The last activity of SAF is deployment of the architecture. This step can make the difference between an ivory-tower architect and one whose designs are actually used in real software projects.
Deployment of the architecture actually means two things
- Verification and feedback loop. – making sure the architecture is actually the right one.
- Governance – making sure that the architecture is followed by the designers and developers
Verification and Feedback loop
It is common practice to think of software development as an iterative process. Knowing that Software architecture is early and that it encompass the important decision which are hard to change, it is probably wise to think of the first few iterations as architectural ones. You would try to work with the team and form the major abstractions, hopefully come up with a blueprint for processes etc. However, the fact that you’ve decided only the (let say) first two iterations are architectural ones, doesn’t mean that new non-functional requirements won’t emerge during later iterations. Since practice shows us it is (almost always) futile to try to analyze “all” the requirements before we do any design – this is almost bound to happen.
Be ready to monitor the project’s progress after the “architectural iterations” to see and deal with any emergent requirements. As the stakeholders (e.g. product owner, project manager and the architect) try to prioritize tasks/requirements from iteration to iteration, hopefully most of the architectural issues would both surface and be taken care of the first few iterations (remember – architectural decisions are the ones that are hard to change…) – but unfortunately this isn’t always so. I recently audited the architecture of a project (which has been running for more than a year) where they identifies the need for transactions, but following some stupid 80/20 rule decided that most of the system does not need that (deadly sin #1) and that they’d be able to easily patch it in later down the road (deadly sin #2) – so not enough just to identify a need, you also need to deal with it early.
The first few iterations also serve as a feedback loop on the suitability of the architecture, sure you’ve tried to evaluate the architecture both in code and on paper , but once it is deployed, or used for real – that is its real test. You will probably want to allocate some time to sit with developers and designers and actually see how the architecture is used and the implications of your decisions.
Governance
It isn’t enough to design a software architecture, show it off at some architecture review and maybe at product demonstrations. Designers and developers are more than likely to bend your architecture to their convenience – this can happen for a multitude of reasons – for example:
- They flipped the bozo on you – they think they know better
- They don’t see the big picture and they try to optimize locally
- They don’t know any better, they just do what they always did
- They believe they are following your design but they didn’t really understand what you’ve meant (or alternatively – you didn’t explain yourself very well)
- They cut corners e.g. to meet dead-lines (just to appease the project manager breathing over their shoulder)
- Etc.
When the architecture is compromised, it can definitely have severe effects on later iterations and the overall stability/usability of the system. It is important to note that it may even result in harsh implications for the organization – imagine someone circumvents some auditing mechanisms you’ve put in place to comply with SOX or Basel II.
What this means for the architect is that she cannot disengage from the project completely even once the architecture is stabilized (i.e. after the first few iterations). Architect involvement is needed for design reviews, maybe key code reviews , on mile stones etc.
I think it is one of the architect rolls to act as a “comptroller” and oversee that the project stays on track as far as the architecture goes. Unfortunately there aren’t too many automated tools to help with that. DSLs is one direction that may help (look for example at the Guidance and Automation Toolkit here and here ). I’ve also recently saw an application that claims it can enforce and monitor SOA policies on e.g. on contacts (for both Java and .NET). I hope we’ll see more of these tools in the future – meanwhile it is up to us, architects, to do that as part of our overall responsibility.
