# Architecture Evaluation Report (ATAM): [System name]

> Report of a scenario-based architecture evaluation following the
> Architecture Tradeoff Analysis Method (ATAM) developed at the Software
> Engineering Institute, Carnegie Mellon University. It records the
> business drivers, the architecture as presented, the quality attribute
> utility tree, prioritised scenarios, the analysis of architectural
> approaches, and the resulting sensitivity points, trade-off points, risks,
> non-risks and risk themes. Replace every `[bracketed]` value and every row
> marked *Example*.

<!--
Guidance: How to use this template
- Fill sections 1 to 3 during preparation and the first evaluation day;
  sections 4 to 9 are filled live by the scribe and cleaned up afterwards.
- Every risk, sensitivity point and trade-off point must reference the
  scenario and the architectural approach it came from. Unlinked findings
  cannot be acted on.
- Risk themes (section 10) are the most important output for management:
  group risks into a few themes and say which business driver each theme
  threatens.
- The evaluation team assesses the architecture; it does not redesign it.
  Record suggestions as next steps, not as decisions.
-->

## Document control

<!-- Guidance: Identify the evaluation, the architecture version evaluated, and who sponsored it. -->

| Field | Value |
|---|---|
| Report ID | [ATAM-YYYY-NNN] |
| System evaluated | [System name] |
| Architecture documentation evaluated | [Document ID and version] |
| Evaluation dates | Phase 1: YYYY-MM-DD; Phase 2: YYYY-MM-DD |
| Report version | [0.1] |
| Status | [Draft / Final] |
| Evaluation leader | [@name] |
| Sponsor | [@name] |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Evaluation leader | [@name] | [Approved / Approved with comments] | YYYY-MM-DD |
| Project decision maker | [@name] | [Accepted / Accepted with comments] | YYYY-MM-DD |
| Lead architect of evaluated system | [@name] | [Reviewed] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Track the draft shared after the evaluation and the final report. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@scribe] | Raw outputs from phases 1 and 2 |
| 0.2 | YYYY-MM-DD | [@leader] | *Example:* Risk themes consolidated; architect comments addressed |
| 1.0 | YYYY-MM-DD | [@leader] | *Example:* Final report issued to sponsor |

## Contents

1. [Executive summary](#1-executive-summary)
2. [Evaluation context and participants](#2-evaluation-context-and-participants)
3. [Business drivers](#3-business-drivers)
4. [Architecture presentation](#4-architecture-presentation)
5. [Architectural approaches](#5-architectural-approaches)
6. [Quality attribute utility tree](#6-quality-attribute-utility-tree)
7. [Scenario brainstorm and prioritisation](#7-scenario-brainstorm-and-prioritisation)
8. [Analysis of architectural approaches](#8-analysis-of-architectural-approaches)
9. [Findings: sensitivity points, trade-offs, risks, non-risks](#9-findings-sensitivity-points-trade-offs-risks-non-risks)
10. [Risk themes and business impact](#10-risk-themes-and-business-impact)
11. [Conclusions and next steps](#11-conclusions-and-next-steps)
12. [Appendices](#12-appendices)

## 1. Executive summary

<!-- Guidance: One page for the sponsor: what was evaluated, the main risk themes, and recommended actions. No method detail. -->

[Example: "On YYYY-MM-DD and YYYY-MM-DD, eleven stakeholders and a
four-person evaluation team evaluated the architecture of the Payments
Hub against 34 scenarios. The architecture handles throughput and
modifiability scenarios well. Three risk themes threaten the business
drivers: (1) single-region dependencies undermine the 99.99% availability
goal, (2) the absence of end-to-end idempotency risks duplicate payments
during failover, and (3) observability is insufficient to meet the
15-minute incident detection target. Twelve risks are recorded; seven
actions are recommended in section 11."]

## 2. Evaluation context and participants

<!-- Guidance: Record why the evaluation was held, its scope and constraints, and who took part in which role. -->

### 2.1 Purpose and scope

| Item | Value |
|---|---|
| Reason for evaluation | [Example: Pre-implementation review before committing to vendor contracts] |
| Lifecycle stage | [Concept / Design / Implemented / Evolution] |
| In scope | [Example: Payments Hub services, data stores, integration with core banking] |
| Out of scope | [Example: Mobile apps, card issuing] |
| Constraints | [Example: Two days of stakeholder time; no access to production metrics] |

### 2.2 Phases held

| Phase | Activity | Date | Duration |
|---|---|---|---|
| Phase 0 | Partnership and preparation: scope, logistics, documentation review | YYYY-MM-DD | [n] h |
| Phase 1 | Steps 1 to 6 with the architect and decision makers | YYYY-MM-DD | [n] h |
| Phase 2 | Steps 7 to 9 with the wider stakeholder group | YYYY-MM-DD | [n] h |
| Phase 3 | Follow-up: report, review of outcomes | YYYY-MM-DD | [n] h |

### 2.3 Participants

| Name | Organisation / role | Group | Phases |
|---|---|---|---|
| [@name] | Evaluation leader | Evaluation team | 0 to 3 |
| [@name] | Scribe, questioner | Evaluation team | 1, 2 |
| [@name] | Lead architect | Project decision makers | 1, 2 |
| [@name] | Product owner | Project decision makers | 1, 2 |
| [@name] | Operations manager | Stakeholders | 2 |
| [@name] | Security officer | Stakeholders | 2 |
| [@name] | [Role] | [Group] | [Phases] |

## 3. Business drivers

<!-- Guidance: Summarise the business presentation: goals, constraints, key quality attributes and the architectural drivers that follow. These drive the utility tree and later judge the risk themes. -->

### 3.1 Business goals and context

[Summary of the presentation by the project manager or sponsor: market,
customers, business goals, timeline, and why the system matters.]

| ID | Business driver | Quality attributes implied |
|---|---|---|
| BD-1 | *Example:* Process instant payments 24/7 under the national scheme | Availability, latency |
| BD-2 | *Example:* Onboard new payment schemes within one quarter | Modifiability |
| BD-3 | *Example:* Pass regulatory audit on payment integrity | Security, auditability |
| [BD-n] | [Driver] | [Attributes] |

### 3.2 Constraints

| Constraint | Type | Source |
|---|---|---|
| *Example:* Must integrate with core banking via its existing message API | Technical | Core banking roadmap |
| *Example:* Go live by YYYY-MM | Schedule | Scheme mandate |
| [Constraint] | [Type] | [Source] |

## 4. Architecture presentation

<!-- Guidance: Summarise what the architect presented: context, main views, technology and how the architecture addresses the drivers. Note gaps in the documentation that limited the evaluation. -->

The architect presented the following views; the context is summarised
below.

```mermaid
flowchart LR
  bank[Bank channels] --> gw[API gateway]
  gw --> hub[Payment orchestration]
  hub --> fraud[Fraud screening]
  hub --> ledger[(Payment ledger)]
  hub --> sch[Scheme connector]
  sch --> scheme[National payment scheme]
  hub --> core[Core banking adapter]
```

| View presented | Content | Adequacy for evaluation |
|---|---|---|
| *Example:* Context | External systems and channels | Adequate |
| *Example:* Container / component | Services and data stores | Adequate |
| *Example:* Deployment | Single cloud region, two zones | Adequate |
| *Example:* Runtime | Payment flow only, no failure flows | Partial: failover flows missing |
| [View] | [Content] | [Adequacy] |

## 5. Architectural approaches

<!-- Guidance: List the patterns, tactics and styles the architect uses to achieve quality attributes. These are what section 8 analyses. -->

| ID | Approach | Quality attributes addressed | Where applied |
|---|---|---|---|
| AP-1 | *Example:* Stateless services behind load balancer with auto-scaling | Availability, performance | Orchestration, gateway |
| AP-2 | *Example:* Synchronous replication across two zones for the ledger | Availability, durability | Payment ledger |
| AP-3 | *Example:* Plug-in connectors per payment scheme | Modifiability | Scheme connector |
| AP-4 | *Example:* Asynchronous core banking posting with retry | Availability | Core banking adapter |
| AP-5 | *Example:* Mutual TLS and signed messages | Security | All external interfaces |
| [AP-n] | [Approach] | [Attributes] | [Elements] |

## 6. Quality attribute utility tree

<!-- Guidance: Refine "utility" into quality attributes, refinements and concrete scenarios. Rate each scenario on importance to the business and difficulty for the architecture as (H/M/L, H/M/L). (H,H) scenarios get analysed first. -->

The utility tree below summarises the attributes and refinements; the
table lists the scenarios with their ratings.

```mermaid
flowchart LR
  U[Utility] --> A[Availability]
  U --> P[Performance]
  U --> M[Modifiability]
  U --> S[Security]
  A --> A1[Zone failure]
  A --> A2[Region failure]
  P --> P1[Latency]
  M --> M1[New scheme]
  S --> S1[Message integrity]
```

| ID | Quality attribute | Refinement | Scenario | Importance | Difficulty |
|---|---|---|---|---|---|
| U-01 | Availability | Zone failure | *Example:* One availability zone fails during peak; payments continue with no loss and under 30 s disruption | H | M |
| U-02 | Availability | Region failure | *Example:* Entire cloud region unavailable; payment processing resumes within 15 minutes | H | H |
| U-03 | Performance | Latency | *Example:* At 400 payments/s, 99% complete end to end within 5 s | H | M |
| U-04 | Modifiability | New scheme | *Example:* Add a new instant payment scheme within 8 weeks without changing orchestration | M | M |
| U-05 | Security | Message integrity | *Example:* A tampered message from a channel is rejected and alerted within 1 minute | H | L |
| [U-nn] | [Attribute] | [Refinement] | [Scenario: stimulus, environment, response, measure] | [H / M / L] | [H / M / L] |

## 7. Scenario brainstorm and prioritisation

<!-- Guidance: Phase 2 stakeholders brainstorm use case, growth and exploratory scenarios, then vote. Compare the top-voted scenarios with the utility tree; new high-priority scenarios not in the tree show a gap in the architect's understanding. -->

Each stakeholder received [n] votes, where $n = \lceil 0.3 \times N_{scenarios} \rceil$, to distribute across the brainstormed scenarios.

| ID | Scenario | Type | Votes | In utility tree | Selected for analysis |
|---|---|---|---|---|---|
| S-01 | *Example:* Scheme connector receives a duplicate payment message after network partition | Use case | 9 | No (new) | Yes |
| S-02 | *Example:* Payment volume triples on salary day | Growth | 7 | U-03 | Yes |
| S-03 | *Example:* Regulator requires full audit trail retrieval within 24 h | Use case | 6 | No (new) | Yes |
| S-04 | *Example:* Move to a second cloud provider | Exploratory | 2 | No | No |
| [S-nn] | [Scenario] | [Use case / Growth / Exploratory] | [n] | [U-nn / No] | [Yes / No] |

Observation: [Example: "Two of the three top-voted scenarios were not in
the utility tree, both about payment integrity under failure, indicating
that integrity concerns were underrepresented in the architecture
presentation."]

## 8. Analysis of architectural approaches

<!-- Guidance: For each high-priority scenario, walk through how the architecture responds, which approaches are involved, and record the findings. One table per scenario keeps the trail clear. -->

### 8.1 Scenario U-02: region failure

| Item | Content |
|---|---|
| Scenario | Entire cloud region unavailable; processing resumes within 15 minutes |
| Attribute | Availability |
| Environment | Normal operation, peak hours |
| Stimulus | Region outage |
| Response measure | Recovery within 15 minutes, no lost or duplicated payments |
| Approaches involved | AP-1, AP-2, AP-4 |
| Analysis | *Example:* All services and the ledger are deployed in one region. AP-2 protects against zone failure only. Recovery to another region relies on restoring backups, estimated at 4 h. |
| Sensitivity points | SP-01 |
| Trade-off points | TP-01 |
| Risks | R-01 |
| Non-risks | NR-01 |

### 8.2 Scenario S-01: duplicate payment after partition

| Item | Content |
|---|---|
| Scenario | Duplicate payment message reaches the scheme connector |
| Attribute | Integrity |
| Approaches involved | AP-3, AP-4 |
| Analysis | *Example:* Idempotency keys exist at the API gateway but are not propagated to the scheme connector; a retry after timeout can submit a second payment. |
| Sensitivity points | SP-02 |
| Trade-off points | none |
| Risks | R-02 |
| Non-risks | none |

### 8.3 Further scenarios

[Repeat the table for each scenario selected in sections 6 and 7. Record
"not analysed" with a reason for any high-priority scenario that time did
not allow.]

## 9. Findings: sensitivity points, trade-offs, risks, non-risks

<!-- Guidance: A sensitivity point is a design property that strongly affects one quality attribute. A trade-off point affects several attributes in opposite directions. A risk is a potentially problematic decision; a non-risk is a good decision that relies on stated assumptions. -->

### 9.1 Sensitivity points

| ID | Sensitivity point | Attribute affected | Scenario | Approach |
|---|---|---|---|---|
| SP-01 | *Example:* Ledger replication mode (synchronous vs asynchronous) | Availability, latency | U-02 | AP-2 |
| SP-02 | *Example:* Scope of idempotency key propagation | Integrity | S-01 | AP-4 |
| [SP-nn] | [Property] | [Attribute] | [Scenario] | [AP-n] |

### 9.2 Trade-off points

| ID | Trade-off point | Attributes in tension | Scenario | Approach |
|---|---|---|---|---|
| TP-01 | *Example:* Cross-region synchronous replication improves recovery but adds 30 to 60 ms per payment | Availability vs performance | U-02, U-03 | AP-2 |
| [TP-nn] | [Property] | [Attribute vs attribute] | [Scenario] | [AP-n] |

### 9.3 Risks

| ID | Risk | Scenario | Approach | Business driver threatened | Severity |
|---|---|---|---|---|---|
| R-01 | *Example:* Single-region deployment cannot meet the 15-minute regional recovery target | U-02 | AP-2 | BD-1 | High |
| R-02 | *Example:* Idempotency not end to end; duplicate payments possible on retry | S-01 | AP-4 | BD-3 | High |
| R-03 | *Example:* No tracing across services; incidents detected late | S-03 | none | BD-1, BD-3 | Medium |
| [R-nn] | [Risk] | [Scenario] | [AP-n] | [BD-n] | [H / M / L] |

### 9.4 Non-risks

| ID | Non-risk | Scenario | Assumption it relies on |
|---|---|---|---|
| NR-01 | *Example:* Zone failure is handled transparently by AP-1 and AP-2 | U-01 | Cloud provider zone isolation holds |
| NR-02 | *Example:* New schemes can be added as plug-ins without orchestration changes | U-04 | Schemes follow the ISO 20022 message family |
| [NR-nn] | [Non-risk] | [Scenario] | [Assumption] |

## 10. Risk themes and business impact

<!-- Guidance: Group related risks into a handful of themes and link each theme to the business drivers it threatens. This is the section decision makers act on. -->

| Theme | Description | Risks | Business drivers threatened | Recommended response |
|---|---|---|---|---|
| RT-1 | *Example:* Regional resilience | R-01 | BD-1 | Design and test a warm standby region; decide replication mode (TP-01) |
| RT-2 | *Example:* Payment integrity under failure | R-02 | BD-3 | End-to-end idempotency keys with deduplication at the scheme connector |
| RT-3 | *Example:* Operational visibility | R-03 | BD-1, BD-3 | Distributed tracing and payment-level audit search |
| [RT-n] | [Theme] | [R IDs] | [BD IDs] | [Response] |

## 11. Conclusions and next steps

<!-- Guidance: State the overall conclusion in plain words and list actions with owners. The evaluation team recommends; the project decides. -->

### 11.1 Conclusion

[Example: "The architecture is well suited to the performance and
modifiability goals. It does not yet meet the availability and integrity
goals under regional failure and retry conditions. With the actions below
completed, the evaluation team considers the architecture fit for
purpose."]

### 11.2 Action plan

| ID | Action | Addresses | Owner | Due | Status |
|---|---|---|---|---|---|
| ACT-01 | *Example:* Produce standby region design and cost estimate | RT-1 | @architect | YYYY-MM-DD | Open |
| ACT-02 | *Example:* Propagate idempotency keys to scheme connector; add deduplication store | RT-2 | @lead-dev | YYYY-MM-DD | Open |
| ACT-03 | *Example:* Add failure runtime views to architecture documentation | Documentation gap (section 4) | @architect | YYYY-MM-DD | Open |
| [ACT-nn] | [Action] | [RT / R IDs] | [@owner] | YYYY-MM-DD | [Open / Done] |

### 11.3 Evaluation feedback

[Participants' feedback on the evaluation process, effort spent per
group, and lessons for the next evaluation.]

## 12. Appendices

<!-- Guidance: Full scenario list, glossary and the documents reviewed. -->

### 12.1 Full list of brainstormed scenarios

| ID | Scenario | Type | Votes |
|---|---|---|---|
| [S-nn] | [Scenario] | [Type] | [n] |

### 12.2 Glossary

| Term | Meaning in this report |
|---|---|
| Utility tree | Hierarchy from overall utility to quality attributes, refinements and rated scenarios |
| Sensitivity point | Architectural property to which a quality attribute response is highly sensitive |
| Trade-off point | Property that is a sensitivity point for more than one attribute, with opposing effects |
| Risk theme | Group of related risks that together threaten a business driver |
| [Term] | [Meaning] |

### 12.3 Documents reviewed

| Document | Version |
|---|---|
| [Architecture document] | [x.y] |
| [Requirements or business case] | [x.y] |

## Standard and licence note

Based on the Architecture Tradeoff Analysis Method (ATAM) published by
the Software Engineering Institute, Carnegie Mellon University: phases,
business drivers, utility tree, scenario prioritisation, analysis of
architectural approaches, sensitivity and trade-off points, risks,
non-risks and risk themes. This template is original text written for this
collection and reproduces no text from SEI publications. ATAM is a method
of Carnegie Mellon University. Template licence: MIT.