1. Analyzing an Architecture

2. Why analyze an architecture? Decide whether it solves the problem Compare to other architectures Assess what needs to change, given some major requirements change Find a problem

3. Methods ATAM – Architecture Trade-off Analysis CBAM – Cost Benefit Analysis Architecture Review

4. ATAM

5. ATAM Participants Evaluation Team Project Decision Makers Sponsor, Customer, Management Architecture Stakeholder Developers, Users, Testers, etc.

6. Evaluation Team Team Leader Evaluation Leader Scenario Scribe Proceedings Scribe Timekeeper Process Observer Process Enforcer Questioner

7. Outputs Concise presentation of the Architecture Articulation of Business Goals Quality Requirements – collection of scenarios Mapping of Architectural decisions to qualities Identified sensitivity and trade-off points Set of risks and non-risks Set of risk themes

8. Phases of ATAM 0 - Partnership and Preparation 1 – Evaluation 1 -- 1 day 2 TO 3 WEEKS BREAK HERE! 2 – Evaluation 2 – 2 days 4 – Follow-up -- 1 week

9. Evaluation Steps – Phase 1 1 - Present the ATAM 2 - Present Business Drivers Most important functions Constraints – technical, economic, political Business goals Major stakeholders Architectural drivers

10. Evaluation Steps 3 – Present Architecture (~20 slides; 60 minutes) 4 – Identify Architectural Approaches 5 – Quality Attribute Utility Tree

11. Quality attribute utility tree Top level: quality attributes Second level: attribute sub-categories (or, scenario groupings if you think bottom- up) Third level: quality attribute scenarios For each scenario, two priority rankings (H/M/L): Importance Architect’s estimate of difficulty See pp 296-297

12. Scenario priority hierarchy (Don’s) HHTop HM, MHSecond level MMTime permitting HL, ML, LLIgnore (you won't have time anyway, and they aren't hard to build) LH, LMWhy would you implement this in the first place?

13. Evaluation Steps 6 – Analyze Architectural Approaches Focus on top priority scenarios first, then 2 nd level, … Understand the architectural decisions made for the scenario, and the consequences For each architectural decision, generate lists of  Sensitivity points (scenarios influenced by the decision)  Tradeoff points (one scenario helped, another one hurt) For each sensitivity point and each tradeoff, decide whether it is a risk or non-risk

14. Sensitivities and tradeoffs: examples Sensitivities Configuration files: good for modifiability Virtual machine: good for portability Virtual machine: bad for performance Virtual machine is also a tradeoff point, because it is good for at least one attribute and bad for at least one other

15. Evaluation Steps – Phase 2 7 – Brainstorm and prioritize scenarios 8 - Analyze Architectural Approaches 9 – Present Results

16. CBAM

17. Goal of CBAM is quantifying decisions Utility – a measure of value Cost – to implement a given strategy Use outputs of ATAM This is a subjective process!

18. Scenario For each scenario of ATAM: Generate a set of scenarios The set has a range of responses The response measure needs to be quantified

19. Assign Utility Values This can be hard! Look at plots in text (pg. 311) Start by establishing worst-case and best- case limits (0 and 100) They also tried to find a current and desired value

20. Priorities Prioritize the scenarios in order first The add a weight for each one

21. Architectural Strategies Expected value of the response (Interpolate on the plot) Effect on other attributes Cost to implement

22. Benefit B i =  j  (b i,j * W j ) b i,j expected change in utility with respect to scenario j as a result of using strategy i. W is weight of scenarios

23. ROI R = B / C

24. Summary ATAM and CBAM provide structure CBAM can be hard, since quantification is called for! Next week we consider a less structured alternative.