The previous post on SPAMMED introduced the different pillars of the process. This one focuses on their interactions
The state chart below (modeled using Sparx System’s excellent Enterprise Architect) shows the possible transitions between the different process steps
Eliciting stakeholders is usually the first step to take – the reason is that stakeholders serve as the base for several of the following steps for example stakeholders concerns serve as a guideline for deciding which views to document during the modeling step.
The next step is documenting principles and goals – which are based on past experience. The real reason however that this step follows the Stakeholders elicitation is that the step also includes documenting constrains, and most of these are set by the different stakeholders (e.g. use .NET/Java because it is a company standard).
Quality Attributes builds on the former two steps, deciding which quality attributes are important and balancing them is based again on the stakeholders concerns and the principles you’ve set.
You would then follow this with some modeling and then technology mapping.
Up to this point the process has been pretty much “waterfall-like”, however after you evaluate your former steps, you may find that you need to revise any of the preceding steps. This is why you want to get here as soon as possible. do not try to complete and “finalize” the architecture and only then perform the evaluation. Developing the architecture, is very much like the other parts of the development life-cycle, and can benefit greatly from a short feedback loop. Evaluating early helps prevent the architecture from being a bottleneck holding all the development process and even more importantly, building too much structure based on false assumptions/decisions.
Deploying the architecture, i.e. releasing it to the designers and developers is the next step (assuming the evaluation was OK). Once the architecture is “out-there”, the realities of the chosen technology/product, changing requirements, budget/talent/ time constrains and most likely the mere iterative nature of modern software development will probably still make you evaluate and retrace some of your steps as a result. I believe this refactoring is a healthy procedure – in the first few iterations (the actual number depends on methodology used, iterations length as well as project size) of your project. Nevertheless if the number of times the architecture has to be reevaluated and changed or alternatively the number of changes is large – it is probably a sign that your architecture is in need of a serious overhaul.
