This post might look like an offbeat if you have not already gone through my two previous posts where I have written why we need to evaluate software architecture and what we need in hand so that we can evaluate them. I encourage you to read them if you are unsure and would like to get the full context.
So at this point we are convinced that we need to review the architecture we create and what we need to be able to review. In this post I will write about how we can do the review, what we need to keep in mind and what steps we could / should probably take to review a software architecture.
What should we do and check to evaluate architecture?
Go through all documents available to gather as much information.
Ask and discuss with the architect(s) who produced the architecture and clear all possible doubts.
When available, run tests if possible and check results against benchmarks and KPIs provided.
Validate whether there are any mismatches between the architecture and the PoC(s) done. Check whether there were too many assumptions in PoC(s).
Evaluate the architecture against the security and performance benchmarks.
Check whether there is data available with measured quality attributes, and whether the measured data matches with expectation according to the architecture documentation.
Check whether the architecture is compliant with standard and guidelines. The standard and guidelines may come from the industry itself. These are the standards and guidelines which are well established in the technical domain. Your company can also have their or product standards and guidelines, as well as architecture guidelines.
At the end provide your evaluation feedback to the architect(s) who produced the architecture.
When the reviewer keeps the above points in mind then it will be easy to evaluate architecture work done by others.
While evaluating an architecture of a software product or a part of a software system the reviewer should seek answers to a few questions. This will help the reviewer to approach the task because architectures can be complex and one needs the background and context as much as possible to understand why some decisions were taken.
What questions need to be answered to evaluate architecture?
In a few words, which problem(s) had to be solved?
What were the boundary conditions (skills, time, budget, strategy, hidden agenda)?
What were the architecture drivers?
Which implicit assumptions turned out to be important architecture drivers? How could they be made explicit?
Were all relevant stakeholder groups identified? Did they provide input?
Was there a conflict in the requirements, quality attributes, and boundary conditions?
What were the main trade-offs to balance?
Could architecture decisions be prepared, for example by prototypes or by a technology evaluation?
Who made the most important architecture decisions?
Which alternatives were considered before finalizing the given architectural design?
How was the communication about the architecture organized with stakeholders?
If the architecture has already been implemented then, looking back
Which architecture decision turned out to be very good? Which architecture decision turned out to be bad? Was something "over engineered"?
To which extent was a change in requirements anticipated in the architecture? Was it needed until now?
Which requirements / quality attributes / boundary conditions changed after the initial architecture was defined? How to deal with that?
Which are the key lessons learned from this project?
Seeking answers to these above questions makes the work of the reviewer easy.
In this post I have gone through some points that makes the review of an architecture easy for a reviewer and helps the reviewer to approach the task of reviewing software architectures created by others.