4+1 and C4 are both viewpoint sets. When would you extend or replace them with additional views, and what governs adding a new view to your organisation's standard set?

## Framing: the named models are menus Kruchten's **4+1** (logical, process, development, physical, + scenarios) and Simon Brown's **C4** (context, container, component, code, plus deployment/dynamic/landscape) are both, in ISO/IEC/IEEE 42010 vocabulary, **viewpoint sets** — reusable conventions chosen because they cover the concerns most systems have. Neither claims completeness. A third widely used catalogue, **Rozanski & Woods**, is explicit about this: it defines six viewpoints (functional, information, concurrency, development, deployment, operational) *and* a separate orthogonal concept, **perspectives** — security, performance and scalability, availability and resilience, evolution, accessibility, regulation — applied *across* views rather than drawn as views. The principal-level skill is knowing which mechanism to reach for, and knowing that every artefact you standardise on becomes a permanent tax on every team. ## What each popular set leaves uncovered | Concern | 4+1 | C4 | |---|---|---| | Runtime concurrency, threads, queues, backpressure | Process view | **Not covered** (dynamic diagrams show flows, not concurrency structure) | | Deployment topology | Physical view | Deployment diagram | | Source/module dependency rules | Development view | Component (partially) | | Information: ownership, lifecycle, residency, retention | **Weak** | **Weak** | | Operational: monitoring, backup, upgrade, runbooks | **Not covered** | **Not covered** (Rozanski & Woods' operational viewpoint fills this) | | Cost / capacity economics | Not covered | Not covered | | Regulatory / safety evidence | Not covered | Not covered | | Rationale for decisions | Not covered | Not covered (use ADRs) | The two "not covered" rows that bite most often in practice are **operational** (who gets paged, how it is backed up, how it is upgraded without downtime) and **information** (who owns which data, where it may legally reside, how long it is kept). ## The decision procedure for adding a view **1. Is there an unanswered concern with a named stakeholder?** No named stakeholder, no view. "It would be nice to have" is not a concern. **2. Can an existing view answer it with annotation instead?** This is the most-skipped step and usually the right answer. Trust boundaries and data classification annotated onto the container and deployment views serve security better than a standalone "security diagram", which typically re-draws the same boxes while answering nothing new. Same for latency budgets on a dynamic diagram, or cost drivers on a deployment diagram. Prefer **perspective over new view**. **3. Is the concern's risk material in this domain?** A hard-real-time controller genuinely needs a concurrency view; a CRUD web app does not. A system holding EU personal data across regions needs a data-residency view; an internal reporting tool does not. Domain risk, not fashion, justifies the addition. **4. Can it be executable or generated rather than drawn?** A dependency rule is better as a fitness function (ArchUnit, dependency-cruiser) than a picture. A deployment view is better generated from infrastructure-as-code. An interaction map is better generated from tracing. Executable and generated artefacts do not drift, so their long-run cost is far lower. **5. Define it properly as a viewpoint, or don't add it.** A standardised addition must specify: stakeholders addressed; concerns framed; model kinds and notation; construction guidance; **correspondence rules** linking it to existing views ("every data store in the information view maps to a container"); analysis/review checklist; owner; update triggers. **6. Price the standing cost.** One extra mandated view across forty teams is forty artefacts to author, review, and keep current forever. Compare that against the risk it retires. Many additions should be *optional and situational* rather than mandatory — a catalogue teams draw from when the concern applies, not a checklist everyone completes. ## Replace versus extend **Extend** is the normal case. **Replace** the base set only when the domain's dominant concerns are structurally different from general enterprise software: - **Embedded / safety-critical**: hazard analysis, timing/schedulability and traceability-to-requirements views dominate; general-purpose sets under-serve them and standards (for example the automotive and aviation processes) effectively mandate their own. - **Data platforms**: lineage, ownership, schema evolution and residency dominate; a container diagram is almost incidental. - **ML systems**: training-versus-serving topology, data and feature lineage, model versioning and rollback are the real risks and appear in none of the classic sets. ## Governance considerations at organisation scale - **House notation buys comparability.** If every team draws C4 with the same legend conventions, a reviewer can read any team's diagram cold, and tooling can be shared. That comparability is often worth more than any individual view's content. - **Coverage, not conformance, is the goal.** The review question is "is every material concern framed by some view or perspective?", not "did you produce all five diagrams?" Explicitly listed gaps are acceptable; invisible ones are not. - **Rationale is separate and immutable.** ADRs record context, decision, alternatives and consequences; superseded ones are marked, not deleted. Views show *what*, ADRs show *why*, and only the latter survives a structural rewrite. - **Sunset views too.** Adding is easy and removing is rare; schedule a periodic check for artefacts with no readers and retire them. A view nobody reads still costs review time and still misleads when stale. - **Beware the checklist reflex.** The moment a viewpoint set becomes an audit checklist, teams produce artefacts to pass the audit rather than to answer questions, and the whole set loses credibility.