Analyzing an Architecture

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)

13. Evaluation Steps • 6 – Analyze Architectural Approaches • Focus on top priority scenarios first, then 2nd 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. CBAM • 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 • Bi = Sj(bi,j * Wj) • bi,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.