none
Instructions for a newbie architect RRS feed

  • Question

  • Hi,

     

    I'm trying to become "officially" an architect, but I think I still don't have enough knowledge. What readings and courses do you suggest? Is Patterns and Practices a good subject for my study?

     

    Do you have any suggestions?

     

    Thanks.

    Friday, April 18, 2008 12:32 PM

Answers

  • For Application/Solution Architect

    PnP is a good one.

    I also recommend my team to use SkyScrapr.net for ,NET and MS focused architecture.  For purist architecture you can look at www.martinfowler.com (my favourite). 

     

    I dont know any for Infrastructure Architecture, probably some one in Windows Server posts can help.

     

    Some concepts of data architecture is covered in skyscrapr and martinfowler.  But I would recommend deep dive on the database platform you want to specialize.

     

    For Enterprise architect (holistic and hands-off), you can look at Zifa.com from John Zachman.

     

    Personally, there is no one place that can give you all the information.  You will grow into the architecture shoe as you start digesting information and finding the common patterns in the problem statement and how you apply it.

     

    Friday, April 18, 2008 2:46 PM
  • The book "Software Architecture in Practice" is a mandatory reading to start with. Also, read some papers of David Parnas. He was one of the first persons who set the foundations of the area.

     

    Regards,

    Monday, April 28, 2008 2:06 AM
  • Hi,

     

    All the resources that people have detailed on here are great, but I think that there's a little more to it.

     

    You need to already be someone who undestands technology well, such as a good developer with a broad range of knowledge.  Obviously that isn't the only way, but that's a helpful one.  Reading about technology, and finding out the compromises of one technology over another.

     

    Then knowing about architecture and design patterns are also, again, whilst not absolutely necessary, they're very useful to know about.

     

    There's the experience gained from having tried out some of your architectural ideas, so you would know what works well, and what doesn't, or is harder than it should be.

     

    There's also knowing about the challenges of supporting, and maintaining any architectures that you come up with.  Whilst not typically the architecture itself, and down probably to a different department to deal with, it makes or breaks an architecture, due to the ongoing costs involved.

     

    One additional resource that I might add is:

     

    www.dofactory.com

     

    which tells you about design patterns.

     

    Another useful thing to know about, and be able to speak fluently in is UML.  It is invaluable to be able to demonstrate your ideas to the wider world, in a format that is both clear and understand.

    Tied into the ideal of being able to write good UML diagrams, it is also good to be able to communicate with business, in a way that is non-technical and able to convery the correct message, and allow them to see the benefits of the choices that you make.

     

    There is so much more to the role, but that's just a start.

     

    Martin Platt.

     

    Monday, April 28, 2008 5:32 AM
  •  

    Hi Juliano,

       I may add IASA (an international, vendor-agnostic association on Software Architecture). They tried to put a little of order in the mess of "architect" definition though a taxonomy and later worked on a series of trainings depending on the "architectural flavor" you want to choose. I also participated, now from the MS perspective, in a video telling how to became an architect (at least how I did it , but all the stories I heard are pretty similar)

     

     

       Good luck

    Thursday, May 22, 2008 8:06 PM

All replies

  • For Application/Solution Architect

    PnP is a good one.

    I also recommend my team to use SkyScrapr.net for ,NET and MS focused architecture.  For purist architecture you can look at www.martinfowler.com (my favourite). 

     

    I dont know any for Infrastructure Architecture, probably some one in Windows Server posts can help.

     

    Some concepts of data architecture is covered in skyscrapr and martinfowler.  But I would recommend deep dive on the database platform you want to specialize.

     

    For Enterprise architect (holistic and hands-off), you can look at Zifa.com from John Zachman.

     

    Personally, there is no one place that can give you all the information.  You will grow into the architecture shoe as you start digesting information and finding the common patterns in the problem statement and how you apply it.

     

    Friday, April 18, 2008 2:46 PM
  • The book "Software Architecture in Practice" is a mandatory reading to start with. Also, read some papers of David Parnas. He was one of the first persons who set the foundations of the area.

     

    Regards,

    Monday, April 28, 2008 2:06 AM
  • Hi,

     

    All the resources that people have detailed on here are great, but I think that there's a little more to it.

     

    You need to already be someone who undestands technology well, such as a good developer with a broad range of knowledge.  Obviously that isn't the only way, but that's a helpful one.  Reading about technology, and finding out the compromises of one technology over another.

     

    Then knowing about architecture and design patterns are also, again, whilst not absolutely necessary, they're very useful to know about.

     

    There's the experience gained from having tried out some of your architectural ideas, so you would know what works well, and what doesn't, or is harder than it should be.

     

    There's also knowing about the challenges of supporting, and maintaining any architectures that you come up with.  Whilst not typically the architecture itself, and down probably to a different department to deal with, it makes or breaks an architecture, due to the ongoing costs involved.

     

    One additional resource that I might add is:

     

    www.dofactory.com

     

    which tells you about design patterns.

     

    Another useful thing to know about, and be able to speak fluently in is UML.  It is invaluable to be able to demonstrate your ideas to the wider world, in a format that is both clear and understand.

    Tied into the ideal of being able to write good UML diagrams, it is also good to be able to communicate with business, in a way that is non-technical and able to convery the correct message, and allow them to see the benefits of the choices that you make.

     

    There is so much more to the role, but that's just a start.

     

    Martin Platt.

     

    Monday, April 28, 2008 5:32 AM
  •  

    Hi Juliano,

       I may add IASA (an international, vendor-agnostic association on Software Architecture). They tried to put a little of order in the mess of "architect" definition though a taxonomy and later worked on a series of trainings depending on the "architectural flavor" you want to choose. I also participated, now from the MS perspective, in a video telling how to became an architect (at least how I did it , but all the stories I heard are pretty similar)

     

     

       Good luck

    Thursday, May 22, 2008 8:06 PM
  • I'm a working solutions/enterprise architect and have written a number of articles on this subject.  Perhaps they may be of some use?  There are a couple in there that describe a means of making the jump from developer to architect.

     

    http://www.billlunney.com/Architecture/Architecture101/ArchIndex.ascx

     

    As regards patterns and practices as a good study - I'd say it's pretty much mandatory to have at least a base knowledge of both code and enterprise level patterns.  You may not be working on producing code but you will be expected to have a knowledge of the best approach to common development tasks.

     

    Patterns aside, the architecture role necessitates non technical skills too.  Commercial savvy, analysis skills, project management awareness, dealing with 3rd party suppliers etc.  These things are applicable to 'solutions architects'.  If you're just designing software systems exclusively then these are less important skills.  However, that being the case you may end up with a title more like lead developer than architect.

     

     

     

    Bill Lunney

    www.billlunney.com

     

    Thursday, September 18, 2008 9:21 PM
  • I found 'Beyond software architecture - creating and sustaining winning solutions' by Luke Howmann really useful. 

     

    http://books.google.co.uk/books?id=7nF6nuLC7m4C&dq=beyond+software+architecture&pg=PP1&ots=h7wZVjeyws&sig=87RdwRmZOMPLVzQydJseJ6bbSTg&hl=en&sa=X&oi=book_result&resnum=1&ct=result#PPP1,M1

     

    The skills that have helped me the most are the people and communication skills rather than technical skills.

     

    The architect role needs a balance between technical and people skills.  If as a developer you focused on the technical at the cost of the people skills, I would redress this first.

    Friday, September 19, 2008 11:05 AM
  • Principle-1: An architecture must be designed to fit the requirements, but not the other way around. We must not design an architecture and try to fit the requirements into it.

     

    Principle-2: Patterns & Practices are gained through decades of experience and having a look at it is like having a capsule of that decades-ageing experience in us, the architects.

     

    Martin Fowler provides a good insight of the Principle-2 through his websites.

     

    Still being a newbie, I could smell that Principle-1 is followed everywhere but not documented well, nor explicitly suggested by experts. I practised architecting by experimenting various enterprise requirements and designing the architecture for those reuirements.

     

    So, PnP + Your own experiments = Perfect architect

     

    skyscrapr.net helped me most of the times

    Friday, October 10, 2008 12:54 PM