Maybe you have been wondering what you have to do as an architect of a software-reliant system to get ready for an SEI Architecture Tradeoff Analysis Method (ATAM) architecture evaluation. Maybe, like me, you hate to be taken by surprise and want to know the outcome of the ATAM upfront. Hmmmm … so, you too are thinking about a strategy on how to “game the system,” right? Well, here is how I do it.
First of all, let us accept the fact that nobody can build an architecture without weaknesses. We just don’t get enough time, money, or the right technology to do a perfect job. And of course, the ATAM will uncover all those weaknesses. If you get a well-trained ATAM team you can be assured that they will find most of those weaknesses. You cannot hide anything from them. So, don’t even try.
Let’s take the bull by the horns. To me the best way to deal with an ATAM is to provide the ATAM results upfront, before the ATAM actually starts. Usually there are pretty good reasons why your architecture has weaknesses, e.g., your project manager doesn’t give you enough resources. You already tried to communicate that but, as usual, nobody listens. Well, maybe they do, but they have their reasons to ignore your comment. So, let’s make the case why the architecture is as it is and what the reasons are that made it what it is.
With a few changes or additions to the architecture-design process, we can actually produce the ATAM artifacts with very little additional effort. I don’t really want to prescribe to you what design process to use. I assume you have some kind of process that results in the definition of the necessary structures with their properties. Let me call this a “structure-oriented” process.
Please recall that ATAM is scenario based, meaning the evaluators will pick scenarios and ask you for evidence in the architecture that those scenarios are supported. This asks for “scenario-based” documentation that shows only those parts of the architecture, structure, and behavior required for a scenario. Producing this “scenario-oriented” documentation may not be part of your architecture-design process and might be a little additional (worthwhile!) work for you.
Now let us go through the ATAM process and see what we can do to prepare for it. The ATAM team will elicit scenarios from the stakeholders. No reason why we cannot do that too. And actually, we already should have a set of quality attribute scenarios as input to the architecture design. Maybe we had a Quality Attribute Workshop (QAW); or if not, we asked our stakeholders to give us the scenarios that are important to them.
With the scenarios at hand, we can use them to drive our design process. What does that mean? To understand the architecture, the ATAM team will ask for the architecture approaches used. To support a scenario, we always ask ourselves: “What do we need to do in the architecture to make this scenario happen?” The answer to this question is what the ATAM calls architecture approaches or architecture decisions. So, instead of just thinking about what approaches to use, let us write them down. I personally create an “evidence chart” in my favorite design tool that is assigned to the scenario. In this evidence chart I pull all the information together that is specific to this scenario. At the end, when I believe this scenario is fulfilled, I have all the information ready for the ATAM on this evidence chart.
So, the first information in the evidence chart is the list of architecture approaches that will be used to provide support in the architecture for this scenario. The next step is to think about structures either in runtime views (Component & Connectors) if the scenario is concerned with a runtime quality attribute, or a code view (Modules) if the quality attribute is concerned about code changes. In most cases, I create a new diagram (C&C or Module) specifically for the current quality attribute scenario that describes what structures I put in place, using the architecture approaches mentioned above. By doing so, I make more detailed decisions that are written down immediately in the scenario’s evidence chart as an architecture decision.
Creating separate diagrams for scenarios makes it easier to track what was done in the architecture for a single scenario. However if the changes in the already existing architecture for a specific scenario are minor, I might use an existing diagram and put notes in it to mark the changes for this scenario. In any case, all the diagrams produced for the scenario must be explicit in the evidence diagram. My tool allows me to create links pointing to diagrams within a diagram. I link all the scenario-specific diagrams to my evidence diagram for easy navigation. Very impressive to your managers when they see how you can answer the ATAM team’s questions with one click!
After the structure looks sound, I start creating sequence charts describing the flow of interactions and information between the architectural elements to fulfill the scenario. This again is to prepare for the evaluation, because the typical opening question for the analysis part of the ATAM is: “Show me what the architecture does to support this scenario.” So, I take the sequence charts and walk the evaluators through them. Needless to mention, I link the sequence charts in my evidence diagram.
During the creation of the sequence diagram, I may have found that I made mistakes: wrong assumptions. If so, I will revise the design and add more information and/or rationale to the evidence diagram. As you can imagine, if the evaluation of alternative solutions are required for a scenario, I will create alternative diagrams with notes in them describing the solutions. All of them will be linked in the evidence diagram with notes that explain why the selected solution is preferable.
Only one thing is missing: the list of risks and tradeoffs. Every solution has risks, and there is nothing wrong with them. The bad part of risks is not knowing them. You don’t have to be afraid to show the risks that come with your design as long as you can show how to tackle them later or that those are risks your organization can easily live with. A good way to produce the list of risks and tradeoffs is to have peer reviews. Tell your fellow architects you invite for a peer review to put on their ATAM-evaluator hats and challenge your design. Everything that is unknown, unclear, or might cause problems is written down as a risk in either the evidence diagram or in some other document linked to the evidence diagram.
That’s it. If you now take an evidence diagram of a scenario, with all the attached information, you can use it to inform your managers and stakeholders about the architecture before the ATAM evaluation starts. This shows competence! The side effect is that, if you did a good job, there shouldn’t be too many surprises during the ATAM. Therefore, the evidence chart builds the scenario-oriented view of the architecture documentation that would also support the ATAM evaluation process.
- Felix Bachmann