Friday, September 18, 2009

3 month projects - the real challenge for architects

We have just successfully completed an challenging "enterprise training tool" on Flex and PHP. This surface computing based training tool is expected to train 40,000 employees of one of the largest European companies. Interestingly, the product had to be completed at production quality in 3 months with 3 major subsystems namely the 'training server', 'admin console' and 'training application'.

Nowadays, is quite often the situation for most of the projects. Delivering projects in 3 months becoming increasingly common whereas considered impossible a year ago. For these projects, there is absolutely no room for architectural mistakes. Single mistake can cost the total easily.

When there is no time to waste, it is really important for architects to have a clear view on the process of architecture. In this short time, what to be performed and to which extent should be a conscious decision rather than ad-hoc.

In this post, let me share my experience on how different pieces get connected in the design phase of a project. Following diagram depicts my view of the software design and architectural process.

For the moment let's assume you have successfully completed the requirement analysis and elicitation. Once you have well defined requirements, it is important to identify the requirements with architectural significance to the project. You may read this post for get to know more on this.

Further analysis on these architecturally significant requirements will tell you the architectural qualities that need to be present to satisfy the requirement in concern. Ensure that you do not just write down a list of general qualities such as performance, reliability, etc. But make your qualities specific to the system you build and measurable too.

Once the required qualities are identified, you need to look for possible ways of realizing those. Each of the quality may be achieved through multiple different tactics. Patterns, blueprints will definitely help you in this exercise.

When multiple tactics present, you will have to compare alternatives and decide the  best suitable tactic for your requirements. Following some decision analysis and resolution method will be useful in structuring and rationalizing the decisions.

Often this selection means compromising.  Therefore each of the selection will possibly raise an architectural risk in the overall architecture. It is important that these risks are properly monitored and managed throughout the project life cycle.

Above we have looked in the process of deriving architecture (high level design) for a system. Where does the low level design (LLD) fits in this picture? Architecture is the base structure of the mini structures (LLDs). LLDs should  elaborate how the functional requirements are realized but should be placed within the rules defined in the architecture. For example, LLD for 'User Login' usecase will have to properly follow the layering demanded by the architecture.

[tag: 99xt ]


Lakmal said...

Great Article sir, it is having the key points to thinks about.
Thank you sir for sharing your experience

Hasith Yaggahavita said...

he he.. thanks for the compliments... This I suppose all of us follows these in practice. Just that being conscious helps in tight situations...