- 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.7 What Are the Outputs of an Architecture Evaluation?
2.7.1 Outputs from the ATAM, the SAAM, and ARID
An architecture evaluation results in information and insights about the architecture. The ATAM, the SAAM, and the ARID method all produce the outputs described below.
Prioritized Statement of Quality Attribute Requirements
An architecture evaluation can proceed only if the criteria for suitability are known. Thus, elicitation of quality attribute requirements against which the architecture is evaluated constitutes a major portion of the work. But no architecture can meet an unbounded list of quality attributes, and so the methods use a consensus-based prioritization. Having a prioritized statement of the quality attributes serves as an excellent documentation record to accompany any architecture and guide it through its evolution. All three methods produce this in the form of a set of quality attribute scenarios.
Mapping of Approaches to Quality Attributes
The answers to the analysis questions produce a mapping that shows how the architectural approaches achieve (or fail to achieve) the desired quality attributes. This mapping makes a splendid rationale for the architecture. Rationale is something that every architect should record, and most wish they had time to construct. The mapping of approaches to attributes can constitute the bulk of such a description.
Risks and Nonrisks
Risks are potentially problematic architectural decisions. Nonrisks are good decisions that rely on assumptions that are frequently implicit in the architecture. Both should be understood and explicitly recorded.2
Documenting of risks and nonrisks consists of
An architectural decision (or a decision that has not been made)
A specific quality attribute response that is being addressed by that decision along with the consequences of the predicted level of the response
A rationale for the positive or negative effect that decision has on meeting the quality attribute requirement
An example of a risk is
The rules for writing business logic modules in the second tier of your three-tier client-server style are not clearly articulated (a decision that has not been made). This could result in replication of functionality, thereby compromising modifiability of the third tier (a quality attribute response and its consequences). Unarticulated rules for writing the business logic can result in unintended and undesired coupling of components (rationale for the negative effect).
An example of a nonrisk is
Assuming message arrival rates of once per second, a processing time of less than 30 milliseconds, and the existence of one higher priority process (the architectural decisions), a one-second soft deadline seems reasonable (the quality attribute response and its consequences) since the arrival rate is bounded and the preemptive effects of higher priority processes are known and can be accommodated (the rationale).
For a nonrisk to remain a nonrisk the assumptions must not change (or at least if they change, the designation of nonrisk will need to be rejustified). For example, if the message arrival rate, the processing time, or the number of higher priority processes changes in the example above, the designation of nonrisk could change.
2.7.2 Outputs Only from the ATAM
In addition to the preceding information, the ATAM produces an additional set of results described below.
Catalog of Architectural Approaches Used
Every architect adopts certain design strategies and approaches to solve the problems at hand. Sometimes these approaches are well known and part of the common knowledge of the field; sometimes they are unique and innovative to the system being built. In either case, they are the key to understanding whether the architecture will meet its goals and requirements. The ATAM includes a step in which the approaches used are catalogued, and this catalog can later serve as an introduction to the architecture for people who need to familiarize themselves with it, such as future architects and maintainers for the system.
Approach- and Quality-Attribute-Specific Analysis Questions
The ATAM poses analysis questions that are based on the attributes being sought and the approaches selected by the architect. As the architecture evolves, these questions can be used in future mini-evaluations to make sure that the evolution is not taking the architecture in the wrong direction.
Sensitivity Points and Tradeoff Points
We term key architectural decisions sensitivity points and tradeoff points. A sensitivity point is a property of one or more components (and/or component relationships) that is critical for achieving a particular quality attribute response. For example:
The level of confidentiality in a virtual private network might be sensitive to the number of bits of encryption.
The latency for processing an important message might be sensitive to the priority of the lowest priority process involved in handling the message.
The average number of person-days of effort it takes to maintain a system might be sensitive to the degree of encapsulation of its communication protocols and file formats.
Sensitivity points tell a designer or analyst where to focus attention when trying to understand the achievement of a quality goal. They serve as yellow flags: "Use caution when changing this property of the architecture." Particular values of sensitivity points may become risks when realized in an architecture. Consider the examples above. A particular value in the encryption level—say, 32-bit encryption—may present a risk in the architecture. Or having a very low priority process in a pipeline that processes an important message may become a risk in the architecture.
A tradeoff point is a property that affects more than one attribute and is a sensitivity point for more than one attribute. For example, changing the level of encryption could have a significant impact on both security and performance. Increasing the level of encryption improves the predicted security but requires more processing time. If the processing of a confidential message has a hard real-time latency requirement then the level of encryption could be a tradeoff point. Tradeoff points are the most critical decisions that one can make in an architecture, which is why we focus on them so carefully.
Finally, it is not uncommon for an architect to answer an elicitation question by saying, "We haven't made that decision yet." In this case you cannot point to a component or property in the architecture and call it out as a sensitivity point because the component or property might not exist yet. However, it is important to flag key decisions that have been made as well as key decisions that have not yet been made.