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.

Document control

Approvals

Revision history

Contents

1. Evaluation context and scope
2. Evaluation framework and tailoring
3. Evaluation objectives
4. Evaluation factors and criteria
5. Evaluation approach and methods
6. Evaluation plan
7. Architectural analysis
8. Value assessment
9. Evaluation synthesis and results
10. Findings and recommendations
11. Confidence, limitations and assumptions
12. Traceability and follow-up
13. Glossary and references

1. Evaluation context and scope

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.

1.2 Subject of evaluation

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

2. Evaluation framework and tailoring

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.

2.2 Clause map

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.

2.4 Tailoring record

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

4. Evaluation factors and criteria

4.1 Criteria and thresholds

4.2 Constraints, assumptions and other factors

5. Evaluation approach and methods

5.1 Method selection

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.

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

6.1 Schedule

6.2 Team and responsibilities

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

6.3 Evidence register

6.4 Risks to the evaluation

7. Architectural analysis

7.1 Analysis objectives and scenarios

7.2 Architecture elements and approaches analysed

7.3 Analysis results

8. Value assessment

8.1 Value scale and weights

8.2 Value judgements

8.3 Weighted value

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

9.1 Result per objective

9.2 Risk themes and opportunities

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

10.1 Findings

10.2 Recommendations

11. Confidence, limitations and assumptions

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

12.1 Traceability matrix

12.2 Follow-up actions

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

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.