Creating an architecture is one of the first steps in the system development life cycle. Creating rock solid architecture comes from a collection of tough decisions. During my experience, I have seen various systems fail to achieve the stated goals because of poor architecture. In most of these cases, the failures are introduced early during design phase and usually go undetected until it's too late—when the deadline is near or, worse, when the problem creates headlines. Solving these problems at that point leads to missing schedules, cost overruns, missed opportunities, and other major difficulties.
Therefore, if architecture is so vital for the success of any system, you should have some way to assess and evaluate it to identify flaws and risks early, so that you can mitigate those risks before the costs become too great to manage effectively.
An architectural assessment should be performed at the point where the outcome only impacts the architecture itself and nothing else—before the development team starts making decisions based on architectural artifacts.
Goals of an architectural assessment
In a perfect world, requirements should identify and prioritize business goals, also known as quality attributes, to be achieved by the system. You need to collect quality attributes of the system by merging the requirement document with the plans of the project manager.
After the architectural evaluation, you should:
- Know whether the current architecture is suitable for achieving the quality attributes of the system or get a list of suggested changes for achieving the quality attributes of the system.
- Get a list of the quality attributes which you will achieve fully and those you will only partially achieve.
- Get a list of quality attributes that have associated risks.
- Gain a better understanding of the architecture and the ability to articulate it.
Architecture evaluation methods
After extensive research, the Carnegie Mellon Software Engineering Institute (SEI) has come up with three architecture evaluation methods:
- Architecture Tradeoff Analysis Method (ATAM)
- Software Architecture Analysis Method (SAAM)
- Architecture Review For Intermediate Design (ARID)
In my opinion, ATAM is the best method of the three and is the one I will discuss in more detail.
According to the SEI, to conduct a detailed evaluation, you should divide the evaluation process into the following steps:
- Presentation—During this phase of ATAM, the project lead presents the process of architectural evaluation, the business drivers behind this project, and a high-level overview of architectures under evaluation for achieving the stated business needs.
- Analysis—In the analysis phase, the architect discusses different architectural approaches in detail, identifies business needs from requirement documents, generates a quality attribute tree, and analyzes architectural approaches.
- Testing—This phase is similar to the analysis phase. Here, the architect would identify groups of quality attributes and evaluate architectural approaches against these groups of attributes.
- Report—During the report phase, the architect puts together in a document the ideas, views collected, and the list of architectural approaches outlined during the previous phases.
The diagram in Figure A shows the conceptual flow of ATAM.
|Conceptual flow of ATAM (SEI)|
Architectural evaluation is an essential part of system development. Here, I have emphasized the importance of architecture and outlined a formal method for evaluating architecture in ATAM.
Architectural evaluation is important for the success of all systems, irrespective of size. But, normally, it becomes more significant to use formal architectural evaluation methods in medium to large-scale projects.