The vocabulary that does the work

ISO 42010 gives precise words for this, and using them precisely is half the benefit:

• A stakeholder is anyone with a stake in the system: developers, operations, security, management, external integrators.

• A concern is what a stakeholder cares about: data ownership, blast radius, open ports, deployability.

• A viewpoint is the convention for addressing a set of concerns, the kind of diagram.

• A view is the concrete artifact you get by applying a viewpoint to your system.

• A correspondence is an explicit relation linking elements across views. Correspondences keep multiple views consistent instead of letting them drift apart.

So far, so standard. The distinction which actually keeps architecture documentation coherent, and the one I see collapsed most often, comes next.

Viewpoints versus perspectives

A viewpoint produces a structural view: a slice of the system, such as functional structure, information structure, or deployment. Views are siblings, each shows a different part.

A perspective is a cross-cutting concern applied across views: security, availability, performance, data quality. A perspective is not a sibling view but a quality lens you run over the structural views.

You do not draw "the security diagram" or "the observability diagram". You ask the security perspective of the context and deployment views, and the availability perspective of the information and operational views. From my experience, treating perspectives as peer views is the primary source of muddled architecture documentation: The "security architecture" picture duplicates half the deployment view, the two drift apart, and soon neither is trusted.

This split comes from Rozanski and Woods' Software Systems Architecture [3] , and the 2022 edition of ISO 42010 ratified it: The separation is standard now, not just one book's convention.

Don't invent your viewpoint set

There is no need to design your own catalogue of views. Two established models compose well:

• Rozanski & Woods provide the catalogue: seven viewpoints (Context, Functional, Information, Concurrency, Development, Deployment, Operational) and a perspective catalogue (Security, Performance, Availability, Evolution, and more).

• C4 (Simon Brown) [4] provides the notation: Context → Container → Component → Code as zoom levels.

These are complementary, not competing. C4 tells you how to draw and how to zoom. Rozanski & Woods tell you which views and perspectives to produce for which stakeholders.

And you are allowed to skip viewpoints, deliberately and with a documented reason. On our platform we omit the Concurrency viewpoint entirely: The system is batch ELT plus change-data-capture with strictly downstream flow, so there is no shared mutable state or process-coordination story worth documenting. An explicit "out of scope because…" is worth more than a half-hearted diagram.

A worked example

For our data platform the catalogue will probably boil down to five views, each with a named audience:

• System Context: What the platform is, what sits outside it, who talks to it. For management and integrators.

• Domain / Context Map: Bounded contexts, ownership, domain dependencies. For domain owners and architects.

• Functional / Component: Services, responsibilities, dependency and data-flow direction. For developers.

• Information / Data Ownership: Which domain owns which data, where it lives, how it flows. For data stewards.

• Deployment: Where containers run, infrastructure mapping. For operations.

The perspectives (security, data quality, audit) are overlays on these views, not additional diagrams. The security perspective is the access-and-ports overlay on the context and deployment views. The data-quality perspective is the issue-event overlay on the information view. Nobody maintains a separate security diagram, so nothing drifts.

The views stay consistent through explicit correspondences. On a data platform the most important correspondence is the data contract: the versioned, CI-enforced relation between a producing data product's interface and its consumers' expectations. A contract is not a view and gets no diagram of its own. It is an interface annotation on a component, resolving to concrete tables and topics only at the deepest zoom level.

Summary

The real asset is not any single diagram but the unified model behind them: domains, components, contexts, flows, and quality events, mapped and queryable. Most teams do not have this, they have a pile of disconnected drawings. Once the model exists, the right 2D view per audience becomes a cheap, on-demand projection: ports and trust boundaries for security, animated flows for operations, a context map for domain owners. Projecting per audience is the operationalization of "no single useful view".

So when someone asks for "the architecture diagram", the productive answer is a question back: Who is it for, and what do they need to decide? Once that is answered, the diagram is usually easy. It is the audience-free version which is impossible.

References

1

Kruchten, P. (1995). "Architectural Blueprints — The '4+1' View Model of Software Architecture." IEEE Software 12(6).

2

ISO/IEC/IEEE 42010:2022. Software, systems and enterprise — Architecture description.

3

Rozanski, N. & Woods, E. (2011). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. 2nd ed.

4

Brown, S. The C4 model for visualising software architecture. c4model.com.