In one of my posts I wrote about why software architectures also need a review, When the reviews need to be done and who should do it (Read my post: Does Software Architectures need review ?). Now, we need to know what we need to know before we can successfully review an architecture. We need to establish a set of parameters against which we can evaluate an architecture.
Contents
What we need to know before we can evaluate an Architecture?
Here I am going to discuss a few points that explain what we need before we can evaluate a software architecture and its designs.
Context
When an architecture is developed it has a history behind it. It is developed for a reason. There are business goals that are required to be addressed. From business goals business requirements are derived. From business requirements technical requirements are derived. The goals and requirements explain why we are creating the architecture and what we want to achieve. Then there are scope and boundary conditions that shape the decisions that are taken by the architects and assumptions that have been made. Whoever reviews your architecture needs this information to understand the context. The context helps them understand why the architect has taken some decisions and validate whether the decisions taken are reasonable.
KPIs
As an architect we need to establish our KPIs and measuring units. This helps a reviewer evaluate whether the architecture met its expectations. The architect also needs to provide the reason why certain KPIs are selected because they need to justify whether the KPis provided and benchmarks created will be able to measure the software product. This is needed because the very design of the software should be done such that it can perform against the established KPIs. And it's the task of architects to come up with the KPI. Then the reviewer needs to verify whether the given KPIs are the write ones to measure the performance of the software according to the requirements.
Quality Attributes and their trade offs
As an architect we know what are the quality attributes you are emphasizing and why. We know how much weightage we have given to which quality attributes. We should have also thought about the trade off we need to make between certain quality attributes. As part of our Architecture Concept Document or Architecture Detail Document we should document these decisions. An architecture evaluator needs to know these decisions and also would like to evaluate the reasoning and decision on quality attributes.
Outcome of PoC(s)
Before we finalize the design we must have done some development as Proof of Concept. Based on the PoC results we verify our architectural assumptions, what will work and what will not work. A reviewer of an architecture also needs the report that explains the result of the PoC(s) that has been done.
All architecture and requirement analysis documents
Finally all documents that we have written explaining the architecture along with the diagrams and for which we seek a review need to be given to the reviewer. Also, we need to provide the requirement analysis documents.
What are the Criteria Against which Architecture needs to be evaluated?
Understandability of Architectural Documents
The documents produced by the architect during the development of the architecture need to be well written, organized and explained so that anyone who is not deep into the topic can also understand it and can evaluate.
Performance measure(KPIs)
When we provide the KPIs that need to be used to measure the Software and its design, we also need to provide the early measures that have been done. The measures may be done on PoCs where a lot of things are hardcoded and do not show the real picture but still it can be helpful.
Cost
The estimated Cost of ownership of the software product that will be developed based on the design. The cost has to be justified against the business goals. Cost can be monitory for example the infrastructure that is needed to deploy and run the software, as well as the cost of development means the manpower needed for development work and cost of maintenance means the manpower needed for DevOps work.
Security
Though security is also a quality attribute of a software product but nowadays security is must. We must define the security criteria for the product and ensure in the design that the criteria will be fulfilled. It's an established fact that to ensure a certain degree of security in a software product we need to think how it can be achieved in the design phase and incorporate it into the architecture. If the software developers code according to the design then the security criteria will be fulfilled.
Other Quality attributes
The quality attributes that have been considered relevant for the product and given weightage against other quality attributes. The non functional quality attributes can be the performance, resilience, robustness and more. The functional quality attributes can be the percentage of error that can be tolerated means the correctness of the product. How the design ensures the quality against the attributes need to be evaluated. As we know some attributes are contradictory, each attribute needs to be given a particular weightage. For example, performance in terms of time can be contradictory with modularity in micro service oriented architecture. Modularity will force us to divide the functionality into different separate micro services, but with many microservices there is communication time between them increases. That takes more time to return results against a monolithic architecture where all modules physically reside in one machine and one code base.
In this post I have jotted down a few of the points that we need to be able to understand the architecture and the architectural decisions taken by the architects. I have also written few points that help us formulate the criteria against which architecture needs to be evaluated. Of Course this is not the full list, there can be many things we can include in the criteria.