- Why Evaluate an Architecture?
- 2 When Can an Architecture Be Evaluated?
- 3 Who's Involved?
- 4 What Result Does an Architecture Evaluation Produce?
- 5 For What Qualities Can We Evaluate an Architecture?
- 6 Why Are Quality Attributes Too Vague for Analysis?
- 7 What Are the Outputs of an Architecture Evaluation?
- 8 What Are the Benefits and Costs of Performing an Architecture Evaluation?
- 9 For Further Reading
- 10 Discussion Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
2.2 When Can an Architecture Be Evaluated?
The classical application of architecture evaluation occurs when the architecture has been specified but before implementation has begun. Users of iterative or incremental life-cycle models can evaluate the architectural decisions made during the most recent cycle. However, one of the appealing aspects of architecture evaluation is that it can be applied at any stage of an architecture's lifetime, and there are two useful variations from the classical: early and late.
Early.
Evaluation need not wait until an architecture is fully specified. It can be used at any stage in the architecture creation process to examine those architectural decisions already made and choose among architectural options that are pending. That is, it is equally adept at evaluating architectural decisions that have already been made and those that are being considered.
Of course, the completeness and fidelity of the evaluation will be a direct function of the completeness and fidelity of the architectural description brought to the table by the architect. And in practice, the expense and logistical burden of convening a full-blown evaluation is seldom undertaken when unwarranted by the state of the architecture. It is just not going to be very rewarding to assemble a dozen or two stakeholders and analysts to evaluate the architect's early back-of-the-napkin sketches, even though such sketches will in fact reveal a number of significant architecture paths chosen and paths not taken.
Some organizations recommend what they call a discovery review, which is a very early mini-evaluation whose purpose is as much to iron out and prioritize troublesome requirements as analyzing whatever "proto-architecture" may have been crafted by that point. For a discovery review, the stakeholder group is smaller but must include people empowered to make requirements decisions. The purpose of this meeting is to raise any concerns that the architect may have about the feasibility of any architecture to meet the combined quality and behavioral requirements that are being levied while there is still time to relax the most troubling or least important ones. The output of a discovery review is a much stronger set of requirements and an initial approach to satisfying them. That approach, when fleshed out, can be the subject of a full evaluation later.
We do not cover discovery reviews in detail because they are a straightforward variation of an architecture evaluation. If you hold a discovery review, make sure to
Hold it before the requirements are frozen and when the architect has a good idea about how to approach the problem
Include in the stakeholder group someone empowered to make requirements decisions
Include a prioritized set of requirements in the output, in case there is no apparent way to meet all of them
Finally, in a discovery review, remember the words of the gifted aircraft designer Willy Messerschmitt, himself no stranger to the burden of requirements, who said:
You can have any combination of features the Air Ministry desires, so long as you do not also require that the resulting airplane fly.
Late.
The second variation takes place when not only the architecture is nailed down but the implementation is complete as well. This case occurs when an organization inherits some sort of legacy system. Perhaps it has been purchased on the open market, or perhaps it is being excavated from the organization's own archives. The techniques for evaluating a legacy architecture are the same as those for one that is newborn. An evaluation is a useful thing to do because it will help the new owners understand the legacy system, and let them know whether the system can be counted on to meet its quality and behavioral requirements.
In general, when can an architectural evaluation be held? As soon as there is enough of an architecture to justify it. Different organizations may measure that justification differently, but a good rule of thumb is this: Hold an evaluation when development teams start to make decisions that depend on the architecture and the cost of undoing those decisions would outweigh the cost of holding an evaluation.