The next viewpoint is AI

The previous post leaned on Kruchten's 4+1 model: describe a system through several views because no single one is complete. What that framing quietly assumes — and what people forget — is that the set of views is not sacred. It was a well-chosen set for 1995. Which viewpoints matter is a moving target, decided by what the industry is worried about at the time. The clearest example is security, which went from something bolted on at the end to a perspective that shapes designs from the first diagram. I think the next viewpoint to earn first-class status is AI — and holding that many perspectives at once only works if they're all reads of one shared model, not a growing pile of documents.

Perspectives change with what matters

Kruchten's genius wasn't the specific four views — logical, process, development, physical — it was the "+1": the recognition that views serve concerns, and are tied together by scenarios.¹ Concerns change. When 4+1 was written, security was barely a named viewpoint in mainstream architecture practice. Today it's inescapable: threat modelling happens against the container diagram, data-flow and trust boundaries are their own analysis, and an entire discipline — DevSecOps — exists to push that concern to the left, into design and development rather than post-hoc audit. Nobody amended Kruchten's paper to add a security view. The model was extensible by design; the industry just started drawing the view it needed.

That is the pattern to expect again. A viewpoint becomes first-class when a concern becomes unavoidable and starts changing the shapes we draw. Security did it. Accessibility and privacy are doing it. And AI is next — not as a box on a diagram, but as a lens you hold the whole system up to.

What an AI perspective actually asks

An AI viewpoint isn't "where do we put the model API." It's a set of questions about how the system is shaped so that AI can work inside it:

• How do we structure the code so an AI agent can extend it safely — clear seams, explicit contracts, boundaries it can reason about without loading the entire system into its head?
• How do we expose the system so AI can monitor it — the runtime signals, the operational surface, the feedback that lets an agent notice something is wrong?
• What context does an AI need to make a change that lands inside the architecture's intent rather than beside it?
• Across the whole application lifecycle — build, extend, operate — where does AI participate, and what does it need from us to do so well?

These are architectural concerns in exactly Kruchten's sense: they cut across the logical, process, and physical views, and they're driven by a stakeholder whose importance is rising fast. Drawing them as their own perspective isn't a gimmick; it's the same move the industry made with security, applied to the concern that is currently reshaping how software gets built.

One model, many reads — or you drown

Here's the trap that kills multi-perspective ambition. Each new viewpoint tempts you to write more documents. Add security docs, data-retention docs, an operational runbook, a functional spec, an AI-integration note — and very quickly you have produced a great deal of text and very little understanding. Volume is not clarity. Drowning the reader in prose actively works against the thing a diagram was good at: getting everyone to the same picture fast.

The way out is the same insight that made 4+1 worth anything: separate the model from the views. Keep one shared repository of elements — the systems, containers, relationships, deployments — and render each perspective from it. Then a reader takes the view they need at the altitude they need it:

• A CISO wants only what touches security — trust boundaries, external touchpoints, data flows — and nothing else.
• The C-suite wants the high-level shape: what the system is, how it's deployed, at a glance.
• A CEO wants to understand what the thing even is and how the pieces come together, with none of the internals.

Same model, three reads. And because it's one shared model, a change made once shows up everywhere it's relevant. Rename an element, re-scope a boundary, add a deployable — every view that touches it updates, without a hunt through five documents to keep them consistent. That is the only way the perspective count can keep growing (security, then AI, then whatever's next) without the maintenance cost growing with it. Views are cheap when they're projections. They're ruinous when they're copies.

The principle: model once, view many. A viewpoint is a filter and a framing over a single source of truth, not a separate artifact you maintain by hand. This is what lets the set of perspectives grow with the concerns of the day.

Rules of thumb

1. Treat the view set as open, not fixed. New concerns earn new perspectives; that's the design, not a violation of it.
2. Add a viewpoint when a concern starts changing the shapes you draw. Security passed that test; AI is passing it now.
3. Frame AI as a lens on the whole system, not a component — clear seams, an observable runtime, and enough context for an agent to act inside the design's intent.
4. Never answer a new concern with a new document by default. Answer it with a new view over the existing model.
5. Make change propagate. If updating one fact means editing several files, you have copies, not views — and the perspective count will bury you.

---

CRAYON-C4 is built around "model once, view many" — one repository of elements, several perspectives derived from it, changes propagating across all of them.

Next in this series: the hard part. AI now changes code faster than any diagram can be redrawn — so how do the pictures stay true?

References

Footnotes

1. Philippe Kruchten, "Architectural Blueprints — The '4+1' View Model of Software Architecture," IEEE Software, vol. 12, no. 6, November 1995, pp. 42–50. The "+1" scenarios view ties the others together and makes the set extensible to new concerns. Paper (PDF) ↩