Tuesday, January 27, 2009

From requirements to architecture

Learning software architecture never flows smoothly as reading a good novel. Often novices get lost within a jungle of technical jargon such as architectural views, frameworks, styles, patterns, etc. When asked, I have seen many of them struggling just to get started due to this complexity mostly created for marketing purposes. With this post, I thought of sharing some of my experience on how to get started with architecting process when you are asked to do so.

Following is one of the definitions for the word 'architecture' by Grady Booch.
"All architecture is design, but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." - Grady Booch

I'm selecting the above as it is much relevant to our discussion. Correctly stated by Booch, it is the high 'cost-of-change' decisions that should be agreed in the system architecture. But the question is that 'from where and how' do we derive these decisions. Keep in mind that you 'MUST' start with requirements, not with a blueprint or a whitepaper that solves another set of problems (blueprints, etc has enormous value but that is not the correct place to start with!). Look for functional/non-functional requirements to identify areas where explicit architecture/design definitions are required (I will brief you on this process in my next post). Then sort the findings in the order of  'significance'. Interestingly it is preferable to omit lower 'significance' decisions from being pre-specified for few reasons.

 - problem understanding increases over the project life cycle, hence decisions taken later are generally more accurate
 - allowing development team to take some design decisions increases the architecture buy-in and provide good design exposure
 - having lesser concerns in the specification makes it less complex but focused

A good understanding of the product road map (explicitly defined) helps to make the architecture less brittle as time passes. It is important not to reinvent every single design decision by your self. Always look around to see relevant existing patterns and blueprints. Learning from someones experience is much cheaper than learning from your own for most of the cases!

I will share more of my experiences on the matter in a future post. Interesting reader can have a look at one of my previous posts on the subject here.

[tag: 99xt ]

No comments: