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. 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 artifacts. 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 organizational 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.

The starting point depends on whether you are working on something that already exists. For brownfield solutions, Current State comes first — understand what you are working with before designing what you want. For all solutions, Domain follows: it establishes the business landscape, the shared language, and the bounded contexts that every other view depends on. Requirements then builds on that foundation — defining what the solution must achieve, for whom, and under what constraints, now informed by what exists and the domain it operates in. How you express requirements 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.

If you are coming from an established framework, here is a rough orientation. The System and Interaction views cover similar ground to the Logical and Process views in 4+1; the Operational view maps to 4+1’s Physical view. C4’s Context and Container diagrams live within the System view here. ArchiMate’s Application and Technology layers span the System, Interaction, and Operational views. What the Ten Views adds — and what most architecture frameworks leave out — is the non-technical ground: Current State, Domain, Customer, Information, Organizational, and Process. These are the views that aren’t code, aren’t diagrams of running systems, and aren’t deployment topology — but they are the views where most solutions actually fail their owners. The mappings are loose by design; the intent is orientation, not formal alignment.

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

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.

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 artifacts — 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.

Organizational View

Purpose. The organizational view is where every actor, owner, and role referenced in the other views gets their organizational 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 organizational 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 its information assets — defined here so that the information view can assign stewardship to parties that already have an organizational identity. The actors that appear in component and sequence diagrams, and the roles that appear in process flows, have their organizational home here: their accountability, authority, and reporting position. External party relationships at the organizational level. Regulatory scope and compliance obligations by unit. Authority chains for security decisions and exception approvals.

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.

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.

System View

Purpose. The system view maps the static landscape at two levels. The systems diagram shows all actors and systems as connected black boxes — who interacts with what, and how systems relate to each other. The component diagram zooms into a single system to reveal its internal structure: APIs, domain layer, data stores, and event queues. It is the most familiar view for technical teams, but it is often underdeveloped: systems without clear responsibility definitions, interfaces without protocol or data specification, and trust boundaries left implicit.

What matters. Systems with explicitly defined responsibilities — what each system 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.

Interaction View

Purpose. The interaction view takes the static landscape of the system 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 system view shows what exists, the interaction 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.

Operational View

Purpose. The operational 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 system view without an information view leaves data classification invisible. An operational view without an organizational 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.