9. ATAM Phase 2

ATAM Phase 2

Bring the producers and consumers together to ensure that there are no discrepancies.

Write Risk Themes early at least start risk themes documentations early – and try to stick to 5. Not all risks map to a theme, there can be some outliers. The following are two groups of activities in Phase 2:

1. Testing – involves checking the results to date against the needs of all relevant stakeholders

2. Reporting –involves presenting the results of the ATAM

Phase 2 involves bottom-up information gathering and analysis.

- Consumers of the system

o End users

o Application builder

o External entities

- Servicers of the system

o System Admin

o Network Admin

o Maintainers

Review Step 1 -6 with the Phase 2 group. Why? This helps Step 7 because these materials are useful in brainstorming. Do not constrain the group, and changes can be made to the utility tree and other artifacts.

Note: Ask for any documentation (architecture) that was requested in Phase 1. Do accept new documentation created “just for Phase 2”. Just a new view, ensure that existing views are not changed/upgraded or modifying the architecture.

Risk Theme

A risk theme is a summarization of multiple similar risks discovered during the analysis of qualified attribute scenarios.

The point out bigger issues in the architecture and are

- Either Commission – i.e. multiple questionable decisions made in the architecture

- Or Omission – i.e. decisions NOT made or requirements not included in the architecture

E.g. Risk Theme: “There is no holistic approach to resource management…” Impacts Business Goals: “Cost, time-to-market, ability to compete with competitors”.

8. ATAM Scenario Documentation example

Scenario Documentation

The following are templates filled out for scenarios for illustration not completeness.

(H,H) Scenario	Port new to Operating System
Attributes	Portability
Environment	Operating system
Stimulus	New Device
Response	The developers deliver a production quality PAMD Image that supports new device within two months.
Architectural Decisions	Sensitivity	Tradeoff	Risk	Nonrisk

(H,H) Scenario	Port new hardware to existing infrastructure and operating system(s)>\.
Attributes	Portability
Environment	N/A for now
Stimulus	A new device is selected to inclusion into the ecosystem.
Response	PAMD developers deliver a production quality PAMD images is developed for the new device within 2 months (business) or 1 year (IT Arch). [Negotiated to 6 months between Business Owner and IT Architect]
Architectural Decisions	Sensitivity	Tradeoff	Risk	Nonrisk

(H,H) Scenario	Data type incompatibility
Attributes	Reliability
Environment	Run-time
Stimulus	The data type understood by the application changes, without an updated plug-in
Response	The system raises an error, informing the user that the data type is incompatible.
Architectural Decisions	Sensitivity	Tradeoff	Risk	Nonrisk

(H,H) Scenario	Loading PAMD plug-ins and applications
Attributes	Reliability
Environment
Stimulus	User loads 1 additional plug-in or applications that exceeds the system capacity limits.
Response	The system responds by loading the new plug-in or application without crashing.
Architectural Decisions	Sensitivity	Tradeoff	Risk	Nonrisk

Here is the clearest definitions I could come up with:

Risk – a clear risk to the architectural design relative to a single quality attribute.

Nonrisk – a good decision.

Tradeoff – two quality attributes are being balanced here.

Sensitivity Point – a single quality attribute is impacted by

7. ATAM Utility Tree Example

I think a utility tree is a visualization of quality attribute exposures for a given architecture, however it can get pretty cumbersome and the details will loose the big picture. In practice, it really depends on the people reading this and how well familiar they are. Chances are they will not be and the goal will be then for the architect to familiarize the stakeholders or create an alternate artifact.

5. ATAM Phase 0: Evaluation

 

Purpose: Partnership & Preparation: Usually present the ATAM to a small group. Get the Business Drivers.

Step 1: Purpose to ensure that the client understands the mechanics of the evaluation method; make sure the client understands the CBA of an architecture evaluation. Record questions for possible FAQ list. Consultants may write up work plans. 75 man days for evaluation team effort– duration best case is 3 weeks.

Step 2: Initial description of the candidate system. Client provides existing documentation describing the system. Client conveys main architectural drivers e.g. business goals, requirements, constraints etc.

Client and evaluation organization agree on necessary architecture documentation – “3 main views”.

NDA – for evaluation team is done at this step.

Evaluators record general business goals, quality attributes, architectural constraints and list of architecture documentation to be delivered to the evaluation team.

Step 3: Go/No-Go decision with respect to conducting ATAM.

Evaluation organization representatives understand the state of the architecture well enough to make a decision and ensure that the candidate system is ready for evaluation.

Evaluation team takes a look at the context drawing and multiple views of the system (e.g. run time etc.)

The list of named participants and their roles with respect to the system must be provided.

Step 4: SOW presentation and negotiation.

Step 5: Form core evaluation team. Aim for 4-6 evaluators.

Modifiability – coupling, encapsulation, contract based interactions, cohesion etc.

Step 6: Conduct evaluation team kick-off meeting.

Team Leader: establishes the time and place for the meeting.

Stickies on a board that can be grouped by risk themes are helpful…or use “Mind Maps”.

Tools like “Enterprise Architect” are used for evaluation in some companies.

Step 7: Prepare and Plan for Phase 1.

Review the purpose of the ATAM phases with the client.

Confirm the time and place for the evaluation for the client to present the system architecture & business goals, architect to present the system architecture and arrange for supplies.

Step 8: Preliminary review of the system’s software architecture.

Hold a brief post-mortem.

4. ATAM Phases Overview

 

There are 4 phases of the ATAM evaluation: Phase 0-3.

Phase 0: Partnership & Preparation

· Usually present the ATAM to a small group. Get the Business Drivers.

Phase 1: Initial Evaluation: Step 1-6

· Steps 1-5: We don’t pre-judge here. Just gather information and focus on the pros.

· Step 6: This is still phase 1. Ask questions about the architectural decisions, and do they map back to business drivers?

Phase 2: Complete Evaluation: Step 7-9

· Step 7: (Brainstorm & Prioritize) – Phase 2: Show Phase 1 scenarios, you recap.

· Step 8: Analyze Architectural Approaches: You have more stakeholders.

· Step 9: Report out

Phase 3: Follow-up