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.
Document control
| 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
| 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
[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
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
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
The architect presented the following views; the context is summarised
below.
| 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
| 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
The utility tree below summarises the attributes and refinements; the
table lists the scenarios with their ratings.
| 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
Each stakeholder received [n] votes, where n=⌈0.3×Nscenarios⌉, 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
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
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
| 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
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
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.