Making Tradeoffs and Choices
30th of March 2018Last week I assisted an Architecture Kata for numerous consultants working at Ordina given by Bart Blommaerts. When the topic of architectural tradeoff popped up, it became clear to me that the approach to tradeoffs spearheaded by Carnegie Mellon’s Software Engineering Institute (SEI), called the Architecture Tradeoff Analysis Method (ATAM) was not on the radar of the attending people and wasn’t loved by those who did know about it. Trying to tackle the issue of awareness around ATAM at the kata, which would just have coopted the session, and made it all about this one topic, I decided to pick up the pen. Since it is proverbially mightier than the sword, this article should get the message across about what ATAM is trying to address during the architectural phase of a solution implementation.
Going back to the origins of ATAM, the method came to life because of a need to have a structured way to assess the fitness of an architectural solution when regarding non-functional attributes such as modifiability, security, performance, availability, and so forth … Basically, all the attributes specified in the ISO-25010 standard. The attributes in this standard interact with each other to strengthen or weaken their colleagues with each design choice. A well-known example of this interaction is the CAP Theorem. The principle idea of ATAM is to ask the proper questions about how their interaction should be, and to be able to ask these questions as soon as possible. It does so by using a spiral model of design, that consists of four major phases: scenario and requirements gathering, architectural views and scenario realization, model building and analysis, and tradeoffs. As shown on the illustration, these phases are then divided into different steps.
The first phase consists of collecting scenarios, requirements and constraints. By eliciting the scenarios from a representative group of stakeholders and/or key users, we get a list of functional requirements that describe the to-be solution. The requirements and constraints referred to by the model are the non-functional requirements and constraints that govern the environment in which the solution is to exist. This step is very similar to the initial version of the Requirements view from my approach to Solution Architecture, where the relevant functional, non-functional and operational requirements are listed to be crosschecked in later views.
Some projects include a Phase 0 for their ATAM efforts, where they list and analyze input that is already present in the project prior to the ATAM analyses. These inputs might include contract documents such as a Statement of Work, associated requirements documents already present in the organization (capability maps, technical constraints…) and/or a master schedule based on an enterprise roadmap or existing project planning. For my part, these inputs are to be gathered and analyzed during phase 1, and don’t really warrant an additional phase.
The second phase consists of describing and elaborating on the different candidate architectural possibilities, which roughly translates to the elaboration of the next views in my approach (logical, implementation, physical and operational view). It is where ATAM suggests comparing the multiple possible competing architectures, as well as list existing constraints from the actual situation of the environment (legacy systems, interoperability, success/failure rate of previous similar projects). ATAM also lays bare any implicit requirements that are derived from the assumptions of one candidate, when this is applied to other candidates.
Phase 3 only has one step to it: Attribute Specific Analyses. We look at each relevant quality attribute (or non-functional requirement) and analyze it in isolation of the other attributes for each of the listed architectural candidates. This separation of concerns aids individual attribute experts to leverage their expertise on the to-be solution.
The final phase of ATAM takes this list of quality attributes and attempts to identify sensitivities. ATAM was formed by a need for a rational choice between possible architectural candidates based on well-documented analyses of the requirements for necessitate the solution. By comparing the value analyses of the previous step, any quality attribute that is significantly affected by a change in architecture is considered a sensitivity. The tradeoff analysis is then done based on this list of sensitive quality attributes.
The method seems to imply that you should elaborate on all views for each architectural candidate, but that would take an inordinate amount of time. To be able to have a workable model, my approach to ATAM is to take the first two phases of the model incrementally, making minor changes to the overall architecture of choice, and then for each design choice that has alternatives, to iteratively apply phases 3 and 4 until a proper choice is decided upon. This is iteratively, since newer choices and elaboration might force you to revisit earlier choice that have been made.
Once a decision has been made, the reasoning behind it must be noted down in your Architectural Rationale section of the Solution Architecture Document, so that this decision can be revisited again when increasing insight in the to-be solution warrants that the decision is revisited. This revisitation will either adapt the values attributed to the quality attributes or introduce new (or previously ignored, rendering them from implicit to explicit) quality attributes to the decision process.
The steps described in the spiral model make up 7 of the 9 steps usually associated with ATAM. The additional 2 steps are taken more from an ATAM workshop point of view. These workshops start with a first step of elaborating ATAM to the audience attending the workshop. This is followed by the 7 steps elaborated in this article, and finally a final ninth step presents the findings to the appropriate stakeholders. Once the appropriate architecture candidate (or in our case design decision) is taken, this is reflected into the decision log and architectural deliverables.
SEI also published several other methodologies that could be used in conjunction with ATAM. For eliciting non-functional requirements, the Carnegie Mellon SEI has an accompanying method for ATAM called the Quality Attribute Workshop (QAW). Drawing up architecture candidates could be done by SEI’s Attribute-Driven Design (ADD). And analyzing the value attributes can be done with either a methodology called the Active Reviews for Intermediate Designs (ARID) or by using Cost Benefit Analysis Method (CBAM). However, despite the fact that these methodologies have a common starting point with similar concepts and steps, their integration has not yet been addressed in a formal manner (except for maybe linking ATAM with CBAM), and thus still leaves a lot of ground to be covered by SEI before really considering to use these other methodologies over my own way of working for functional and non-functional requirement evaluation.
Speaking of the connection with CBAM, a paper published by SEI does elaborate more on a possible integration between the two methods, stating an added value to ATAM. CBAM brings the return on investment (Remember WACC!) and economic tradeoffs into the picture, and adds a differentiation for the value attribute evaluation, changing it from a single response measure to a range of measures: worst case, best case, current case, desired case and expected case. This gives a more nuanced view on the candidate analyses, but takes a bit more effort. This is why it would be smart to limit this nuanced view to the differentiating value attributes when there is a time constraint on the ATAM exercise.
| Thought | Business Case |