locked
architecture books for becoming an architect RRS feed

All replies

  • Here are a couple of suggestions:


    You'll want to understand design patterns very well.  The classic book is the GoF book.

    You may also want to read most or all of the Patterns and Practices guidance books - they have quite a few good suggestions for architectural decisions, oriented towards Microsoft technologies.





    Reed Copsey, Jr. - http://reedcopsey.com
    Friday, February 12, 2010 7:31 PM
  • be aware though, that one does not 'train' to become an architect. the difference between developer and architect is that the latter thinks in hyper-abstractions. its a paradigm shift in thinking more often or not.

    most of the time people say 'architecture' they are really referring to design. the two are not the same, the former is several orders of magnitude abstracted away from the latter.

    e.g.

    the design of a chair-leg has nothing to do with the architecture of a building .

    Micky D
    Thursday, March 11, 2010 4:11 AM
  • Greeting,

    Simply reading books , you cannot become architect.  The knowledge that you gain, should be put into right partical use.  You should initiate desinging software architecture of your own , this is acutally a learning experience. You needs to learn from your mistakes. It helps you grow alot.

    Read software books and start implementing technical into right use. Just start small projects with small architecture.

    Some basics tips from software architecture.

    • UML,
    • objected oriented analysis and design.
    • Importance ofusing tools for your design.
    • Design pattern
    • Software Project managment.
    • Always have a attitude to learn from books and listening to other people advices.

    Hope this helps

    Take Care

    PL

     


    Helping People To Solve Technical Problems
    Thursday, April 8, 2010 2:50 PM
  • Hi Chuck,

    I agree with the other responses to some extent -- reading a book on C# syntax will not make you a good programmer, nor will reading a book on software architecture make you good at architecture.  On the other hand, there were plenty of clever Roman engineers but any engineering student today can build things better than those Roman engineers.  The difference is the knowledge we can apply.

    So where do you get knowledge about software architecture?  One place is your experience building systems.  Another is conversations with other developers or reading their code.  Yet another place is books.  I am the author of a book on software architecture (Just Enough Software Architecture by George Fairbanks ) but let me instead point you to some classics:

    • Software Architecture in Practice (Bass, Clements, Kazman) .  This book from the Software Engineering Institute (SEI) describes how architects should think about problems.  It describes the importance of quality attributes (performance, security, modifiability, etc.) and how to make tradeoffs between them, since you cannot maximize all of them.
    • Documenting Software Architectures (lots of SEI/CMU authors) .  The title of this book is a bit scary, because many people are trying to avoid writing shelfware documents.  But the wonderful thing about the book is that it describes the standard architectural styles / patterns, notations for describing structure and behavior, and a conceptual model of understanding architectures.  All these are valuable even if you only ever sketch on a whiteboard.
    • Software Systems Architecture (Rosanski and Woods) .  Goes into detail about how to think about a system from multiple perspectives (views).  What I like particularly is that it gives checklists for ensuring that a particular concern (say security) has been handled.
    • Essential Software Architecture (Gorton) .  Small, straightforward book on IT architecture.  Covers the different kinds of things you'll see (databases, event busses, app servers, etc.)

    That's just a short list and just because I didn't list something doesn't mean it's a bad book.  If you are looking something free to read immediately, I have three chapters of my book available for download on my website.

    Good luck,

    -George

    Thursday, September 16, 2010 8:30 PM
  • Previous respondants are spot on - you cannot become an architect just by reading any more than you can become a C# developer by reading a c# book.

    But, do not become discouraged!!

    A good architect will firstly know his business.  He is closer to the business than IT, and will be able to abstract business problems into suitable process, rules, information/data and technology aspects.  From there he can recommend suitable technology building blocks to IT, but is probably not forefront of product selection and CERTAINLY is not directly involved in implementation.

    The best starter I have found is "Enterprise Architecture as Strategy" by Ross, Weill and Robertson (Harvard)

     

    Thursday, September 23, 2010 8:25 AM
  • Well, congrats on your aspiration to become an Architect.

    There is a whole series of WebCast exist on "Aspiring Architects" on MSDN. Following links should help on the same.

    1. http://blogs.msdn.com/b/mohammadakif/

    2. http://blogs.msdn.com/b/mohammadakif/archive/2007/04/25/webcast-series-for-aspiring-architects.aspx

    3. Search for Aspiring Software Architect Program (ASAP) on http://www.microsoft.com/india/webcasts/ondemand.aspx

    4. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives by by Nick Rozanski, Eóin Woods


    HTH


    Equinox!
    Friday, November 5, 2010 10:27 PM
  • The webcast you linked above doesn't seem to have the videos anymore. I get the following message:

    Microsoft Events - Canada
    The Event you are searching for does not exist. If you are searching with an Event Number that you received with an invitation, then it is possible that this event is no longer available for registration.
    Thursday, November 18, 2010 4:48 PM
  • Being an architect is tough to describe, but if I had to describe a software architect's role it would involve

    • Dividing up work to keep multiple people busy
    • Understanding caching and the ACID properties
    • State management
    • Knowing the expected performance before you code
    • Knowing how security is going to play out
    • Breaking things down to the point where you can replace technologies easily (different databases, different code layers, different UI technologies)

    A large application will have lots of layers. For example we had one that had a...

    • Declarative UI layer
    • Procedural UI layer
    • Web Service layer
    • Cache layer
    • Data access layer
    • Relational Database Layer
    • OLAP Cube Layer

    deciding what code goes where is the choice of the architect. The best training is to write complex applications :)

    Thursday, December 2, 2010 12:04 AM
  • 1). Microsoft .NET: architecting Applications for the Enterprise

         by Dino Exposito & Andrea Saltarello

        - Microsoft Press.

     

    2) ASP.NET and AJAX: Architecting Web Applications

          by Dino Esposito

         - Microsoft Press.

     

    3) Inside the Microsoft Build Engine: Using MSBuild and Team Foundation

            by    Sayed Ibrahim Hashimi & William Bartholomew

           - Microsoft Press.

    Monday, January 3, 2011 11:24 PM