Computer Systems & Architecture Lesson 5

1. Computer Systems & ArchitectureLesson 5 9. The ATAM

2. 9. The ATAM: A comprehensive Method for Architecture Evaluation Objectives • Explain the participants in the ATAM. • List the output of the ATAM based evaluation. • Discuss the phases of the ATAM based evaluation.

3. 9.1 Introduction • In this chapter, we will introduce the Architecture Tradeoff Analysis Method (ATAM), a through and comprehensive way to evaluate a software architecture. • The ATAM is so named because it reveals how well an architecture satisfies particular quality goals, and it provides insight into how quality goals interact – that is, how they trade off. • Evaluating an architecture for a large system is a complicated undertaking. First, a large system will have a comparably large architecture that will be difficult to understand in a limited amount of time.

4. Second, a computer system is intended to support business goals and the evaluation will need to make connections between these goals and the technical decisions. • Finally, a large system usually has multiple stakeholders and acquiring their different perspectives in a limited amount of time requires careful management of an evaluation process.

5. The ATAM is designed to elicit the business goals for the system as well as for the architecture. • It is also designed to use those goals and stakeholder participation to focus the attention of the evaluators on the portion of the architecture that is central to the architecture of the goals.

6. The ATAM requires the participation and mutual cooperation of three groups: The evaluation team: This group is external to the project whose architecture is being evaluated. It usually consists of three to five people. Each member of the team is assigned a number of specific roles to play during the evaluation. The evaluation team may be standing unit in which architecture evaluation are regularly performed, or its members may be chosen from a pool of architecturally savvy individuals for the occasion. 9.2 Participants in the ATAM

7. Project decision makers: These people are empowered to speak for the development project or have the authority to mandate changes to it. They usually include the project manager, and, if there is an identifiable customer who is footing the bill for the development. • Architectural stakeholders: Stakeholders have a vested interest in the architecture performing as advertised.

8. They are the ones whose ability to do their jobs hinges on the architecture promoting modifiability, security, high reliability or the like. Stakeholders include developers, testers, integrators, maintainers, performance engineers, users, builders of systems interacting with the one under consideration and others.

9. An ATAM-based evaluation will produce at least the following outputs: A concise presentation of the architecture. Architecture documentation is often thought to consist of the object model, a list of interfaces and their signatures, or some other voluminous list. Architecture of the business goals. Frequently, the business goals presented in the ATAM are being seen by some of the development team for the first time. 9.3 Outputs of the ATAM

10. Quality requirements in terms of a collection of scenarios. Business goals lead to quality requirements. Some of the important quality requirements are captured in the form of scenarios. • Mapping of architectured decisions to quality requirements. Architectural decisions can be interpreted in terms of the qualities that they support or hinder.

11. A set of identified sensitivity and tradeoff points. There are architectural decisions that have a marked effect on one or more quality attributes. Adopting a backup database. • A set of risks and nonrisks. A risk is defined in the ATAM as an architectural decision that may lead to undesirable consequences in light of stated quality attribute requirements.

12. A set of risk themes. When the analysis is complete, the evaluation team will examine the full set of discovered risks to look for over-arching themes that identify systemic weaknesses in the architecture or even in the architecture process and team.

13. Activities in an ATAM-based evaluation are spread out over four phases. In phase 0, ‘partnership and preparation’, the evaluation team leadership and the key project decision makers informally meet to work out the details of the exercise. The project representatives brief the evaluators about the project so that the team can be supplemented by people who posses the appropriate expertise. 9.4 Phases of the ATAM

14. In Phase 1,2 • Phase 1 and phase 2 are the evaluation phases, where everyone gets down to the business of analysis. • By now the evaluation team will have studied the architecture documentation and will have a good idea of what the system is about, the overall architectural approaches taken, and the quality attributes that are of paramount importance.

15. During phase 1, the evaluation team meets with the project decision makers to begin information gathering and analysis. • For phase 2, the architecture's stakeholders join the proceedings and analysis continues, typically for two days.

16. In Phase 3, • Phase 3 is follow up in which the evaluation team produces and delivers a written final report. The essence of this phase, however, is team self-examination and improvement. • During a post-mortem meeting, the team discusses what went well and what did not. They study the surveys handed out to participants during phase 1 and phase 2, and the process observer makes his or her report.

17. Steps of the evaluation process • The ATAM analysis phases consist of nine steps. Step 1 through 6 are carried in phase 1. In phase 2, with all stakeholders present, those steps are summarized and steps 7 through 9 are carried out. • Step 1 – Present the ATAM. • The first step calls for the evaluation leader to present the ATAM to the assembled project representatives.

18. This time is used to explain the process that everyone will be following, to answer questions, and to set the context and expectations for the remainder of the activities. • Using a standard presentation, the leader will describe the ATAM steps in brief and the outputs of the evaluation.

19. Step 2 – Present Business Drives. • Everyone involved in the evaluation – the project representatives as well as the evaluation team members – needs to understand the context for the system and the primary business drivers motivating its development. • In this step, a project decision maker presents a system overview from a business perspective.

20. The presentation should describe the following: • The system’s most important functions • Any relevant technical, managerial, economic or political constraints • The business goals and context as they relate to the project • The major stakeholders • The architectural drivers

21. Step 3 – Present architecture. • Here, the lead architect makes a presentation describing the architecture at an appropriate level of detail. • The ‘appropriate level’ depends on several factors: how much of the architecture has been designed and documented; how much time is available; and the nature of the behavioral and quality requirements.

22. Step 4 – Identify architectural approaches. • The ATAM focuses on analyzing an architecture by understanding its architectural approaches. • As we saw lesson 2, architectural patterns are useful for the known ways in which each one affects particular quality attributes. • A layered pattern tends to bring portability to a system, possibly at the expense of performance. A dada repository pattern is usually scalable in the number of producers and consumers of data.

23. Step 5 – Generate quality attribute utility tree. • An architecture is either suitable or unsuitable with respect to its ability to deliver particular quality attributes to the systems built from it. • The highest performance architecture may be totally wrong for a system in which performance is not nearly as important as, say security. • The important quality attribute goals for the architecture under consideration were named in step 2, when the business drivers were presented, but not to any degree of specificity that would permit analysis.

24. Step 6 – Analyze architectural approaches. • Here the evaluation team examines the highest ranked scenarios one at a time; the architect is asked to explain how the architecture supports each one. • Team members-especially the questioners-probe for the architectural approaches that the architect used to carry out the scenario. • Along the way, the team documents the relevant architectural decisions and identifies and catalogs their risks, nonrisks, sensitivity points and tradeoffs.

25. Step 7 – Brainstorm and prioritize scenarios. • While utility tree generation is used primarily to understand how the architect perceived and handled quality attribute architectural drivers, the purpose of scenario brainstorming is to take the pulse of the larger stakeholder community. • Scenario brainstorming works well in larger groups, creating an atmosphere in which the ideas and thoughts of one person stimulate others’ ideas. • The process fosters communication and creativity, and serves to express the collective mind of the participants.

26. Step 8 – Analyze architectural approaches. • After the scenarios have been collected and prioritizes, the evaluation team guides the architect in the process of carrying out the highest ranked scenarios from step 7. • The architect explains how relevant architectural decisions contribute to realizing each one. • Ideally this activity will be dominated by the architect’s explanation of scenarios in terms of previously discussed architectural approaches.

27. Step 9 – Present results. • Finally, the collected information from the ATAM needs to be summarized and presented once again to stakeholders. • This presentation typically takes the form of a verbal report accompanied by slides, but it might be accompanied by a more comprehensive written report delivered subsequent to the ATAM evaluation. • ATAM and all the information collected in the steps of the method, including the business context, driving requirements, constraints and architecture.

28. Then the following outputs are presented: • The architectural approaches documented. • The set of scenarios and their prioritization from the brainstorming • The utility tree • The risks discovered • The nonrisks documented • The sensitivity points and tradeoff points found

29. Limited time is one of the problem in conducting an architectural evaluation. Now we can see how the ATAM solves that problem. The business goals are used as motivation for the collection of scenarios that represent the utility tree. Other scenarios are prioritized, essentially, as a bottom-up check on the top-down scenario generation of the utility tree. Only the high-priority and difficult scenarios are analyzed. Using the limited time of an evaluation effectively