Evaluating Architectural Options

Simon Field

Chief Technology Officer

The development lifecycle context

First Architecture Review

Second Architecture Review

Architecture Trade-off Analysis Method

• Developed by:Software Engineering Institute, Carnegie Mellon University

• Sponsored by the US Department of Defense• Review team develop a utility tree showing trade-off

among quality attributes for solution options

• References:ATAM:Method for Architecture Evaluation (technical report from Software

Engineering Institute, CMU)

Evaluating Software Architectures by Paul Clements, Rick Kazman and Mark Klein

Review Structure

• Completion of Matrix 1• Review preparation• The Review workshop

Describe business problem

Outline solution options

Review Matrix 1

Populate Matrices 2 & 3

Throughout: build list of issues, mitigations etc.

• Write Report

Duration of workshop varies from ½ day to 2 days depending on size and complexity of project

Governance

• Reviews mandated in ONSide development method• Conducted on behalf of the ONS Architecture Review

Board (ARB)• Report signed of by ARB• Accepted in writing by Project Board / Project

Manager, or contested in an “appeal”• Appeal heard by the ONS IM Committee (on behalf of

the Executive Management Group)

Matrix 1 – Quality Attributes

Relates quality attributes to project business requirements

Timeliness Performance Security Connectability

Business Requirement 1 Business Requirement 2 Business Requirement 3Business Requirement 4 Business Requirement 5 Business Requirement 6 Business Requirement 7 Business Requirement 8 Business Requirement 9 Business Requirement 10 Business Requirement 11 Business Requirement 12 Business Requirement 13 Business Requirement 14 Business Requirement 15 Business Requirement 16 Key: = relationship = strong relationship

Architectural Design GoalsBusiness Requirements

Matrix 2 – Risk Trade-off

Examines risk of failure to achieve each business requirement for each solution option

Business Requirements

Likelihood x Impact Exposure

Likelihood x Impact Exposure

Likelihood x Impact Exposure

Likelihood x Impact Exposure

Likelihood x Impact Exposure

Business Requirement 1 3 x 4 12 2 x 4 8 1 x 4 4 2 x 4 8 2 x 4 8

Business Requirement 2 1 x 4 4 4 x 4 16 4 x 4 16 4 x 4 16 4 x 4 16

Business Requirement 3 3 x 6 18 2 x 6 12 2 x 6 12 1 x 6 6 1 x 6 6

Business Requirement 4 1 x 3 3 2 x 3 6 1 x 3 3 2 x 3 6 2 x 3 6

Business Requirement 5 2 x 4 8 1 x 4 4 1 x 4 4 2 x 4 8 3 x 4 12

Business Requirement 6 2 x 6 12 1 x 6 6 1 x 6 6 1 x 6 6 1 x 6 6

Business Requirement 7 2 x 4 8 2 x 4 8 2 x 4 8 1 x 4 4 1 x 4 4

Business Requirement 8 4 x 3 12 3 x 3 9 3 x 3 9 4 x 3 12 1 x 3 3

Business Requirement 9 N/A N/A N/A N/A N/A

Business Requirement 10 N/A N/A N/A N/A N/A

Business Requirement 11 2 x 6 12 2 x 6 12 2 x 6 12 1 x 6 6 1 x 6 6

Business Requirement 12 3 x 3 9 2 x 3 6 1 x 3 3 2 x 3 6 2 x 3 6

Business Requirement 13 1 x 3 3 4 x 3 12 4 x 3 12 4 x 3 12 4 x 3 12

Business Requirement 14 2 x 3 6 2 x 3 6 2 x 3 6 2 x 3 6 1 x 3 3

Business Requirement 15 2 x 6 12 3 x 6 18 2 x 6 12 3 x 6 18 2 x 6 12

Business Requirement 16 N/A N/A N/A

Total 119 123 107 114 100

Approach EApproach A Approach B Approach C Approach D

Matrix 3 – Architectural Fit

Examines extent to which each solution option satisfies a selected set of key architectural principles

Scoring Guide 0=Doesn't meet principle, 3=Falls short of principle, 5= Satisfactory/Compliant, 7=-Good/Very Good, 10=Fully meets principle/goes beyond it

Principle Approach A Approach B Approach C Approach D Approach E

Reusability3 5 5 5 7

Integrability0 3 3 5 5

Serviceability5 5 5 3 3

Corporate Asset3 5 5 3 5

Security5 5 5 7 10

TOTAL16 23 23 23 30

Conclusions

• Structured reviews help you:get the right focus on all requirements (including

NFRs)

select the right architecture for each project

steer projects towards your corporate vision

reduce project risk and costs

• Make sure you get the governance right• Involve the right stakeholders• Link to existing corporate methods and

processes