The Ten Views of a Digital Solution

Most digital solutions are poorly documented — not because teams don’t care, but because documentation feels difficult, time is always short, and there’s rarely a shared understanding of what complete documentation actually requires. Without that, teams document what they know how to document and skip the rest. The result is gaps that only become visible when something goes wrong, a key person leaves, or a regulator asks a question nobody can answer.

This is well-trodden ground. The 4+1 architectural view model, ArchiMate, TOGAF, the C4 model, and many others have mapped the documentation landscape for decades. I am not proposing a new framework. What follows is my expression of what I believe a well-documented digital solution actually needs — shaped by practical experience with solutions that failed their owners because the wrong things were left undocumented.

The ten views below are the ones I think every solution should be considered against. Each answers a different set of questions and produces different artefacts. Not every solution will need all of them in full — but skipping a view should be a conscious decision, not a default. Together, they create a record that can be understood, operated, audited, and eventually decommissioned by people who weren’t in the room when it was built.

Not every view requires the same level of detail either. A simple internal tool doesn’t need the same coverage as a regulated platform operating across organisational boundaries. The depth required within each view is largely determined by the solution’s security classification — but how to make that determination is a topic for another post.

One thing the ordering doesn’t imply: a sequential process. In practice, working the views is iterative — you move between them as each one informs and clarifies the others. A component discussion surfaces a gap in the information model. A process walkthrough exposes an accountability that was assumed but never stated. Domain work reshapes requirements. The order reflects dependency and priority; the work is exploratory and cyclical, with each pass filling in more of the picture.

Of the ten views, Requirements comes first — it establishes what the solution must achieve, for whom, and under what constraints. Every other view is shaped by what is captured there. How you express requirements in the first place matters as much as where you record them. I’ve touched on this in the Stakeholder Stories post. That said, don’t aim for completeness before moving on — working the other views will surface requirements you didn’t know to ask for. Capture what you know, move forward, and return as the picture sharpens.

The Views I Work With

These are the views I return to on every engagement. For years I worked within formal frameworks — TOGAF, ArchiMate, the 4+1 model — and they taught me a lot about structured thinking. But over time I developed my own take — a different way of cutting the problem — one I found more practical to work with in the field. These ten emerged from that experience: from solutions where missing one of them created real problems, for the team, for the business, or for the people auditing it afterwards:

A solution documented across all ten views can be handed to a new team, audited by a regulator, extended by an architect who wasn’t there at the start, and eventually decommissioned without leaving orphaned dependencies or unresolved obligations.

These ten views form the documentation backbone of the Digital Solution Lifecycle Model I’m building — an opinionated framework for taking solutions from first design to reliable operation and eventual decommission.

The Ten Views

Requirements View

Purpose. The requirements view makes explicit what the solution must achieve before any design decisions are made. Without it, every other view risks being built on assumptions rather than agreed outcomes. It is the view that connects stakeholder needs to documented artefacts — and makes it possible to trace every design decision back to a stated requirement.

What matters. Stakeholder outcomes — what each affected party needs the solution to achieve. Functional requirements — what the solution must do. Non-functional requirements — performance, availability, security, scalability, and other quality attributes. Compliance and regulatory obligations — what the solution must satisfy by law, policy, or contractual agreement. Acceptance criteria — how each requirement will be demonstrated to be met.

Deliverables.

Customer View

Purpose. The customer view documents who interacts with the solution from the outside — their drivers, goals, and the channels through which they engage. It is the outside-in perspective that grounds every other view in real user experience. Without it, design decisions are made for an assumed user who may not reflect the people actually affected by the solution.

What matters. Customer and user segments — the distinct groups of people the solution serves or affects. Their drivers and goals — what they are trying to achieve and why. The channels through which they interact with the solution. The customer journeys — the sequences of touchpoints and decisions that make up their experience. The value moments — where the solution succeeds or fails in meeting customer expectations at the points that matter most.

Deliverables.

Current State View

Purpose. The current state view documents what exists before any design work begins. It is only relevant for brownfield solutions — where you are changing, extending, or replacing something that already exists. Skipping it in those contexts is one of the most reliable ways to introduce integration failures, inherit undocumented constraints, and underestimate decommissioning complexity.

What matters. The as-is version of each applicable view: current customer journeys, current domain model, existing systems and components, active processes, current deployment topology, and known information assets and obligations. Technical debt — known issues, constraints, and compromises inherited from the current state. Decommission candidates — what will be retired and when. The gap between current and target state, view by view. Pain points and friction in current processes and journeys — where the existing solution or ways of working are failing the people who depend on them.

Deliverables.

Domain View

Purpose. The domain view establishes the high-level business landscape before any technical detail is introduced. It maps the business domains, defines bounded contexts, and makes explicit where the solution sits within the broader domain model. It is the view that prevents two teams from using the same word to mean different things, and from building integrations that silently corrupt data because domain boundaries were never agreed.

What matters. Business domain identification and their relationships. Bounded context definitions with clear responsibility boundaries — what each context owns and what it does not. Ubiquitous language: the terms agreed within each context that all documentation, code, and conversation must use consistently. Context maps showing how bounded contexts relate — partnership, customer-supplier, shared kernel, anti-corruption layer, or open-host service. Domain events that cross context boundaries. Aggregate boundaries and their consistency rules.

Deliverables.

Information View

Purpose. The information view establishes the information model — the information the solution creates, stores, processes, or transmits. It is the foundation everything else builds on. Without it, data model decisions are made ad hoc, information is misclassified or never classified at all, compliance obligations are discovered late, and nobody has a clear picture of what the solution actually handles.

What matters. The conceptual entity model with relationships and attributes. Information ownership and stewardship assignments. Classification of all information assets — sensitivity, handling requirements, and where applicable, sovereign or security classification. Compliance obligations: personal data register, legal basis for processing, retention schedule, and data flow classification showing where information moves and at what level. Audit log classification — log content inherits the classification of the information it records or gives access to.

Deliverables.

Organisational View

Purpose. The organisational view is where every actor, owner, and role referenced in the other views gets their organisational identity. It does not describe what people do — that belongs to the process view — or what they can access — that belongs to the information view. What it captures is accountability: who owns what at the organisational level, who has the authority to approve decisions, and who is answerable to regulators, auditors, and external parties when something fails.

What matters. Named ownership of the solution and each of its information assets — the entities that appear as owners in the information view are defined and grounded here. The actors that appear in component and sequence diagrams, and the roles that appear in process flows, have their organisational home here: their accountability, authority, and reporting position. External party relationships at the organisational level. Regulatory scope and compliance obligations by unit. Authority chains for security decisions and exception approvals.

Deliverables.

Process View

Purpose. The process view covers how people interact with the solution — manual activities, human-in-the-loop handoffs, and the operational workflows the system supports but doesn’t fully automate. It makes explicit what a sequence or component diagram leaves invisible: the human steps, the exceptions, and the approval gates.

What matters. Manual activities and role assignments. Human-in-the-loop handoffs between automated and manual steps. Exception and escalation paths — not as afterthoughts but as first-class documented flows. Security approval gates and the authority required at each decision point. The distinction between informal process diagrams used for discussion and formal, baselined process models that define how the solution is actually operated — and which processes fall into each category.

Deliverables.

Component View

Purpose. The component view maps the static landscape — the systems, the actors that interact with them, the components those systems contain, the interfaces those components expose, and how everything is statically connected. It is the most familiar view for technical teams, but it is often underdeveloped: component boxes without clear responsibility definitions, interfaces without protocol or data specification, and trust boundaries left implicit.

What matters. Components with explicitly defined responsibilities — what each component does and what it doesn’t. Integration points with direction, protocol, and data exchanged. Trust boundaries with explicitly classified cross-boundary interactions. Formal data models: both logical (what entities exist and how they relate) and physical (schemas, constraints, storage design). API specifications for all endpoints. A dependency map with version constraints.

Deliverables.

Sequence View

Purpose. The sequence view takes the static landscape of the component view and layers scenarios on top of it — showing how the solution actually works when used. For a given scenario, it makes explicit which actors initiate the flow, which components are involved, what messages and data pass between them, in what order, and under what conditions. Where the component view shows what exists, the sequence view shows what happens.

What matters. Scenario coverage — the key flows that reveal how the solution behaves in normal operation, under error conditions, and in exception paths. The actors that initiate each scenario and their entry points into the system. The sequence of component interactions, including the messages and data exchanged at each step. Authentication and authorisation at each boundary crossing. Trust zone transitions — especially where data moves between classification levels. Personal data flows through the solution from entry to exit.

Deliverables.

Deployment View

Purpose. The deployment view documents how the solution is hosted and how it is released. It records the infrastructure decisions that have been made — where components run, how environments are separated, how the network is structured, and how changes move from development to production. It is the view that makes hosting decisions explicit and auditable, and that shows how the physical and regulatory constraints identified elsewhere in the documentation have been addressed in the design.

What matters. The infrastructure topology — where components are hosted and how they connect. The environment separation design — how environments are divided and what controls exist between them. The network topology — boundary placements, zone definitions, and the controls enforced at each. The release pipeline design — the stages and gates that govern how changes are promoted. The data residency design — where data is physically stored and how jurisdictional obligations are met. The physical security and isolation design — zone classifications, isolation mechanisms, and air-gap arrangements in place.

Deliverables.

The Full Picture

Ten views is a lot — but no single view is complete without the others. A requirements view without a customer view can capture what must be built but miss who it needs to work for. Requirements without a domain model can produce technically correct solutions to the wrong problem. A component view without an information view leaves data classification invisible. A deployment view without an organisational view tells you where the system runs but not who is accountable when something fails.

The views are designed to be used together. Each illuminates something the others don’t — and the gaps between them are often exactly where the most consequential design decisions get made implicitly rather than explicitly. A solution documented across all ten can be understood, operated, audited, extended, and eventually decommissioned by people who weren’t there at the start. That’s the standard worth aiming for.

These ten views are the documentation backbone of the Digital Solution Lifecycle Model — a broader framework I’m building for taking solutions from first design through reliable operation to eventual decommission.