# Architecture Evaluation Plan and Report: [Architecture or system name]

> Plan and report for one architecture evaluation, organised on the architecture evaluation
> framework of ISO/IEC/IEEE 42030:2019 (*Software, systems and enterprise: Architecture evaluation
> framework*, first edition, still current; ISO lists it as "to be revised" (stage 90.92 since
> 2026-01-08), and a second edition, *Enterprise, systems and software: Architecture evaluation
> framework*, is registered as work item AWI 42030 since 2026-05-22). It records why the evaluation is done, the objectives and factors, the approach and
> methods (with ATAM as a plug-in analysis method), the architectural analysis, the value
> assessment, the synthesis of results, findings, recommendations, confidence and follow-up.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- One file per evaluation effort. Sections 1 to 6 are the evaluation plan (approve them before
  evidence is collected); sections 7 to 12 are the evaluation report. You may split them into two
  documents that share the same Document ID.
- 42030 evaluates the architecture itself (its fitness, value and quality), not the quality of the
  architecture description. To review the description, use Architecture Description
  (`architecture/architecture-description-42010`) section 8 or an active design review such as
  ARID Design Review (`architecture/arid-design-review`).
- Keep the three tiers separate: architectural analysis (section 7) establishes facts, value
  assessment (section 8) judges what those facts are worth to stakeholders, and evaluation
  synthesis (section 9) combines both into conclusions for a decision.
- Every finding must trace back to an objective. Section 12 holds the traceability matrix; an
  objective with no result means the evaluation is incomplete.
- Clause numbers refer to ISO/IEC/IEEE 42030:2019. Headings and explanations are original
  wording; obtain the standard for its normative requirements.
-->
## Document control

<!-- Guidance: Identify the evaluation separately from the architecture it evaluates. Name the evaluation authority (the person or body that will act on the results) explicitly, because the objectives are set for that decision. -->

| Field | Value |
|---|---|
| Document ID | [AE-YYYY-NNN] |
| Document type | [Evaluation plan / Evaluation report / Combined plan and report] |
| Architecture evaluated | [Name of the architecture or architecture collection] |
| Entity of interest | [System, software, service, enterprise or product line] |
| Architecture description used as evidence | [Document ID and version, for example AD-SYSTEM-001 v1.2] |
| Lifecycle stage of the entity | [Concept / Development / Production / Utilisation / Support / Retirement] |
| Evaluation authority (decision owner) | [@name, role] |
| Evaluation lead | [@name] |
| Evaluation framework | [Generic 42030 framework / Customised framework: name and version] |
| Version | [0.1] |
| Status | [Draft plan / Approved plan / In progress / Draft report / Final report / Superseded] |
| Owner | [@evaluation-lead] |
| Approvers / reviewers | [@sponsor], [@chief-architect], [@quality-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Evaluation authority | [@name] | [Plan approved / Report accepted / Accepted with conditions] | YYYY-MM-DD |
| Evaluation lead | [@name] | [Prepared] | YYYY-MM-DD |
| Architect of the evaluated architecture | [@name] | [Reviewed for factual accuracy] | YYYY-MM-DD |
| Independent reviewer | [@name] | [Reviewed] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record the plan baseline and every change to objectives or methods after approval, because they change what the results mean. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Draft evaluation plan |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Plan approved by the evaluation authority |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Objective EO-004 added after the scope review; ATAM phase 2 rescheduled |
| 2.0 | YYYY-MM-DD | [@name] | *Example:* Final report issued with synthesis, findings and recommendations |

## Contents

1. [Evaluation context and scope](#1-evaluation-context-and-scope)
2. [Evaluation framework and tailoring](#2-evaluation-framework-and-tailoring)
3. [Evaluation objectives](#3-evaluation-objectives)
4. [Evaluation factors and criteria](#4-evaluation-factors-and-criteria)
5. [Evaluation approach and methods](#5-evaluation-approach-and-methods)
6. [Evaluation plan](#6-evaluation-plan)
7. [Architectural analysis](#7-architectural-analysis)
8. [Value assessment](#8-value-assessment)
9. [Evaluation synthesis and results](#9-evaluation-synthesis-and-results)
10. [Findings and recommendations](#10-findings-and-recommendations)
11. [Confidence, limitations and assumptions](#11-confidence-limitations-and-assumptions)
12. [Traceability and follow-up](#12-traceability-and-follow-up)
13. [Glossary and references](#13-glossary-and-references)

## 1. Evaluation context and scope

<!-- Guidance: Answer: why now, for which decision, about which architecture, and for whom? An evaluation without a named decision drifts into a general review. Pitfall: evaluating "the system" when the decision is about one change. -->

### 1.1 Purpose and decision supported

State the decision the evaluation informs in one sentence, then the reason for evaluating
now. 42030 lists several uses for an evaluation, such as checking that stakeholder
concerns are addressed, judging value and quality, confirming fitness for purpose,
tracking progress, finding risks and opportunities, and supporting decisions; name the
ones that apply here.

| Item | Value |
|---|---|
| Decision supported | [*Example:* Approve the target architecture for the Order Management Platform before the build contract is signed] |
| Trigger | [*Example:* Stage gate 2 of the investment process] |
| Uses of this evaluation | [*Example:* Address stakeholder concerns; identify risks; compare two candidate architectures] |
| Decision deadline | YYYY-MM-DD |
| Consequence of no evaluation | [*Example:* Contract signed on an architecture whose availability has never been analysed] |

### 1.2 Subject of evaluation

| Item | Value |
|---|---|
| Architecture or architectures evaluated | [*Example:* Candidate A (event-driven modular monolith) and candidate B (microservices on managed Kubernetes)] |
| Boundary | [*Example:* Order capture, fulfilment orchestration, inventory reservation, customer notifications] |
| Out of scope | [*Example:* Warehouse robotics control; finance ledger (evaluated separately)] |
| Related architectures | [*Example:* Enterprise integration architecture; data platform architecture] |
| Evidence available | [*Example:* Architecture description v1.2, two prototypes, load test results from the current system] |

### 1.3 Evaluation context

Describe the environment that shapes the evaluation (clause 4.2 treats the evaluation
context as a first-class concept): organisation, market, regulation, programme
constraints, earlier evaluations and the politics of the decision. Note any conflict of
interest between the evaluation team and the architecture team.

[Context narrative, three to six sentences.]

### 1.4 Stakeholders and concerns

<!-- Guidance: Reuse the stakeholder and concern IDs from the architecture description where they exist, so traceability works across documents. -->

| ID | Stakeholder | Concerns relevant to this evaluation | Role in evaluation |
|---|---|---|---|
| SH-01 *(Example)* | Chief operating officer (evaluation authority) | Cost to operate, time to market for new channels | Sets objectives, accepts report |
| SH-02 *(Example)* | Head of e-commerce | Peak-season availability, checkout latency | Provides value judgements |
| SH-03 *(Example)* | Security officer | Card data scope, audit trail | Provides criteria and value judgements |
| SH-04 *(Example)* | Platform engineering lead | Operability, skills, run cost | Provides evidence and value judgements |
| SH-05 *(Example)* | Lead architect | All architectural concerns | Presents architecture, answers questions |
| [SH-nn] | [Stakeholder] | [Concerns] | [Role] |

## 2. Evaluation framework and tailoring

<!-- Guidance: Say which framework you follow and how you tailored it. Clause 4.7 and clause 7 allow an organisation to define a customised framework; clause 4.8 covers tailoring. Pitfall: claiming conformance to the generic framework while skipping value assessment. -->

### 2.1 Conceptual model used

The evaluation uses three tiers. Architectural analysis produces facts and estimates about
architecture properties. Value assessment turns those facts into stakeholder value
judgements. Evaluation synthesis combines analysis and assessment results against the
evaluation objectives into conclusions for the evaluation authority.

```mermaid
flowchart TB
  EA[Evaluation authority and decision] --> EO[Evaluation objectives]
  EO --> EF[Evaluation factors and criteria]
  EF --> AA[Architectural analysis: properties, measures, models]
  EF --> VA[Value assessment: stakeholder value judgements]
  AD[Architecture description and other evidence] --> AA
  SH[Stakeholders and concerns] --> VA
  AA --> VA
  AA --> SY[Evaluation synthesis]
  VA --> SY
  SY --> RS[Results, findings, recommendations]
  RS --> EA
```

### 2.2 Clause map

| 42030:2019 clause | Topic (short label) | Where addressed here |
|---|---|---|
| 4.2 | Evaluation context | Section 1.3 |
| 4.3 | Evaluation tiers (synthesis, value assessment, analysis) | Sections 7, 8, 9 |
| 4.4 | Conceptual model | Section 2.1 |
| 4.5 | Assessment compared with analysis | Sections 7 and 8 intros |
| 4.6 | Evaluation factors | Section 4 |
| 4.7, 7 | Customised frameworks | Section 2.3 |
| 4.8 | Tailoring | Section 2.4 |
| 5 | Conformance | Section 2.5 |
| 6.1 | Evaluation synthesis elements (objectives, approaches, factors, results) | Sections 3, 4, 5, 9 |
| 6.2 | Value assessment elements | Section 8 |
| 6.3 | Architectural analysis elements | Section 7 |
| 8.2 | Evaluation plan | Sections 1 to 6 |
| 8.3 | Evaluation report | Sections 7 to 12 |

### 2.3 Customised framework

If the organisation has its own evaluation framework (for example an architecture review
board method that always uses ATAM plus a cost model), name it and say how its elements
map to the generic framework.

| Item | Value |
|---|---|
| Framework name and version | [*Example:* Enterprise Architecture Review Method v3] |
| Owner | [@architecture-office] |
| Mandatory methods | [*Example:* ATAM for new platforms; lightweight checklist review for changes] |
| Mandatory work products | [*Example:* This plan and report; risk register entries] |
| Mapping to 42030 elements | [*Example:* Review board scorecard is the synthesis; ATAM is the analysis method; stakeholder voting is the value assessment method] |

### 2.4 Tailoring record

| ID | Element | Tailoring decision | Rationale | Approved by |
|---|---|---|---|---|
| TL-01 *(Example)* | Value assessment | Use a five-point value scale per objective instead of monetary value | No reliable benefit model at stage gate 2 | [@sponsor] |
| TL-02 *(Example)* | Architectural analysis | Use the ATAM utility tree as the analysis structure | Organisation standard for platform decisions | [@architecture-office] |
| [TL-nn] | [Element] | [Decision] | [Rationale] | [@name] |

### 2.5 Conformance claim

State which conformance case applies (clause 5): whether this document is an evaluation
work product created against the generic framework, against a customised framework, or
both. Keep the claim honest; a partial claim with a stated tailoring record is more useful
than an unsupported full claim.

[*Example:* "This plan and report are prepared as architecture evaluation work products
under the organisation's customised framework, which is mapped to ISO/IEC/IEEE 42030:2019
in section 2.3. Tailoring is listed in section 2.4."]

## 3. Evaluation objectives

<!-- Guidance: Write each objective as a question the evaluation authority needs answered. Three to eight objectives are typical. Pitfall: objectives that are really methods ("run an ATAM") instead of questions ("can the architecture meet peak-season availability?"). -->

| ID | Objective (question to answer) | Stakeholders | Concerns | Decision impact | Priority |
|---|---|---|---|---|---|
| EO-001 *(Example)* | Can the candidate architectures meet peak-season availability and latency targets? | SH-02, SH-04 | Availability, performance | Go or no-go for build | Must |
| EO-002 *(Example)* | Which candidate gives the lower three-year run cost at forecast volumes? | SH-01, SH-04 | Cost | Selection between A and B | Must |
| EO-003 *(Example)* | Does either candidate increase card data scope? | SH-03 | Security, compliance | Selection, compliance budget | Must |
| EO-004 *(Example)* | How quickly can a new sales channel be added? | SH-01, SH-02 | Modifiability, time to market | Selection | Should |
| EO-005 *(Example)* | Can the current platform team operate the candidate with its existing skills? | SH-04 | Operability, skills | Staffing plan | Should |
| [EO-nnn] | [Question] | [SH-nn] | [Concerns] | [Impact] | [Must / Should / Could] |

## 4. Evaluation factors and criteria

<!-- Guidance: Factors are the things that influence or constrain how each objective is judged (clause 4.6 and 6.1.4): criteria and thresholds, constraints, assumptions, available resources and evidence. Make every threshold explicit and say where it came from. -->

### 4.1 Criteria and thresholds

| ID | Objective | Criterion | Measure | Threshold or target | Source of threshold |
|---|---|---|---|---|---|
| EF-001 *(Example)* | EO-001 | Availability during peak season | Monthly availability of order capture | >= 99.95% | Service level objective, [link] |
| EF-002 *(Example)* | EO-001 | Checkout latency at peak | p99 order submission latency at 1,200 orders per minute | <= 800 ms | Product performance budget |
| EF-003 *(Example)* | EO-002 | Three-year run cost | Infrastructure plus licence plus operations staff, USD | Must not exceed USD 4.2 million; lower is better, compared in value assessment | Business case v2 |
| EF-004 *(Example)* | EO-003 | Card data scope | Number of components that store, process or transmit card data | Not greater than today (2) | Security policy |
| EF-005 *(Example)* | EO-004 | Channel onboarding effort | Engineering effort to add a marketplace channel | <= 6 person-weeks, no change to core order model | Channel strategy |
| EF-006 *(Example)* | EO-005 | Skills gap | Number of critical skills not present in the team | <= 1, closable by training in one quarter | Platform team plan |
| [EF-nnn] | [EO-nnn] | [Criterion] | [Measure] | [Threshold] | [Source] |

### 4.2 Constraints, assumptions and other factors

| ID | Type | Factor | Effect on evaluation |
|---|---|---|---|
| EF-101 *(Example)* | Constraint | Must run in the existing cloud provider tenancy | Candidate comparison excludes other providers |
| EF-102 *(Example)* | Assumption | Volume grows 35% per year for three years | Cost and capacity analysis use this curve |
| EF-103 *(Example)* | Resource | Two evaluation days with stakeholders; four analyst weeks | Limits number of scenarios analysed in depth |
| EF-104 *(Example)* | Evidence | No production data for candidate B | Lower confidence in B performance results |
| [EF-1nn] | [Constraint / Assumption / Resource / Evidence / Risk] | [Factor] | [Effect] |

## 5. Evaluation approach and methods

<!-- Guidance: Choose methods per objective (clauses 6.1.3, 6.2.3 and 6.3.3). One evaluation usually combines an analysis method, a value assessment method and a synthesis rule. Pitfall: selecting a method because the team knows it, not because it answers the objective. -->

### 5.1 Method selection

| ID | Method | Tier | Objectives served | Why chosen | Effort |
|---|---|---|---|---|---|
| EM-01 *(Example)* | ATAM (scenario-based tradeoff analysis) | Analysis, with stakeholder prioritisation feeding value assessment | EO-001, EO-003, EO-004 | Surfaces risks and tradeoffs across several quality attributes at once | 2 days plus preparation |
| EM-02 *(Example)* | Queueing model and load test on prototypes | Analysis | EO-001 | Gives numbers for EF-002 | 2 analyst weeks |
| EM-03 *(Example)* | Three-year cost model | Analysis | EO-002 | Quantifies EF-003 | 1 analyst week |
| EM-04 *(Example)* | Data flow review against card data scope rules | Analysis | EO-003 | Counts in-scope components for EF-004 | 2 days |
| EM-05 *(Example)* | Skills inventory and interviews | Analysis | EO-005 | Measures EF-006 | 3 days |
| EM-06 *(Example)* | Weighted value scoring by stakeholders | Value assessment | All | Turns analysis results into comparable value | Half-day workshop |
| EM-07 *(Example)* | CBAM-style cost-benefit comparison of top strategies | Value assessment | EO-002, EO-004 | Relates benefit to cost of each architectural strategy | 1 day |
| [EM-nn] | [Method] | [Analysis / Value assessment / Synthesis] | [EO-nnn] | [Reason] | [Effort] |

Other methods you can plug in: a quality attribute workshop before an architecture exists
(Quality Attribute Workshop Report, `architecture/qaw-workshop-report`), an active design
review of a partial design (ARID Design Review, `architecture/arid-design-review`), a
cost-benefit analysis (CBAM Analysis, `architecture/cbam-analysis`), automated fitness
functions for continuous evaluation (Architecture Fitness Functions,
`architecture/fitness-functions`), simulation, prototyping, checklist and principle
reviews, and expert judgement panels.

### 5.2 How ATAM plugs into this framework

ATAM is an architectural analysis method in 42030 terms. Its outputs feed value assessment
and synthesis; it does not on its own make the decision. Record the ATAM itself in
Architecture Evaluation Report (ATAM) (`architecture/atam-evaluation`) and map its outputs
here.

| ATAM output | 42030 element it feeds | Where recorded here |
|---|---|---|
| Business drivers | Evaluation context and objectives | Sections 1.3, 3 |
| Utility tree with importance and difficulty ratings | Analysis objectives and value inputs (importance is a value judgement) | Sections 7.1, 8.1 |
| Architectural approaches | Subject of analysis | Section 7.2 |
| Prioritised stakeholder scenarios | Analysis scope and value inputs | Sections 7.1, 8.1 |
| Sensitivity points and tradeoff points | Analysis results | Section 7.3 |
| Risks, non-risks and risk themes | Analysis results; risk themes feed synthesis | Sections 7.3, 9.2 |
| Business drivers threatened by each risk theme | Value assessment results | Section 8.2 |

### 5.3 Synthesis rule

State in advance how results combine into a conclusion so the outcome is not argued after
the fact.

[*Example:* "A candidate is acceptable only if every Must objective is rated Met or Met
with conditions. Among acceptable candidates, the one with the higher weighted value score
in section 8.3 is recommended. A difference of less than 10% of the score is reported as
no material difference, and the lower-cost candidate is then recommended."]

## 6. Evaluation plan

<!-- Guidance: This is the planning work product (clause 8.2). Make it detailed enough that a second team could run the same evaluation. Approve it before collecting evidence. -->

### 6.1 Schedule

| Step | Activity | Start | End | Output |
|---|---|---|---|---|
| P-01 *(Example)* | Agree objectives, factors and methods | YYYY-MM-DD | YYYY-MM-DD | Approved plan v1.0 |
| P-02 *(Example)* | Collect evidence (architecture description, prototypes, cost data) | YYYY-MM-DD | YYYY-MM-DD | Evidence register |
| P-03 *(Example)* | ATAM phase 1 and phase 2 | YYYY-MM-DD | YYYY-MM-DD | ATAM report |
| P-04 *(Example)* | Load tests and cost model | YYYY-MM-DD | YYYY-MM-DD | Analysis results |
| P-05 *(Example)* | Value assessment workshop | YYYY-MM-DD | YYYY-MM-DD | Value scores |
| P-06 *(Example)* | Synthesis, draft report, factual accuracy review | YYYY-MM-DD | YYYY-MM-DD | Draft report |
| P-07 *(Example)* | Report to evaluation authority | YYYY-MM-DD | YYYY-MM-DD | Final report, decision |
| [P-nn] | [Activity] | YYYY-MM-DD | YYYY-MM-DD | [Output] |

### 6.2 Team and responsibilities

| Activity | Evaluation authority | Evaluation lead | Analysts | Architect | Stakeholders |
|---|---|---|---|---|---|
| Set objectives | A | R | C | C | C |
| Select methods | I | A | R | C | I |
| Provide evidence | I | A | C | R | C |
| Run analysis | I | A | R | C | I |
| Value assessment | C | A | R | I | R |
| Synthesis and findings | I | A | R | C | I |
| Accept results and decide | A | R | I | C | I |

R responsible, A accountable, C consulted, I informed.

### 6.3 Evidence register

| ID | Evidence | Version or date | Provided by | Used for | Reliability |
|---|---|---|---|---|---|
| EV-01 *(Example)* | Architecture description AD-OMP-001 | v1.2, YYYY-MM-DD | [@architect] | EM-01, EM-04 | High |
| EV-02 *(Example)* | Prototype load test results, candidate A | YYYY-MM-DD | [@platform] | EM-02 | Medium (synthetic data) |
| EV-03 *(Example)* | Vendor price list and committed-use discount quote | YYYY-MM-DD | [@procurement] | EM-03 | High |
| EV-04 *(Example)* | Current system incident history, last 12 months | YYYY-MM-DD | [@sre] | EM-01, EM-02 | High |
| [EV-nn] | [Evidence] | [Version] | [@name] | [EM-nn] | [High / Medium / Low] |

### 6.4 Risks to the evaluation

| Risk | Effect | Mitigation |
|---|---|---|
| *Example:* Key stakeholders unavailable for phase 2 | Value judgements biased towards technical staff | Book dates at plan approval; accept delegates with written mandate |
| *Example:* Architecture changes during the evaluation | Results describe an outdated architecture | Freeze the description version for the evaluation (EV-01) |
| [Risk] | [Effect] | [Mitigation] |

## 7. Architectural analysis

<!-- Guidance: Analysis establishes what is true about the architecture: properties, measurements, model results and identified risks. Keep value words out of this section ("good", "acceptable"); put them in section 8. Clause 6.3 lists objectives, methods, factors and results for analysis. -->

### 7.1 Analysis objectives and scenarios

| ID | Analysis objective | Derived from | Scenario or question | Method |
|---|---|---|---|---|
| AO-01 *(Example)* | Determine order capture availability under single zone and region loss | EO-001, EF-001 | Zone failure at peak; full region outage | EM-01, EM-02 |
| AO-02 *(Example)* | Measure p99 submission latency at 1,200 orders per minute | EO-001, EF-002 | Black Friday peak load | EM-02 |
| AO-03 *(Example)* | Estimate three-year run cost for both candidates | EO-002, EF-003 | Forecast volume curve EF-102 | EM-03 |
| AO-04 *(Example)* | Count card data scope components | EO-003, EF-004 | Payment authorisation flow | EM-04 |
| AO-05 *(Example)* | Estimate effort to add a marketplace channel | EO-004, EF-005 | Growth scenario from ATAM | EM-01 |
| AO-06 *(Example)* | Identify skills gaps | EO-005, EF-006 | Operate candidate in production | EM-05 |
| [AO-nn] | [Objective] | [EO-nnn, EF-nnn] | [Scenario] | [EM-nn] |

### 7.2 Architecture elements and approaches analysed

| ID | Approach or element | Candidate | Quality attributes affected |
|---|---|---|---|
| AP-01 *(Example)* | Event-driven modules with a transactional outbox | A | Availability, modifiability |
| AP-02 *(Example)* | Independent services with per-service databases | B | Modifiability, operability, cost |
| AP-03 *(Example)* | Tokenisation gateway in front of payment provider | A and B | Security, card data scope |
| AP-04 *(Example)* | Active-passive region pair with asynchronous replication | A and B | Availability, cost |
| [AP-nn] | [Approach] | [Candidate] | [Attributes] |

### 7.3 Analysis results

| ID | Analysis objective | Candidate | Result (fact, measurement or estimate) | Basis | Related risk or tradeoff |
|---|---|---|---|---|---|
| AR-01 *(Example)* | AO-01 | A | Zone loss: no outage, 20 s degradation. Region loss: recovery estimated at 18 min, up to 5 s of orders at risk | EM-01 scenario walk-through, EV-04 | Risk R-01 (recovery time) |
| AR-02 *(Example)* | AO-01 | B | Zone loss: no outage. Region loss: recovery estimated at 40 min because 14 databases fail over separately | EM-01, EV-01 | Risk R-02; tradeoff T-01 (independence vs recovery coordination) |
| AR-03 *(Example)* | AO-02 | A | p99 610 ms at 1,200 orders per minute on prototype | EM-02, EV-02 | None |
| AR-04 *(Example)* | AO-02 | B | p99 920 ms; three synchronous service hops dominate | EM-02 | Sensitivity point S-01 (hop count) |
| AR-05 *(Example)* | AO-03 | A | USD 3.1 million over three years | EM-03, EV-03 | None |
| AR-06 *(Example)* | AO-03 | B | USD 3.9 million over three years | EM-03, EV-03 | Tradeoff T-02 (team autonomy vs platform cost) |
| AR-07 *(Example)* | AO-04 | A and B | 2 components in scope with tokenisation gateway | EM-04 | Non-risk NR-01 |
| AR-08 *(Example)* | AO-05 | A | 4 to 5 person-weeks; touches the order module | EM-01 | Sensitivity point S-02 (shared order schema) |
| AR-09 *(Example)* | AO-05 | B | 3 person-weeks; new adapter service only | EM-01 | None |
| AR-10 *(Example)* | AO-06 | B | Three critical skills missing (service mesh, distributed tracing, per-service database operations) | EM-05 | Risk R-03 |
| AR-11 *(Example)* | AO-06 | A | One critical skill missing (event streaming operations), covered by a vendor course of four weeks | EM-05 | None |
| [AR-nn] | [AO-nn] | [Candidate] | [Result] | [Method, evidence] | [Risk / tradeoff / sensitivity point] |

## 8. Value assessment

<!-- Guidance: Value assessment judges how much the analysis results matter to the stakeholders (clause 6.2). Use the stakeholders named in section 1.4, a declared scale, and recorded weights. Pitfall: the architects score their own design alone. -->

### 8.1 Value scale and weights

| Score | Meaning |
|---|---|
| 5 | Exceeds the threshold with margin; creates new options |
| 4 | Meets the threshold with margin |
| 3 | Meets the threshold |
| 2 | Misses the threshold, but a known change closes the gap |
| 1 | Misses the threshold; no known remedy within constraints |

| Objective | Weight | Weight set by | Rationale |
|---|---|---|---|
| EO-001 *(Example)* | 30% | SH-01 with SH-02 | Peak season is 40% of annual revenue |
| EO-002 *(Example)* | 25% | SH-01 | Run cost is a business case condition |
| EO-003 *(Example)* | 20% | SH-03 | Compliance scope drives audit cost |
| EO-004 *(Example)* | 15% | SH-02 | Channel strategy |
| EO-005 *(Example)* | 10% | SH-04 | Staffing is adjustable |
| Total | 100% | | |

### 8.2 Value judgements

| ID | Objective | Candidate | Analysis results used | Score | Stakeholder rationale |
|---|---|---|---|---|---|
| VA-01 *(Example)* | EO-001 | A | AR-01, AR-03 | 3 | Latency has margin; an 18 min region recovery fits the 21.6 min monthly downtime budget of EF-001, with little margin |
| VA-02 *(Example)* | EO-001 | B | AR-02, AR-04 | 1 | Latency misses EF-002 by 15% and a 40 min region recovery exceeds the 21.6 min monthly budget; no tested remedy within constraints |
| VA-03 *(Example)* | EO-002 | A | AR-05 | 4 | 26% below the cap |
| VA-04 *(Example)* | EO-002 | B | AR-06 | 3 | 7% below the cap |
| VA-05 *(Example)* | EO-003 | A | AR-07 | 3 | Scope unchanged |
| VA-06 *(Example)* | EO-003 | B | AR-07 | 3 | Scope unchanged |
| VA-07 *(Example)* | EO-004 | A | AR-08 | 4 | Inside the 6 person-week target |
| VA-08 *(Example)* | EO-004 | B | AR-09 | 5 | Half the target, no core change |
| VA-09 *(Example)* | EO-005 | A | AR-11 | 4 | One gap, closable by training |
| VA-10 *(Example)* | EO-005 | B | AR-10 | 2 | Three gaps; hiring needed |
| [VA-nn] | [EO-nnn] | [Candidate] | [AR-nn] | [1 to 5] | [Rationale] |

### 8.3 Weighted value

| Candidate | EO-001 (30%) | EO-002 (25%) | EO-003 (20%) | EO-004 (15%) | EO-005 (10%) | Weighted score |
|---|---|---|---|---|---|---|
| A *(Example)* | 3 | 4 | 3 | 4 | 4 | 3.50 |
| B *(Example)* | 1 | 3 | 3 | 5 | 2 | 2.60 |

Computation for A: 0.30 x 3 + 0.25 x 4 + 0.20 x 3 + 0.15 x 4 + 0.10 x 4 = 0.90 + 1.00 +
0.60 + 0.60 + 0.40 = 3.50. For B: 0.30 + 0.75 + 0.60 + 0.75 + 0.20 = 2.60. Recompute
whenever a score or weight changes.

## 9. Evaluation synthesis and results

<!-- Guidance: Synthesis answers each objective and applies the rule fixed in section 5.3 (clause 6.1.5). State the result per objective first, then the overall conclusion. Pitfall: an overall conclusion that the objective table does not support. -->

### 9.1 Result per objective

| Objective | Candidate A | Candidate B | Evidence |
|---|---|---|---|
| EO-001 *(Example)* | Met | Not met (latency, region recovery) | VA-01, VA-02 |
| EO-002 *(Example)* | Met | Met | VA-03, VA-04 |
| EO-003 *(Example)* | Met | Met | VA-05, VA-06 |
| EO-004 *(Example)* | Met | Met | VA-07, VA-08 |
| EO-005 *(Example)* | Met | Met with conditions (hiring) | VA-09, VA-10 |
| [EO-nnn] | [Met / Met with conditions / Not met / Not determined] | [Result] | [VA-nn] |

### 9.2 Risk themes and opportunities

| ID | Theme | Risks grouped | Objectives threatened | Candidates |
|---|---|---|---|---|
| RT-01 *(Example)* | Regional recovery depends on manual, multi-step failover | R-01, R-02 | EO-001 | A and B (worse in B) |
| RT-02 *(Example)* | Operating a distributed platform exceeds current team capability | R-03 | EO-005, EO-001 | B |
| OP-01 *(Example)* | Outbox events can feed the planned analytics platform with no extra integration | Not a risk | EO-004 | A |
| [RT-nn / OP-nn] | [Theme] | [R-nn] | [EO-nnn] | [Candidates] |

### 9.3 Overall conclusion

[*Example:* "Candidate A satisfies all Must objectives and scores 3.50 against 2.60 for
candidate B. Candidate B fails EO-001 on latency and regional recovery and needs three new skills.
The evaluation recommends candidate A, subject to REC-01 on regional recovery and REC-02
on latency monitoring. Candidate B's advantage in channel onboarding (EO-004) is real but does
not offset the latency and skills gaps at the current weights."]

## 10. Findings and recommendations

<!-- Guidance: A finding is a statement the evaluation authority can act on; a recommendation says what to do, who should do it and by when. Keep the evaluation independent: recommend, do not redesign. -->

### 10.1 Findings

| ID | Finding | Evidence | Objectives | Severity |
|---|---|---|---|---|
| FND-01 *(Example)* | Region recovery in both candidates relies on runbook steps never rehearsed | AR-01, AR-02, EV-04 | EO-001 | High |
| FND-02 *(Example)* | Candidate B latency is sensitive to the number of synchronous hops on the order path | AR-04 | EO-001 | Medium |
| FND-03 *(Example)* | The shared order schema in candidate A is the main constraint on channel onboarding | AR-08 | EO-004 | Low |
| [FND-nn] | [Finding] | [AR-nn, VA-nn, EV-nn] | [EO-nnn] | [High / Medium / Low / Information] |

### 10.2 Recommendations

| ID | Recommendation | Addresses | Owner | Due | Acceptance criterion |
|---|---|---|---|---|---|
| REC-01 *(Example)* | Automate region failover and rehearse it in a game day before go-live | FND-01 | [@sre-lead] | YYYY-MM-DD | Rehearsal recovers in <= 15 min with no lost orders |
| REC-02 *(Example)* | Add a fitness function that fails the release if p99 submission latency exceeds 800 ms in the performance environment | FND-02, EF-002 | [@platform] | YYYY-MM-DD | Function FF-nn live in the pipeline |
| REC-03 *(Example)* | Version the order schema and add an extension area for channel attributes | FND-03 | [@lead-architect] | YYYY-MM-DD | Architecture decision recorded; next channel added without schema change |
| [REC-nn] | [Recommendation] | [FND-nn] | [@owner] | YYYY-MM-DD | [Criterion] |

## 11. Confidence, limitations and assumptions

<!-- Guidance: Tell the evaluation authority how far to trust each result. Low confidence is acceptable if it is stated and the decision allows for it; hidden low confidence is not. -->

| Result or objective | Confidence | Reason | What would raise confidence |
|---|---|---|---|
| EO-001, candidate A *(Example)* | Medium | Prototype load test with synthetic data; region recovery estimated, not measured | Rehearsed failover (REC-01) and a production-like load test |
| EO-002 *(Example)* | High | Vendor quote and committed-use discount confirmed | Not needed |
| EO-005, candidate B *(Example)* | Medium | Skills inventory self-reported | Practical assessment |
| [Result] | [High / Medium / Low] | [Reason] | [Action] |

Limitations of this evaluation:

- [*Example:* Only the five highest-priority ATAM scenarios were analysed in depth; 19 lower-priority scenarios were recorded but not analysed.]
- [*Example:* Security was evaluated for card data scope only; a full threat model is out of scope (see Threat Model, `security/threat-model`).]
- [*Example:* Cost model assumes the volume curve in EF-102; at half that growth the cost gap between candidates narrows to USD 0.4 million.]

## 12. Traceability and follow-up

<!-- Guidance: The matrix proves that every objective was analysed, valued, concluded and acted on. Use it in the factual accuracy review before issuing the report. -->

### 12.1 Traceability matrix

| Objective | Factors | Methods | Analysis results | Value judgements | Result | Findings | Recommendations |
|---|---|---|---|---|---|---|---|
| EO-001 *(Example)* | EF-001, EF-002 | EM-01, EM-02 | AR-01 to AR-04 | VA-01, VA-02 | A met, B not met | FND-01, FND-02 | REC-01, REC-02 |
| EO-002 *(Example)* | EF-003 | EM-03, EM-07 | AR-05, AR-06 | VA-03, VA-04 | Both met | None | None |
| EO-003 *(Example)* | EF-004 | EM-04 | AR-07 | VA-05, VA-06 | Both met | None | None |
| EO-004 *(Example)* | EF-005 | EM-01, EM-07 | AR-08, AR-09 | VA-07, VA-08 | Both met | FND-03 | REC-03 |
| EO-005 *(Example)* | EF-006 | EM-05 | AR-10, AR-11 | VA-09, VA-10 | A met, B met with conditions | None | None |
| [EO-nnn] | [EF-nnn] | [EM-nn] | [AR-nn] | [VA-nn] | [Result] | [FND-nn] | [REC-nn] |

### 12.2 Follow-up actions

| ID | Action | Owner | Due | Status |
|---|---|---|---|---|
| ACT-01 *(Example)* | Record the decision and conditions in an architecture decision record | [@lead-architect] | YYYY-MM-DD | Open |
| ACT-02 *(Example)* | Add RT-01 and RT-02 to the programme risk register | [@pm] | YYYY-MM-DD | Open |
| [ACT-nn] | [Action] | [@owner] | YYYY-MM-DD | [Open / Done] |

### 12.3 Re-evaluation triggers

Re-run the evaluation, or the affected part of it, when any of these occur:

- A Must objective, threshold or weight changes.
- The architecture changes an approach analysed in section 7.2.
- Evidence with low confidence (section 11) is replaced by measured data that contradicts the estimate.
- A fitness function linked to an evaluation factor fails repeatedly in production.
- [Organisation-specific trigger, for example the annual architecture health check in Architecture Health Check (`architecture/architecture-health-check`)].

### 12.4 Report completeness check

Before issuing the report (clause 8.3), confirm:

- [ ] The evaluation authority, decision and scope are stated.
- [ ] Every objective has factors, a method, analysis results, value judgements and a result.
- [ ] Tailoring and conformance are stated.
- [ ] Analysis results are separated from value judgements.
- [ ] Confidence and limitations are stated for each Must objective.
- [ ] The architect has reviewed the report for factual accuracy.
- [ ] Recommendations have owners, dates and acceptance criteria.

## 13. Glossary and references

<!-- Guidance: Define terms in your own words for readers who have not read the standard. Keep the reference list to sources actually used. -->

| Term | Meaning in this document |
|---|---|
| Architecture evaluation | Determining how well an architecture meets its objectives and serves its stakeholders, for a stated decision |
| Architectural analysis | Work that establishes facts or estimates about architecture properties, using models, tests, walk-throughs or calculations |
| Value assessment | Judging how much the analysis results are worth to the stakeholders, on a declared scale |
| Evaluation synthesis | Combining analysis and value results against the objectives into conclusions |
| Evaluation factor | Anything that shapes how an objective is judged: criteria, thresholds, constraints, assumptions, resources, evidence |
| Evaluation authority | The person or body that commissions the evaluation and acts on its results |
| Sensitivity point | An architectural property that strongly affects one quality attribute response (ATAM term) |
| Tradeoff point | A property that affects more than one quality attribute in opposite directions (ATAM term) |
| Risk theme | A group of related risks that together threaten a business driver (ATAM term) |

| ID | Reference | Version | Use |
|---|---|---|---|
| REF-01 | ISO/IEC/IEEE 42030, *Software, systems and enterprise: Architecture evaluation framework* | 2019, first edition (stage 90.92, to be revised since 2026-01-08; AWI 42030 *Enterprise, systems and software: Architecture evaluation framework* registered 2026-05-22) | Structure of this template |
| REF-02 | ISO/IEC/IEEE 42020, *Software, systems and enterprise: Architecture processes*, clause 9 Architecture Evaluation process | 2019 | Process context; see Architecture Process Plan and Records (`architecture/architecture-practice-42020`) |
| REF-03 | ISO/IEC/IEEE 42010, *Software, systems and enterprise: Architecture description* | 2022 | Evidence: the architecture description |
| REF-04 | Kazman, Klein, Clements, *ATAM: Method for Architecture Evaluation*, SEI CMU/SEI-2000-TR-004 | August 2000 | Plug-in analysis method |
| REF-05 | Related templates: Architecture Evaluation Report (ATAM) (`architecture/atam-evaluation`), Non-Functional Requirements and Quality Attribute Scenarios (`requirements/quality-attributes`), Architecture Fitness Functions (`architecture/fitness-functions`), CBAM Analysis (`architecture/cbam-analysis`) | Current | Methods and inputs |
| [REF-nn] | [Title] | [Version] | [Use] |

## Standard and licence note

Structure aligned with ISO/IEC/IEEE 42030:2019, *Software, systems and enterprise:
Architecture evaluation framework* (clauses 4 to 8: evaluation context, the three
evaluation tiers, evaluation factors, customised frameworks, conformance, and the
evaluation plan and report work products), with the Architecture Evaluation process of
ISO/IEC/IEEE 42020:2019 as process context and the SEI Architecture Tradeoff Analysis
Method as an example analysis method. Only clause numbers and short topic labels are used;
all explanations, tables and examples are original text written for this collection, and
no text, definition or table of the standards is reproduced. ISO lists the 2019 edition as
"to be revised" (stage 90.92 since 2026-01-08), and a second edition is registered as work
item AWI 42030 (2026-05-22) under the reordered title *Enterprise, systems and software:
Architecture evaluation framework*; check the current edition in the ISO catalogue before
claiming conformance. ATAM may be a trademark or service mark of
Carnegie Mellon University; this template is not affiliated with or endorsed by the SEI. Template licence: MIT.