← VAF·SA Framework
Documentation records what happened. An artefact drives what happens next. They are not the same thing. Every artefact in this framework produces a decision, unlocks an action, or protects an outcome. Anything that does none of those three things is overhead.
VAF·SA produces five artefacts. No more. Each one has a named audience, a named purpose, and a size limit of one page. If it does not fit on one page, the thinking is not done. The temptation to add more pages is always a signal that the architect has not yet found the answer — they are still working through the problem in the document instead of before it.
The VAF Enterprise Architecture framework produces six artefact types at EA altitude — Guardrail Canvas, Trade-off Matrix, Architecture Decision Record with fitness functions, Reference Architecture, Site Risk Matrix, and Programme Overview. VAF·SA produces the delivery-altitude equivalents of four of those. Different altitude. Same purpose. Less governance weight. Faster production.
Where a Proof of Concept has been conducted — by the architect, the client, or the vendor — its outputs belong in this artefact set. A PoC without structured outputs is an experiment. A PoC with named success criteria, a heat map contribution, and a resulting Architecture Decision Record is a design instrument. The PoC output does not become a separate artefact — it populates the heat map cells it confirms and generates the ADR that records what the PoC determined.
The relationship between VAF EA and VAF·SA artefacts is not hierarchy — it is altitude. The EA practitioner operates at a different level of the organisation to the SA practitioner. The artefacts reflect that. When the EA is present and functional, VAF·SA artefacts feed upward into the EA governance layer. When the EA is absent — which is the common condition in the four engagement archetypes — VAF·SA artefacts stand alone as the authoritative record of the engagement.
Artefact
Guardrail Canvas
Strategic intent and governance boundaries
Artefact
Trade-off Matrix
EA-level decision trade-offs
Artefact
ADR + Fitness Functions
Governed architectural decisions
Artefact 01
Customer Impact Statement
Business intent locked in plain language
Audience
Executive · Business Leads
Anyone who funds or approves
Size
One Page
No exceptions
Artefact 02
Architecture on a Page
Solution visible to all audiences
Artefact 03
Heat Map
Nine domains. Forensic instrument.
Size
One Page Each
No exceptions
Artefact 04
Architecture Decision Record
SA-level. Why this was decided.
Audience
All · Future Architects
Decision rationale preserved
Size
One Page Per Decision
No exceptions
The Customer Impact Statement is the artefact that locks business intent before any technical work begins. It is written in plain language. It contains no technical architecture. It can be read by a CFO in under two minutes and understood by a DBA in the same time. If either of those audiences cannot understand it, it has been written at the wrong altitude.
The CIS is not a business case. It is not a requirements document. It is not a project brief. It is the answer to one question: what are we actually trying to achieve, and what happens if we fail? Everything else in the engagement flows from that answer.
What It Contains
- The problem — in the business's language
- The cost of inaction — time, money, risk
- The proposed solution — one paragraph
- The expected outcome — measurable
- The cost of failure — what happens if this fails again
- The decision required — from whom, by when
What It Does Not Contain
- Technical architecture or system names
- Framework references or methodology
- Jargon of any kind
- More than one page of content
- Anything the executive cannot act on
- Assumptions not confirmed in Module 2
The test: Hand it to the most senior non-technical person in the engagement. If they cannot read it, understand it, and tell you what decision they need to make — rewrite it. The CIS has failed if anyone needs it explained to them.
The Problem
[Organisation name] is currently experiencing [specific problem in business language]. This has been the case for [duration]. Previous attempts to resolve it include [brief summary of prior attempts]. None succeeded because [plain-language reason].
The Cost of Inaction
If this remains unresolved: [financial cost per period] in ongoing expense. [operational impact] on service delivery. [risk exposure] in compliance or security terms. The organisation has already spent [amount] attempting to solve this. Each month of inaction adds [monthly cost].
The Proposed Solution
[One paragraph. No technical terms. What will be done, not how it will be done.] The solution addresses the problem by [plain-language description]. It replaces [what] with [what] and enables [business outcome].
The Expected Outcome
Within [timeframe]: [measurable outcome 1]. Within [timeframe]: [measurable outcome 2]. The solution will be considered successful when [specific, testable condition].
The Decision Required
[Name or role] is asked to approve [specific decision] by [date]. Without this decision, [specific consequence] will follow. This document has been prepared by [architect name] and reviewed by [stakeholder name].
The Architecture on a Page is the single deliverable that the entire engagement has been building toward. It contains the business intent, the solution structure, and the delivery roadmap — visible simultaneously on one page to every audience who needs to act on it. The executive reads the top. The architect reads the middle. The delivery team reads the bottom.
It is produced in Lucidchart for stakeholder-facing presentation. It references the context diagram from Module 3. It reflects the current state of the heat map. It is the evidence that the architect has understood the problem, designed the solution, and identified the path to delivery.
Zone 1 — Top (Business)
- Business objective — one sentence
- Success criteria — two or three measurable items
- Key constraints — what cannot be changed
Zone 2 — Middle (Architecture)
- context diagram — named systems, named connections
- Current state — what is being replaced or extended
- Target state — what the solution looks like
- Key decisions — ADR references where applicable
Zone 3 — Bottom (Delivery)
- Roadmap — three phases maximum
- Phase 1: what unlocks the solution
- Phase 2: what builds it
- Phase 3: what operationalises it
Right Margin — Risks
- Top three risks — named and owned
- Heat map status — red items visible
- Open decisions — pending items that could change design
The test: Place it in front of three people simultaneously — the CIO, the lead architect, and the project manager. All three should be able to read what concerns them without asking for clarification. If any of the three needs something explained, the zone for their audience has been designed at the wrong altitude.
The Architecture on a Page is not the same as an architecture diagram. An architecture diagram shows how a system is built. The AoaP shows why a solution was chosen, what it looks like, and how it will be delivered — for every audience who needs to act on that information simultaneously.
The heat map is not produced at the end of an engagement. It is created at the beginning of Module 3 and updated continuously through Modules 3 and 4. By the time it reaches its final state, every cell has been answered, challenged, and independently verified. A heat map with no red cells at the end of a complex engagement is not evidence of a complete solution — it is evidence that the cells were accepted without interrogation.
Nine Domains
- 01 — Security and Cybersecurity
- 02 — Data Flow and Sovereignty
- 03 — Compliance and Regulatory
- 04 — Networking and Connectivity
- 05 — Cloud and Infrastructure
- 06 — Integration and APIs
- 07 — Vendor and Commercial
- 08 — Operations and Support
- 09 — Non-Functional Requirements
Cell Status
- RED — open risk. Decision required before design proceeds
- AMBER — partially addressed. Owner assigned. Deadline set.
- GREEN — confirmed. Documented. Independently verified.
- GREY — not applicable. Reason documented.
- BLANK — not permitted. Ever.
Final State Rule
- All red cells: named owner, named deadline
- All green cells: independently verified
- All grey cells: documented reason
- Zero blank cells — no exceptions
The forensic function: Place the heat map in front of the vendor or the withholding stakeholder. Every blank cell is named aloud. Every red cell is assigned an owner and a deadline in the meeting. The map makes silence visible. It makes deflection structural rather than conversational. You cannot deflect a named cell the way you can deflect an open question.
The ADR solves the most pervasive problem in solution architecture: decision rationale gets lost. Systems are built to reflect decisions nobody on the current team remembers making. New architects repeat analysis already completed. Governance reviews lack evidence of past reasoning. Vendors exploit the gap between what was decided and what was documented.
In every one of the four engagement archetypes, the absence of ADRs contributed to the failure. The vendor who obfuscated did so partly because no prior decision about data egress had been formally recorded. The organisation with institutional paralysis had no record of why prior attempts failed. The ADR exists so that the next architect, the next audit, and the next vendor engagement has the evidence in writing.
VAF·SA ADRs are SA-level. They are lighter than the EA-level ADR with fitness functions. One page. Written at the time of the decision. Numbered. Versioned. Status tracked. Never modified — only superseded by a new ADR that references the original.
When to write an ADR: Any decision that, if reversed, would require significant rework. Any decision that could be challenged in governance. Any decision involving a vendor commitment. Any decision about data flow, security controls, or integration patterns. When in doubt — write one. The cost of writing one is minutes. The cost of not having one can be months.
ADR Number
ADR-[NNN] — sequential, engagement-scoped. E.g. ADR-001, ADR-002.
Title
One line. States the decision, not the topic. E.g. "Use Azure Blob Storage for long-term data archival" not "Storage decision."
Status
Proposed — under discussion. Accepted — active and governing. Superseded — replaced by ADR-[NNN]. Never deleted.
Date
Date the decision was made. Not the date the document was written.
Decision Makers
Named individuals who made or approved this decision. Role and name. Not just role.
Context
What forced this decision. The situation as it existed at the time — including constraints, risks, and what was already known from the heat map and intelligence gathering.
Decision
One or two sentences. What was decided. Plain language. No ambiguity. The decision that will govern subsequent work.
Alternatives Considered
What else was evaluated. Why it was rejected. This is the most important field — it prevents future architects from re-evaluating options already ruled out and documents the trade-off that was accepted.
Consequences
What this decision creates, enables, or closes off. What would need to change if this decision were reversed. Any downstream decisions it triggers.
Trade-off Accepted
What was given up to make this decision. The alternative approach that was rejected and the specific reason it was rejected in favour of this path. This field makes the cost of the decision visible to every future architect who reads this record — preventing re-evaluation of options already ruled out with considered rationale.
What Changes This
Named conditions that would require this decision to be reviewed. E.g. "Vendor changes hosting model" or "Regulatory requirement changes data classification."
The Stakeholder Concern Register is the artefact that makes political dynamics visible and accountability explicit. Every stakeholder in the engagement has their name on a page next to their actual concern — stated in their own words, not sanitised into a category. When that document is shared with all parties and each concern is committed to in writing, those concerns stop being private agendas and become formal work items.
This is not a stakeholder management matrix. It is not a responsibility matrix. It is a transparency contract — the document that prevents the backchannel conversation, the revisited commitment, and the mid-engagement claim that a concern was never raised. When every concern is named, politics has nowhere to hide.
Four Columns
- Stakeholder — named individual, not a role
- Their concern — in their own words, not paraphrased
- What will be done — specific commitment, not a category
- By when — a date, not a phase
What It Prevents
- Backchannel concern campaigns
- Mid-engagement claims that concerns were ignored
- Scope arguments based on undisclosed stakeholder positions
- Political resistance disguised as technical objection
- The vendor who claims their position was never heard
Stakeholder
Concern — in their words
Commitment
By When
Status
CISO
"I need written confirmation that no data leaves the jurisdiction before I can approve this design."
Written data sovereignty statement obtained from vendor and reviewed
15 June
Open
Regional Finance Lead
"The migration cost needs to be broken out from ongoing run cost before we can take this to the board."
Separate CAPEX and OPEX view provided in the CIS cost section
1 June
Resolved
Platform Lead
"The three teams who depend on this system haven't been consulted. If we design without them we'll have to redesign."
Workshop 2 structured to include all three dependent teams
Workshop 2
Resolved
The test: Every person named in this register has seen it, confirmed their concern is accurately stated, and received a written commitment in response. If any named stakeholder can claim their concern was not recorded or not addressed — the register has not done its job.
A document that is accurate on the day it is produced and outdated within a month is not a living artefact. It is a historical record with a future expiry date. Every artefact produced in VAF·SA is treated as a living document — versioned, dated, and updated when the engagement conditions change.
This is not about maintaining a documentation system. It is about maintaining the integrity of the artefact as the authoritative record of what was decided and why. A CIS that reflects the original intent and not the evolved one has failed its purpose. An ADR marked Accepted for a decision that has since been superseded — without a new ADR referencing it — has broken the decision chain.
Principle 01
Every Artefact is Dated and Versioned
Version number. Date. Author. Status. On every document. When it changes — new version, new date, change documented. The version history is the audit trail.
Principle 02
ADRs Are Never Deleted
A superseded ADR remains in the record. The new ADR references the old one. The chain of decisions is unbroken. Future architects can trace every significant decision back to its context.
Principle 03
Artefacts Are Linked to Delivery
The AoaP references the roadmap phases. The roadmap phases reference the backlog. The backlog references the ADRs that constrain each workstream. The chain from intent to delivery is traceable in both directions.
Principle 04
Reality Changes the Artefact
When the engagement changes — vendor exits, requirements shift, new constraints emerge — the artefact changes too. A CIS that no longer reflects the current problem is not a CIS. It is a liability.
The VAF Agentic Architect already generates and commits VP1, VP2, and VP3 artefacts to GitHub automatically. VAF·SA artefacts — CIS, AoaP, Heat Map, ADR — are the next generation of targets for agentic generation. The framework teaches the human method first. The agent automates it second.
ALL FIVE ARTEFACTS MUST EXIST AND ALL ITEMS CONFIRMED BEFORE PROCEEDING TO MODULE 5
Customer Impact Statement produced — one page, plain language, no technical content, named decision required from named person by named date.
CIS test passed — most senior non-technical stakeholder can read it, understand it, and state the decision required without explanation.
Architecture on a Page produced — three zones populated: business intent top, context-level diagram and current/target state middle, roadmap bottom, risks right margin.
AoaP test passed — CIO reads zone 1, lead architect reads zone 2, project manager reads zone 3, none require clarification from the other's zone.
Heat map finalised — all nine domains addressed, zero blank cells, all red cells have named owner and named deadline, all green cells independently verified.
Stakeholder Concern Register produced — every named stakeholder has their concern recorded in their own words, a written commitment confirmed, and a deadline assigned.
ADRs written — one per significant decision made in the engagement. Status set. Decision makers named. Alternatives documented. Consequences stated.
All artefacts versioned and dated — version number, date, author, status on every document.
Artefacts linked to delivery — AoaP roadmap phases traceable to workstreams, ADRs referenced from affected design decisions.
All four artefacts consistent with each other — CIS intent matches AoaP business zone, heat map risks visible in AoaP right margin, ADRs referenced where relevant.
Artefact set ready for Module 5 — all four artefacts can now be presented to every room. Module 5 teaches how to present them.