none
Learn architecture for beginners

    Question

  • Could you please suggest some ideal web site for learning/to get good metarials about Architecture for beginners.

    Thanks,
    Wednesday, November 11, 2009 4:50 AM

All replies

  • Hi,


    Check this

    http://msdn.microsoft.com/en-us/library/dd673617.aspx


    Regards
    Azhar

    Mark as answer if this helps



    Thanks and Regards Azhar Amir
    Wednesday, November 11, 2009 4:58 AM
  • Greetings,


    Point 1:
    Architecture is defined to be the rules, heuristics and patterns governing:

    • Partitioning the problem and the system to be built into discrete
    • pieces Techniques used to create interfaces between these pieces
    • Techniques to manage overall structure and flow
    • Techniques used to interface the system to its environment
    • Appropriate use of development and delivery approaches, techniques  and tools.

    Defining architecture is part of the software development process. Its primary goal is to define the non-functional requirements of a system and define the environment. The detailed design is followed by a definition of how to deliver the functional behavior within the architectural rules. Architecture is important because it:

    •  Controls complexity
    •  Enforces best practice
    •  Gives consistency and uniformity
    •  Communicates skill needs
    •  Reduces risk
    •  Enables re-use.


    Point 2:

    IEEE Std. 610.12-1990: A system is a collection of components organized to accomplish a specific function or set of functions.

    Point 3:

    There are many common ways of designing computer software modules and their communications, among them:

    • Blackboard
    • Client-server (2-tier, n-tier, peer-to-peer, Cloud Computing all use this model)
    • Database-centric architecture (broad division can be made for programs which have database at its center and applications which don't have to rely on databases, E.g. desktop application programs, utility programs etc.)
    • Distributed computing
    • Event Driven Architecture
    • Front-end and back-end
    • Implicit invocation
    • Monolithic application
    • Peer-to-peer
    • Pipes and filters
    • Plugin
    • Representational State Transfer
    • Rule evaluation
    • Search-oriented architecture (A pure SOA implements a service for every data access point)
    • Service-oriented architecture
    • Shared nothing architecture
    • Software componentry (strictly module-based, usually object-oriented programming within modules, slightly less monolithic)
    • Space based architecture
    • Structured (module-based but usually monolithic within modules)
    • Three-tier model (An architecture with Presentation, Business Logic and Database tiers)
    Point 4:

    Who are the Three Amigos?

    Grady Booch, James Rumbaugh, and Ivar Jacobson, leaders of the method unification effort that led to the creation of UML, are commonly referred to as the Three Amigos.The Unified Modeling Language (UML) was developed by Grady Booch, Jim Rumbaugh and Ivar Jacobson (the Three Amigos ) as a way to define large complicated systems.

    Grady Booch Importance of Software in Society Video 0004 -  Youtube. must see video
    http://www.youtube.com/watch?v=Q8SmtqxTqf4

    Point 5: Video Tutorials

    Usability and Software Architecture: The Forgotten Problems: stanfordUniversity, usa
    http://www.youtube.com/watch?v=CRx4h4ITx9g


    Software Modeling and Architecture
    http://www.youtube.com/watch?v=79hrNLm6S7k&feature=related

    The role of the software architect

    http://www.youtube.com/watch?v=lFGIVHeQPbg

    O'Reilly Webcast: 10 Things Every Software Architect Should Know

    http://www.youtube.com/watch?v=Dtd0njgo4s8


    Point 5: Architectural Patterns
    The multi-layer architecture and design principles
    • Divide and conquer: The layers can be independently designed.
    • Increase cohesion: Well-designed layers have layer cohesion.
    • Reduce coupling: Well-designed lower layers do not know about the higher layers and the only connection between layers is
    • through the API.
    • Increase abstraction: you do not need to know the details of how the lower layers are implemented.
    • Increase reusability: The lower layers can often be designed generically.
    • The multi-layer architecture and design principles
    • Increase reuse: You can often reuse layers built by others that provide the services you need.
    • Increase flexibility: you can add new facilities built on lower-level services, or replace higher-level layers.
    • Anticipate obsolescence: By isolating components in separate layers, the system becomes more resistant to obsolescence.
    • Design for portability: All the dependent facilities can be isolated in one of the lower layers.
    • Design for testability: Layers can be tested independently.
    • Design defensively: The APIs of layers are natural places to build in rigorous assertion-checking.
    The Client-Server and other distributed architectural patterns

    • There is at least one component that has the role of server, waiting for and then handling connections.
    • There is at least one component that has the role of client, initiating connections in order to obtain some service.
    • A further extension is the Peer-to-Peer pattern.
    • A system composed of various software components that are distributed over several hosts.
    An example of a distributed system
    The distributed architecture and design principles
    • Divide and conquer: Dividing the system into client and server processes is a strong way to divide the system.
    • Each can be separately developed.
    • Increase cohesion: The server can provide a cohesive service to clients.
    • Reduce coupling: There is usually only one communication channel exchanging simple messages.
    • Increase abstraction: Separate distributed components are often good abstractions.
    • Increase reuse: It is often possible to find suitable frameworks on which to build good distributed systems
    • However, client-server systems are often very application specific.
    • The distributed architecture and design principles
    • Design for flexibility: Distributed systems can often be easily reconfigured by adding extra servers or clients.
    • Design for portability: You can write clients for new platforms without having to port the server.
    • Design for testability: You can test clients and servers independently.
    • Design defensively: You can put rigorous checks in the message handling code.

    The Broker architectural pattern

    • Transparently distribute aspects of the software system to different nodes
    • An object can call methods of another object without knowing that this object is remotely  located.
    • CORBA is a well-known open standard that allows you to build this kind of architecture.

    Example of a Broker system
    The broker architecture and design principles
    •  Divide and conquer: The remote objects can be independently designed.
    •  Increase reusability: It is often possible to design the remote objects so that other systems can use them too.
    •  Increase reuse: You may be able to reuse remote objects that others have created.
    •  Design for flexibility: The brokers can be updated as required, or the proxy can communicate with a different remote object.
    •  Design for portability: You can write clients for new platforms while still accessing brokers and remote objects on other platforms.
    •  Design defensively: You can provide careful assertion checking in the remote objects.
    The Transaction-Processing architectural pattern
    • A process reads a series of inputs one by one.
    • Each input describes a transaction – a command that typically some change to the data stored by the system
    • There is a transaction dispatcher component that decides what to do with each transaction
    • This dispatches a procedure call or message to one of a series of component that will handle the transaction  

    Example of a transaction-processing system

    • The transaction-processing architecture and design principles
    • Divide and conquer: The transaction handlers are suitable system divisions that you can give to separate software engineers.
    •  Increase cohesion: Transaction handlers are naturally cohesive units.
    • Reduce coupling: Separating the dispatcher from the handlers tends to reduce coupling.
    •  Design for flexibility: You can readily add new transaction handlers.
    • Design defensively: You can add assertion checking in each transaction handler and/or in the dispatcher.
    The Pipe-and-Filter architectural pattern
    • A stream of data, in a relatively simple format, is passed through a series of processes
    • Each of which transforms it in some way.
    • Data is constantly fed into the pipeline.
    • The processes work concurrently.
    • The architecture is very flexible.
    • Almost all the components could be removed.
    • Components could be replaced.
    • New components could be inserted.
    • Certain components could be reordered.
    Example of a pipe-and-filter system
    The pipe-and-filter architecture and design principles
    • Divide and conquer: The separate processes can be independently designed.
    • Increase cohesion: The processes have functional cohesion.
    • Reduce coupling: The processes have only one input and one output.
    • Increase abstraction: The pipeline components are often good abstractions, hiding their internal details.
    • Increase reusability: The processes can often be used in many different contexts.
    • Increase reuse: It is often possible to find reusable components to insert into a pipeline.
    • The pipe-and-filter architecture and design principles
    • Design for flexibility: There are several ways in which the system is flexible.
    • Design for testability: It is normally easy to test the individual processes.
    • Design defensively: You rigorously check the inputs of each component, or else you can use design by contract.
    The Model-View-Controller (MVC) architectural pattern
    • An architectural pattern used to help separate the user interface layer from other parts of the system
    • The model contains the underlying classes whose instances are to be viewed and manipulated
    • The view contains objects used to render the appearance of the data from the model in the user interface
    • The controller contains the objects that control and handle the user’s interaction with the view and the model
    The Observable design pattern is normally used to separate the model from the view
    • Example of the MVC architecture for the UI
    • Example of MVC in Web architecture

    The MVC architecture and design principles
    • Divide and conquer: The three components can be somewhat independently designed.
    • Increase cohesion: The components have stronger layer cohesion than if the view and controller were together in a single UI layer.
    • Reduce coupling: The communication channels between the three components are minimal.
    • Increase reuse: The view and controller normally make extensive use of reusable components for various kinds of UI controls.
    • Design for flexibility: It is usually quite easy to change the UI by changing the view, the controller, or both.
    • Design for testability: You can test the application separately from the UI.

    The Service-oriented architectural pattern
    • This architecture organizes an application as a collection of services that communicates using well-defined interfaces
    • In the context of the Internet, the services are called Web services
    • A web service is an application, accessible through the Internet, that can be integrated  with other services to form a complete system
    • The different components generally communicate with each other using open standards such as XML.
    Example of a service-oriented application

    The Service-oriented architecture and design principles
    • Divide and conquer: The application is made of independently designed services.
    • Increase cohesion: The Web services are structured as layers and generally have good functional cohesion.
    • Reduce coupling: Web-based applications are loosely coupled built by binding together distributed components.
    • Increase reusability: A Web service is a highly reusable component.
    • Increase reuse: Web-based applications are built by reusing existing Web services.
    • Anticipate obsolescence: Obsolete services can be replaced by new implementation without impacting the applications that use them.
    • The Service-oriented architecture and design principles
    • Design for portability: A service can be implemented on any platform that supports the required standards.
    • Design for testability: Each service can be tested independently.
    • Design defensively: Web services enforce defensive design since different applications can access the service.

    The Message-oriented architectural pattern
    • Under this architecture, the different sub-systems communicate and collaborate to accomplish some task only by exchanging messages.
    • Also known as Message-oriented Middleware (MOM)
    • The core of this architecture is an application-to-application messaging system
    • Senders and receivers need only to know what are the message formats
    • In addition, the communicating applications do not have to be available at the same time (i.e. messages can be made persistent)
    • The self-contained messages are sent by one component (the publisher) through virtual channels (topics) to which other
    • interested software components can subscribe (subscribers)

    Example of a Message-oriented application

    The Message-oriented architecture and design principles
    • Divide and conquer: The application is made of isolated software components.
    • Reduce coupling: The components are loosely coupled since they share only data format.
    • Increase abstraction: The prescribed format of the messages are generally simple to manipulate, all the application details being hidden behind the messaging system.
    • Increase reusability: A component will be resusable is the message formats are flexible enough.
    • Increase reuse: The components can be reused as long as the new system adhere to the proposed message formats.


    The Message-oriented architecture and design principles

    • Design for flexibility: The functionality of a message-oriented system can be easily updated or enhanced by adding or replacing components in the system.
    • Design for testability: Each component can be tested independently.
    •  Design defensively: Defensive design consists simply of validating all received messages before processing them.
    Point 6 : Design Patterns

    • Design patterns are not a design or development methodology. They are a vocabulary: they help putting names on recurring patterns that occur in software architectures.  Designing a software from patterns ends up in hairy software with a lot of single-purpose classes, which increases the number of things that the programmer must have in mind (and software development is complicated enough to avoid filling your brain with noise).
    • However design patterns come very handy at a later stage. Always start with your specific problem and domain, try to find solutions, and identify patterns in the process. Don't start with the patterns, trying to force-fit your problem into them. Knowledge of the most common patterns is a must, as it eases communication between programmers (be they developer or library users) and promotes good practices.
    • Design patterns originally come from building and architecture, which are very similar to software development in many ways. From my experience the best way to understand DPs is through analogy with architecture: software is the building, patterns are the way architectural elements are organized: windows, doors, corridors, stairs, lights... Architects don't think about the elements they want to use, but think about the effect they want to get. For example, an architect might think: this staircase needs light. To achieve this, he may use windows, skylights, glass blocks, artificial lights, etc., according to the architectural constraints, building code, his client's taste, etc. He doesn't arbitrarily choose elements before thinking about the problem he's trying to solve, unless he's trying to achieve an effect or style. Moreover, if another solution becomes available on the market (e.g. reflective sunlight tunnels) then he may integrate it in the available design patterns for his future projects. OTOH if he takes the habit of thinking about solutions before thinking about problems, he takes the risk of missing alternative solutions, complicating the problem, or not solving it at all.
    • Overusing design patterns is as bad as not using them where they are needed. Choosing whether to use some pattern or not comes with knowledge and experience on software design and development in general, and your field in particular.
    Point 7 : UML


    There are three classifications of UML diagrams:

    • Behavior diagrams.  A type of diagram that depicts behavioral features of a system or business process.  This includes activity, state machine, and use case diagrams as well as the four interaction diagrams.
    •  Interaction diagrams.  A subset of behavior diagrams which emphasize object interactions.  This includes communication, interaction overview, sequence, and timing diagrams.
    • Structure diagrams.  A type of diagram that depicts the elements of a specification that are irrespective of time.  This includes class, composite structure, component, deployment, object, and package diagrams. 
    • http://www.uml.org/
    The diagrams of UML 2.


    Diagram

    Description

    Learning Priority

    Activity Diagram

    Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system.

    High

    Class Diagram

    Shows a collection of static model elements such as classes and types, their contents, and their relationships.

    High

    Communication Diagram

    Shows instances of classes, their interrelationships, and the message flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages.  Formerly called a Collaboration Diagram. 

    Low

    Component Diagram

    Depicts the components that compose an application, system, or enterprise. The components, their interrelationships, interactions, and their public interfaces are depicted.

    Medium

    Composite Structure Diagram

    Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system.   

    Low

    Deployment Diagram

    Shows the execution architecture of systems.  This includes nodes, either hardware or software execution environments, as well as the middleware connecting them.

    Medium

    Interaction Overview Diagram

    A variant of an activity diagram which overviews the control flow within a system or business process.   Each node/activity within the diagram can represent another interaction diagram.   

    Low

    Object Diagram

    Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram. 

    Low

    Package Diagram

    Shows how model elements are organized into packages as well as the dependencies between packages.

    Low

    Sequence Diagram

    Models the sequential logic, in effect the time ordering of messages between classifiers.  See 

    High

    State Machine Diagram

    Describes the states an object or interaction may be in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram. 

    Medium

    Timing Diagram

    Depicts the change in state or condition of a classifier instance or role over time.  Typically used to show the change in state of an object over time in response to external events. 

    Low

    Use Case Diagram

    Shows use cases, actors, and their interrelationships. 

    Medium





    Hope this helps .

    Take Care

    PL
    Helping People To Solve Technical Problems
    • Proposed as answer by Ashwini47 Thursday, May 10, 2012 1:54 PM
    Wednesday, November 11, 2009 7:22 PM
  • There is so much information out there, it can get overwhelming rather quickly.  I found that a good start for me was reading the following book:
    http://www.amazon.com/Microsoft%C2%AE-NET-Architecting-Applications-PRO-Developer/dp/073562609X/ref=sr_1_1?ie=UTF8&s=books&qid=1258041639&sr=8-1


    I think once you have a good handle on the concept in that book, you'll brain will naturally start branching out into different directions which you'll be able to explore on your own.
    Thursday, November 12, 2009 4:02 PM
  • Hi Ramkumar Thangavel,


     Simply the study the software architecture does not make no sense. It will be useful for you, when you create the software architecture based on the technical know how that you have gained.  Then you are putting the knowledge into practical use. It makes a lot of sense. You are spending the time in a useful manner.  The technical challenges that you face in design and implementing your software architecture is a great learning experience for you. All the best friend.

    Wishing you all success . In this forum , you will get the help that you need. Your attitude and self motivation is more important than anything else.

    Thanking you,

    Phijo Mathew Philip.

    PHIJO MP
    • Proposed as answer by PROGRAMMERLIVE Thursday, November 12, 2009 8:47 PM
    Thursday, November 12, 2009 8:33 PM
  • Greeting,

    Look into cloud computing software architecture, software as service . Check the latest developments that is happening in field software architecture. When you develop the software architecture you need to understand the business objective and customer expectation in terms of customer satisfaction .

    Take Care

    PL
    Helping People To Solve Technical Problems
    Thursday, November 12, 2009 8:52 PM
  • Hi.

    The best way I found to learn architecture at the software level (as in how to design software internals) is through learning design patterns.

    Get the Gang Of Four Design Patterns book and study it....



     
    Thinking in pictures helps too....
    http://en.wikipedia.org/wiki/Thinking_in_pictures

    Take up painting or learn a music instrument. :)
    Tuesday, November 17, 2009 11:10 AM
  • one cannot generally 'learn' to be an architect. it requires a paradigm shift in thinking for one.  architects think in hyper abstrations.

    most of the time where i see others use the term 'architecture' they really mean 'design'.

    having said that, i highly recommend the book:

    bass, clements, kazman, Software ARchitecture in Practice, 2nd edition, addison wesley
    Micky D
    Thursday, November 19, 2009 6:53 AM
  • Hi MickyD

    You posted....

    "most of the time where i see others use the term 'architecture' they really mean 'design'."


    This is interesting and I'm genuinely curious as to what you think is the difference between architecture and design?

    I understand that there is the architecture of the overall system, the infrastructure, the location of components and how they all communicate; more than the sum of their parts. I also understand the internal architecture of each component, the domain model, and so on.... but to me there isn't a difference between architecture and design; do they not represent the same thing?

    This is genuine, there might be something I'm missing.
    Thursday, November 19, 2009 10:51 AM
  • Hi Derek,

    That's a good question. design and architecture start off quite similar but the latter goes on to describe elements , interfaces or contracts, behaviour between elements in abstract terms. these elements may be external systems.  elements expose interfaces that other elements may utilise (not the same as c# interfaces). however designing a few interfaces is not an architecture. we must also describe the other elements and show the relationship between elements and detail the behavior a element will exhibit when invoked.  it is important to understand that elements are not objects as in typical design but more than likely other processes or systems off site.

    the fundamental difference between 'physical design' and architecture, is that architecture generally begins in hyper-abstrations. one single logical architecture can be realised into countless physical designs or implementations. 

    there is also the difference of scale. what most programmers think of as 'design' is the 'physical implementation'. at this scale developers are working on a subsystem or sub-component that is part of a larger hosting environment.  e.g. developers 'design' their online sales portal; their customer-edit screen; their database ORM component.  architects author application extensibility frameworks; a distributed system for inter-application communications via ESB SOA across heterogeneous network, OSs and applications written in various languages. 

    it is perhaps true that architecture has a 'design' element, but it does not mean everything that is designed has an 'architecture'.

    the 'design' of a certain software program can be as far removed as a chair-leg is from the architecture of a house . a rather good metaphor i read recently somewhere.

    i think IASA will have a post somwhere going into more detail.

    a good litmus test is that if you are crafting a new program and are allready thinking of programming languages, physical classes, operating systems then chances are you are doing 'design'. architecture needs to be neutral in these things unless of course it is a requirement (though emphasis there would be most likely OS or language in my example). its also vitally important that the creation be long-term and more than likely exceed the requirements of today.

    architects are also very good at looking at several projects being designed by others and saying

    'hey, if we take a step back, you guys are really just working on the pieces of a much larger system - let us architect that instead'

    so if you're working on bit of software that is pretty much self-contained with no incoming behaviours, then its a good chance you're working on a chair-leg. :)

    hope this helps



    Micky D
    Monday, November 23, 2009 9:52 AM
  • Get experience, get more experience, and then when you think you're ready, get some more experience.

    If you try to become an architect by reading books, you won't be very good, or you will be reading for many years!

    You need to look into application architecture first, designing applications, which is about use of design patterns, OO, Services, Technologies, and so on, but would likely be scoped at defining parts of a system.

    There are also infrastructure architects, who will put together networks, security, machine build specs and so on.

    The next level up from there is solution architect, where you are looking at a wider picture, so including much more in your scope, such as intrastructure as well as software design for example.

    The next level up from there is effectively enterprise architect, where you are looking at all the enterprise wide attributes, making such that the solutions produced by the solution architects, fit in with the business strategy.  Here's you're more of a strategist, so also define future technology direction, and how that will assist the business in achieving its goals.

    As you can see from the above very brief generalisations, this is a very broad subject, and to be good at it, you need a very broad knowledge.

    My first comment - experience, in all these roles you are likely to be a mentor for other team members, and if you don't have that experience, people won't respect you, and you won't do well with your job.  Being call 'an architect' means absolutely nothing if you're no good at the steps that would naturally precede it, such as being a good developer, or network admin, or team leader or whatever. 

    Martin.

    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good! http://www.consultantvault.com
    Friday, November 27, 2009 3:00 AM
  • I agree Martin my old friend. Experience is essential.

    My final point to others is that the role of an architect is that it is not the last 'promotion' a software developer receives .  Though generally architects were once developers, not all developers should be promoted to an architectural role just because they're been programming for 20 years or so. It is a specialist role, just like not all developers would make good managers.  I'm sure we have all encountered these.

    This is a common problem and should be avoided.

    I wish you well Ramkumar in your architectual ventures

    Micky D
    Friday, November 27, 2009 8:02 PM
  • Get your bearings on Wikipedia (here) and visit links at the bottom of that page. Some of the links provided by the members of this community are also good, like the Microsoft Application Architecture Guide, 2nd Edition. Also consider the architecture starter page from the SEI. And a one page executive summary from SoftwareArchitectures.com.

    I highly recommend approaching the art and science of architecting from technology agnostic point of view. Please consider an architecture centric approach to designing. This book is on my "essential selection" list: Software Intensive Systems: A Practitioners Guide by Anthony J. Lattanze. A short blurb about the book can be found here.

    Review The Architecture Journal for the contemporary topics. Most articles provide a gentle immersion into the topic covered. You can learn a lot from that.


    Constantin K.

    Firebrand Architect® - software fit for purpose™
    Monday, November 30, 2009 1:19 AM
  • These are the most valuable resources that helps a lot for .NET Architect

    Modeling the Application - http://msdn.microsoft.com/en-us/library/dd409376(v=VS.100).aspx

    Microsoft Application Architecture Guide, 2nd Edition - http://msdn.microsoft.com/en-us/library/dd673617.aspx

    Cheers!!!

    Abu

    Thursday, May 27, 2010 1:52 AM
  • Greetings

    Be a good programmer , proper behavior skill is required , that is how adjust with people to get a task done. 

     

    PL


    Helping People To Solve Technical Problems
    Friday, May 28, 2010 3:31 PM
  • Hi MickyD

    You posted....

    "most of the time where i see others use the term 'architecture' they really mean 'design'."


    This is interesting and I'm genuinely curious as to what you think is the difference between architecture and design?

    I understand that there is the architecture of the overall system, the infrastructure, the location of components and how they all communicate; more than the sum of their parts. I also understand the internal architecture of each component, the domain model, and so on.... but to me there isn't a difference between architecture and design; do they not represent the same thing?

    This is genuine, there might be something I'm missing.

    Hi Derek,

    I agree with you.

    To me an architect is a designer with more accent to interpersonal/politic/organisation things.

    A designer is an architect with more accent on technology/decision/product.

    Architect more blah-blah-blah (no offence!), designer more modeling-creating-deploying.


    Leonid Ganeline [BizTalk MVP] Biztalkien blog
    Monday, May 31, 2010 5:41 AM
  • This list of online articles and books is a great start:

    Software Developer / Architect Recommended Reading


    Sergey
    Sunday, October 09, 2011 1:03 PM