Most architecture documents are written to be complete. They catalogue every component, every interface and every environment, and they are genuinely useful to the engineers who will build from them. They are much less useful to the people who have to approve the work, because completeness and decidability are different properties. A pack with forty diagrams can leave an investment committee unable to answer the only question it was asked: should we do this, in this way, now?
The aim of the views in this part is narrower. They are the minimum set that lets a decision be made and defended: by a business owner who needs to know it solves the problem, by a risk function that needs to know what could go wrong, and by the teams who will have to run it. Detail still matters, but it lives behind these views rather than in front of them.
A view answers a question
The rule we work to is that every view should answer one question a decision-maker actually has. If you cannot say which question a diagram answers, it is probably either decoration or reference material, and it belongs in an appendix.
Grouped by question, the minimum set looks like this.
Why are we doing this?
- Outcome and capability. The business outcome, the measures from Part 2, and the business capabilities involved. At Klipspringer: decision time and abandonment, held against three guardrails, and the capabilities of application intake, document verification, credit decisioning and loan set-up.
- Customer or service journey. What the customer and staff experience, step by step, today and in the target state.
What are we changing?
- Current-state context. The systems and parties involved today and how they connect, at a level a non-specialist can follow.
- Target components. What will exist after the change, with new, changed, reused and retired components clearly marked. Part 4's decisions show up here directly.
- Information and trust boundaries. Where data lives, where it crosses between systems or organisations, and where identity and trust change.
How will it work, and how do we get there?
- Integration and sequence flows. What calls what, in what order, and what happens when a step fails.
- Deployment and operations. Where each component runs, who operates it, how it is monitored and supported.
- Transition roadmap. The states between today and the target, including the awkward middle where old and new run side by side.
Running alongside all of them is a log of decisions, assumptions and open questions. It is the ninth view, and arguably the most important.
A good review starts with the customer journey
Klipspringer Bank is fictional, and its systems and figures are illustrative. When its architecture team first presented the target design internally, they opened with the component diagram, as most teams do. The meeting went badly. People argued about whether the decision service should be a separate component, then about which cloud services it would use, and ran out of time without discussing whether the design would actually shorten a decision.
The second presentation opened with the journey. On the left, today: complete the form, upload documents, wait two days, get a call about a missing page, upload again, wait for a second signature, receive a decision on day six. On the right, the target: the upload step checks completeness on the spot, existing customers skip the bank-statement upload entirely, the decision service clears straightforward applications the same day, and only genuinely complex or high-value cases reach an underwriter, with a status the customer can see.
Every component in the design could then be explained as serving a step in that journey. The discussion moved from "do we need this service?" to "does this step really happen in minutes?", which is the right argument to have. That is why we start every architecture review with the journey. It is the view everyone in the room can read, and it is the one that connects the design to the outcome.
Information and trust boundaries deserve their own view
It is tempting to fold data and security into the component diagram with a few padlock icons. For anything regulated, that is not enough. Klipspringer's design moved personal and financial information across several boundaries: from the customer's phone into the bank, from core banking into the decision service, from the decision service into the loan system, and, if the new components were hosted in the cloud, from the bank's data centre into a provider's region.
Each crossing raised questions that risk and compliance needed answered before approving anything. What personal information crosses, and is all of it needed? Which identity is used at each step? Where is the data stored, and for how long? Who can see a decision and the reasons for it? Showing those crossings explicitly, on a view designed for the purpose, was what got information security and the privacy office to sign off. A padlock icon would not have.
Bridge states are where programmes fail
The transition roadmap is the view most often missing, and the one whose absence causes the most damage. Target-state diagrams show a clean end point. Real programmes spend most of their life in between: the new upload checks are live but the decision service is not; the decision service handles existing customers but not new ones; brokers are half migrated off email.
Each of those bridge states is a working system that has to be secure, supportable and correct. Klipspringer's roadmap had four, each with its own short note on what was live, what was manual, what was being measured and how it would be rolled back. Our proposal-writing series covers this in more depth in as-is, bridge states and to-be.
The log ties it together
Every view rests on choices. The decision service will own the referral rules. Existing customers' transaction data can replace uploaded statements, with consent. The loan system's nightly batch will not be changed. Brokers have three months to move off email. Some of those are decisions, some are assumptions still to be confirmed, and some are open questions nobody has answered yet.
Writing them in one log, each with an owner, a date and a status, does three things. It makes the reasoning auditable, so that a reviewer can challenge a choice rather than a diagram. It stops assumptions from hardening into facts simply by being drawn. And it gives every audience a shared reference.
That last point matters because different audiences read different views first. Klipspringer's executive committee went straight to the outcome and the roadmap. Credit risk cared about the decision flow and who owned the rules. Information security read the trust boundaries and the deployment view. IT operations wanted the operations view and the bridge states. The delivery team lived in the components and integration flows. Each audience could start where it needed to, and all of them could see the same decisions.
How much is enough?
The set above is a floor, not a template to fill in mechanically. A small change might need only the journey, the target components and the log. A large regulated programme will need far more detail behind each view. Formal frameworks have their place, and our piece on using TOGAF, CAF and WAF without framework theatre covers when they help. Our proposal-writing series also explains why one diagram cannot answer every question.
The test we apply is simple. Hand the views to the person who has to approve the work. If they can say what problem it solves, what changes, what could go wrong and how you get there, the set is sufficient. If they ask for the forty-diagram pack, something in the minimum set is not doing its job.
Key points
Every view answers one question. If it does not, it is reference material, not a decision view.
Nine views make a sufficient floor. Why, what and how, plus a log of decisions, assumptions and open questions.
Start the review with the journey. It is the view everyone can read, and it connects the design to the outcome.
Give information and trust boundaries their own view. Regulated approvals depend on it.
Show the bridge states. Programmes spend most of their life between today and the target.
Next: Part 6, A proposal should follow the client's decision path. All parts are on the series page.
How CloudNala can help
We help architecture teams cut a sprawling pack down to the views that get a decision made: a journey that connects to the outcome, a target that shows clearly what changes, trust boundaries that risk and privacy teams can sign, bridge states that operations can run, and a decisions log that holds it all together.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Architecture Discovery Sprint or write to us at consult@cloudnala.co.za