Markdown Editor

Architecture Evaluation Report Template (ATAM)

ATAM evaluation report – business drivers, approaches, utility tree, voted scenarios, sensitivity and trade-off points, risks, risk themes

아키텍처 및 시스템 설계전체SEI ATAMatamevaluation

사용법: Formal architecture evaluations before major commitments. Prepare sections 1 to 3 in advance; the scribe fills the rest live. Link every risk to a scenario and approach, and group risks into themes tied to business drivers – that is what management acts on.

미리보기

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

FieldValue
Report ID[ATAM-YYYY-NNN]
System evaluated[System name]
Architecture documentation evaluated[Document ID and version]
Evaluation datesPhase 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

RoleNameDecisionDate
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

VersionDateAuthorChange summary
0.1YYYY-MM-DD[@scribe]Raw outputs from phases 1 and 2
0.2YYYY-MM-DD[@leader]Example: Risk themes consolidated; architect comments addressed
1.0YYYY-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

ItemValue
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

PhaseActivityDateDuration
Phase 0Partnership and preparation: scope, logistics, documentation reviewYYYY-MM-DD[n] h
Phase 1Steps 1 to 6 with the architect and decision makersYYYY-MM-DD[n] h
Phase 2Steps 7 to 9 with the wider stakeholder groupYYYY-MM-DD[n] h
Phase 3Follow-up: report, review of outcomesYYYY-MM-DD[n] h

2.3 Participants

NameOrganisation / roleGroupPhases
[@name]Evaluation leaderEvaluation team0 to 3
[@name]Scribe, questionerEvaluation team1, 2
[@name]Lead architectProject decision makers1, 2
[@name]Product ownerProject decision makers1, 2
[@name]Operations managerStakeholders2
[@name]Security officerStakeholders2
[@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.]

IDBusiness driverQuality attributes implied
BD-1Example: Process instant payments 24/7 under the national schemeAvailability, latency
BD-2Example: Onboard new payment schemes within one quarterModifiability
BD-3Example: Pass regulatory audit on payment integritySecurity, auditability
[BD-n][Driver][Attributes]

3.2 Constraints

ConstraintTypeSource
Example: Must integrate with core banking via its existing message APITechnicalCore banking roadmap
Example: Go live by YYYY-MMScheduleScheme mandate
[Constraint][Type][Source]

4. Architecture presentation

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

View presentedContentAdequacy for evaluation
Example: ContextExternal systems and channelsAdequate
Example: Container / componentServices and data storesAdequate
Example: DeploymentSingle cloud region, two zonesAdequate
Example: RuntimePayment flow only, no failure flowsPartial: failover flows missing
[View][Content][Adequacy]

5. Architectural approaches

IDApproachQuality attributes addressedWhere applied
AP-1Example: Stateless services behind load balancer with auto-scalingAvailability, performanceOrchestration, gateway
AP-2Example: Synchronous replication across two zones for the ledgerAvailability, durabilityPayment ledger
AP-3Example: Plug-in connectors per payment schemeModifiabilityScheme connector
AP-4Example: Asynchronous core banking posting with retryAvailabilityCore banking adapter
AP-5Example: Mutual TLS and signed messagesSecurityAll 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.

IDQuality attributeRefinementScenarioImportanceDifficulty
U-01AvailabilityZone failureExample: One availability zone fails during peak; payments continue with no loss and under 30 s disruptionHM
U-02AvailabilityRegion failureExample: Entire cloud region unavailable; payment processing resumes within 15 minutesHH
U-03PerformanceLatencyExample: At 400 payments/s, 99% complete end to end within 5 sHM
U-04ModifiabilityNew schemeExample: Add a new instant payment scheme within 8 weeks without changing orchestrationMM
U-05SecurityMessage integrityExample: A tampered message from a channel is rejected and alerted within 1 minuteHL
[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⌉n = \lceil 0.3 \times N_{scenarios} \rceil, to distribute across the brainstormed scenarios.

IDScenarioTypeVotesIn utility treeSelected for analysis
S-01Example: Scheme connector receives a duplicate payment message after network partitionUse case9No (new)Yes
S-02Example: Payment volume triples on salary dayGrowth7U-03Yes
S-03Example: Regulator requires full audit trail retrieval within 24 hUse case6No (new)Yes
S-04Example: Move to a second cloud providerExploratory2NoNo
[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

ItemContent
ScenarioEntire cloud region unavailable; processing resumes within 15 minutes
AttributeAvailability
EnvironmentNormal operation, peak hours
StimulusRegion outage
Response measureRecovery within 15 minutes, no lost or duplicated payments
Approaches involvedAP-1, AP-2, AP-4
AnalysisExample: 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 pointsSP-01
Trade-off pointsTP-01
RisksR-01
Non-risksNR-01

8.2 Scenario S-01: duplicate payment after partition

ItemContent
ScenarioDuplicate payment message reaches the scheme connector
AttributeIntegrity
Approaches involvedAP-3, AP-4
AnalysisExample: 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 pointsSP-02
Trade-off pointsnone
RisksR-02
Non-risksnone

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

IDSensitivity pointAttribute affectedScenarioApproach
SP-01Example: Ledger replication mode (synchronous vs asynchronous)Availability, latencyU-02AP-2
SP-02Example: Scope of idempotency key propagationIntegrityS-01AP-4
[SP-nn][Property][Attribute][Scenario][AP-n]

9.2 Trade-off points

IDTrade-off pointAttributes in tensionScenarioApproach
TP-01Example: Cross-region synchronous replication improves recovery but adds 30 to 60 ms per paymentAvailability vs performanceU-02, U-03AP-2
[TP-nn][Property][Attribute vs attribute][Scenario][AP-n]

9.3 Risks

IDRiskScenarioApproachBusiness driver threatenedSeverity
R-01Example: Single-region deployment cannot meet the 15-minute regional recovery targetU-02AP-2BD-1High
R-02Example: Idempotency not end to end; duplicate payments possible on retryS-01AP-4BD-3High
R-03Example: No tracing across services; incidents detected lateS-03noneBD-1, BD-3Medium
[R-nn][Risk][Scenario][AP-n][BD-n][H / M / L]

9.4 Non-risks

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

10. Risk themes and business impact

ThemeDescriptionRisksBusiness drivers threatenedRecommended response
RT-1Example: Regional resilienceR-01BD-1Design and test a warm standby region; decide replication mode (TP-01)
RT-2Example: Payment integrity under failureR-02BD-3End-to-end idempotency keys with deduplication at the scheme connector
RT-3Example: Operational visibilityR-03BD-1, BD-3Distributed 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

IDActionAddressesOwnerDueStatus
ACT-01Example: Produce standby region design and cost estimateRT-1@architectYYYY-MM-DDOpen
ACT-02Example: Propagate idempotency keys to scheme connector; add deduplication storeRT-2@lead-devYYYY-MM-DDOpen
ACT-03Example: Add failure runtime views to architecture documentationDocumentation gap (section 4)@architectYYYY-MM-DDOpen
[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

IDScenarioTypeVotes
[S-nn][Scenario][Type][n]

12.2 Glossary

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

12.3 Documents reviewed

DocumentVersion
[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.

관련 템플릿