Why one view fails everyone
A repository serving a whole organisation contains business capabilities, applications, data entities, technology platforms, security controls, requirements, work packages and decisions. Publish all of it to everyone and each reader wades through four fifths of a model that has nothing to do with their question.
The instinct is to filter. Give people a type filter and let them narrow it themselves. This reliably fails, for a reason worth understanding: the reader does not know your metamodel. They do not know that what they call "a system" is an Application Component, or that the thing they need is filed under Technology Service. Asking them to filter is asking them to learn your modelling conventions in order to read your output.
Perspectives as editorial decisions
A perspective is better understood as a claim: this audience should not have to read the rest. That makes it an editorial decision, and editorial decisions need an owner who is prepared to defend them.
Five perspectives cover most organisations. The names matter less than the boundaries:
| Perspective | Reader | The question they arrive with |
|---|---|---|
| Executive / portfolio | Exec committee, transformation leads | Are we investing in the right things, and are they connected? |
| Application | Delivery leads, solution architects | What exists, what does it depend on, what will I break? |
| Data | Data office, privacy, analytics | Where does this data live, who owns it, how is it classified? |
| Security & risk | CISO function, risk, audit | Which controls apply, and where is the evidence? |
| Technology | Platform and operations teams | What runs where, and what happens when it fails? |
Naming perspectives so readers self-select
A perspective's name does a job no other text on the portal does: it is read by someone who has not yet chosen where to go, in the two seconds before they choose wrongly. Naming is therefore not cosmetics — it is the routing layer, and it fails in a specific direction: names drawn from the practice's own vocabulary. "ArchiMate Application Layer" routes architects perfectly and nobody else at all; the delivery lead it exists for does not know the word ArchiMate and should never need to.
Name each perspective after its reader's situation, in the reader's words. "Planning a change" beats "Application architecture"; "Data & privacy" beats "Information layer"; "Risk & controls" beats "Security viewpoint catalogue". The test is mechanical: put the five names in front of someone from each audience and ask which is theirs — every audience should choose correctly, instantly, without a tour. Add one sentence of landing copy under each name saying who it is for and what it answers, and resist the completeness instinct that wants to list what it contains; the reader is choosing a door, not auditing an inventory.
One name deserves special care: the default. Whatever the portal shows before any choice is itself a perspective, and making it the full unscoped repository re-creates the original problem for everyone who never clicks. The strongest choice is a genuine home: the two or three questions each audience most often brings, as links routed into the right perspective — which turns the landing page into the routing layer working as designed, rather than a lobby everyone hurries through.
Getting the boundaries right
Two rules save most of the pain.
An element may appear in several perspectives
A payment orchestration platform is an application to delivery, a control point to risk, and a workload to operations. Perspectives are not a partition. Trying to assign each element to exactly one is where these designs go wrong — you end up with arguments about ownership of a box rather than about what readers need.
Every perspective needs an entry point
A perspective that drops the reader into an alphabetical element list has failed. Each one should open on something that orients: a landscape diagram, a capability map, a catalogue with the twenty things that matter. If you cannot name the landing artefact for a perspective, the perspective is not designed yet.
The trap: publishing your org chart
A recurring mistake is defining perspectives around internal team structure — one per architecture chapter, one per domain team. It feels natural because that is how the repository is maintained.
It fails because readers are not organised the way you are. A delivery lead does not want "the integration chapter's view"; they want everything relevant to the change they are making, which cuts across three chapters. Perspectives should follow questions, not maintainers.
A quick check: if a perspective's name contains a team name, it is probably an ownership boundary rather than a reader boundary. Rename it after the question it answers and see whether the scope still makes sense.
The same element, in the reader's words
Scoping decides what each audience sees; there is a second decision hiding behind it about how it is described, and portals that get the first right and the second wrong still leave readers stranded. The executive perspective that faithfully shows twelve Application Components with their repository names — APP-CRM-CORE-V2, Payment Orchestration Svc (Target) — has scoped perfectly and communicated nothing.
The model usually already contains the material for better: a business name alongside the technical one, a one-line purpose in the documentation, a capability link that says what the thing is for. Rendering per perspective means choosing, per audience, which of these leads. The executive view leads with the business name and the capability; the delivery view leads with the technical name because that is the string in the deployment scripts; the risk view leads with whatever the control framework calls it, because the auditor's cross-reference is the point. Same element, same page underneath, different first line — and the search index carries all the names at once, so every audience finds it in their own vocabulary.
This is also the honest answer to the recurring stakeholder complaint that the portal is "too technical". The complaint is almost never about the content — executives are entirely comfortable with complexity in their own domains. It is about being made to translate. A portal that speaks each audience's language at the surface, while keeping one model underneath, does the translation once, centrally, instead of asking every reader to do it at every visit — which is, compressed to a sentence, the entire business case for publishing perspectives at all.
The sixth audience: machines
The perspective table lists five human audiences, and most estates acquire a sixth within a year: other systems. The CMDB wants the application inventory; the data catalogue wants entities and their owners; the security tooling wants the control mappings; a programme dashboard wants status fields. Each arrives as a one-off request, gets served by a one-off export, and the exports quietly become load-bearing integrations with no contract.
Treat the machines as a perspective and the mess becomes a design. A machine perspective has a scope like any other — the elements and properties this consumer is entitled to — and its "rendering" is structured files rather than pages: the same catalogue that renders as a table for humans, emitted as JSON or CSV at a stable path with a stable schema. It inherits the publication cadence, so consumers know exactly how fresh the data is; it inherits the quality gate, so a broken model does not propagate into the CMDB; and it inherits the manifest, so when the two systems disagree, the export's provenance settles which week's truth it carried.
The one discipline machines add is schema stability. Renaming a column in a human table is a Tuesday; renaming a field in a feed breaks a consumer you may not know exists. Version the machine perspective's schema explicitly, announce changes ahead, and keep the previous shape available for a transition window — ordinary integration hygiene, applied to architecture data, which is what the repository has become the moment the first system subscribes to it.
How many is too many
Beyond about eight, perspectives stop helping. Readers cannot tell which one they want, and the choice itself becomes a barrier — the exact problem perspectives were meant to remove. If you find yourself needing twelve, the real requirement is usually search plus two or three good catalogues, not more scoped views.
Start with three. Add a fourth when a specific audience demonstrably cannot answer their questions in the existing ones. Perspectives added speculatively are almost never used, and each one is a thing you have committed to keeping coherent.
Deriving perspectives from your metamodel
A perspective has to be computable. "Everything relevant to delivery" is an intention; the publication needs a rule it can evaluate against every element.
Three mechanisms, in increasing order of maintenance cost:
By element type
The cheapest and the most brittle. An application perspective is "Application Components, Application Services, Interfaces". It works until someone models something important as a type you did not list, and it fails silently — the element simply is not there.
By package
Robust and coarse. If your repository structure already reflects domains, this needs no additional metadata. The limitation is that an element lives in one package, so anything genuinely cross-cutting has to be duplicated or arbitrarily assigned.
By tagged value
The most flexible and the most work. An explicit Audience or Perspective property, maintained per element. Powerful, and it decays the moment nobody is checking it — an element with no value appears in nothing, which is the worst failure mode because it is invisible.
In practice a combination works best: type plus package as the default, with a tagged value as an override for the elements that genuinely need one. That keeps the maintenance burden proportional to the number of exceptions rather than to the size of the model.
A worked cut of one repository
Numbers make the editorial argument concrete. Take a mid-sized estate: 620 elements after the gate has had its say. The five-perspective cut of that repository, in one real engagement, came out as follows: the application perspective carried 210 elements — components, services, interfaces and their immediate dependencies. Data carried 140, of which forty also appeared in the application view, because a data store is legitimately both. Security and risk carried 90, mostly controls and the platforms they attach to. Technology carried 160. The executive view carried 28 — capabilities, programmes and the dozen platforms that appear in board conversations — and that number is the point of the example.
Twenty-eight is not a failure of coverage; it is the editorial claim working. The executive perspective asserts that its audience should not have to read the other 592 elements, and the assertion held — the questions that audience brought were answerable from the twenty-eight, with links downward for the rare reader who wanted the detail. Meanwhile roughly sixty elements appeared in no perspective at all: internal modelling scaffolding, a retired subtree awaiting archival, two packages of imported reference content. The coverage report listed them, an architect confirmed each was deliberate, and the confirmation took one coffee. That is the whole system behaving: overlapping scopes where reality overlaps, a tiny curated view where attention is scarcest, and an exception list short enough to actually read.
Testing a perspective before you ship it
A perspective that looked sensible in design frequently fails on contact, and the failure is easy to detect if you look for it.
- Count the elements. A perspective containing 80% of the repository is not scoped. One containing twelve elements is probably a diagram, not a perspective.
- Check the entry point. Open it as a reader would. If the first screen is an alphabetical list, it has no orientation.
- Follow three real questions. Take three questions that audience actually asked and try to answer them from within the perspective alone. If you have to leave it, the boundary is wrong.
- Look for dangling references. Elements whose relationships point at things outside the perspective are common and usually fine — but if most of an element's context is outside, it does not belong.
The third check is the one that matters. A perspective exists to let someone answer their question without knowing the metamodel. If answering requires leaving it, you have built a filter rather than a perspective.
Each perspective needs an editor
Calling perspectives editorial decisions has a consequence that deserves its own paragraph: editorial products need editors. Each perspective should have a named owner — not necessarily its maintainer, but the person who answers for whether its audience can still answer their questions in it. The role is light: review the perspective's scope when the coverage report flags gaps, walk the three-questions test once a quarter, and speak for the audience when a modelling change threatens their view. What the role prevents is heavier: the orphaned perspective, still generated weekly, slowly diverging from its audience's needs, kept alive because removing things feels riskier than ignoring them.
Ownership also supplies the missing verb for perspectives that have stopped earning their generation: retire. If the adoption numbers show a perspective with nine visits a quarter, its editor either fixes it or closes it — with a redirect to where its content lives now, the same courtesy any publication owes its readers. A portal that has retired a perspective or two is a portal being run on evidence; one that has only ever added them is accumulating shelf-ware with a build step. The five-perspective table at the top of this article is a starting point, not a constitution, and the editors are how it stays negotiable.
Keeping them coherent over time
Perspectives decay in a predictable way: new content gets modelled, nobody assigns it, and the perspective quietly stops being complete. Nothing breaks, so nothing raises an alarm.
The countermeasure is a report rather than a rule — a list, produced with each publication, of elements that appear in no perspective. It is usually short, it is usually a genuine oversight, and reviewing it takes an architect five minutes a month. Without it, the drift is invisible until a reader complains that something obvious is missing.
Starting smaller than five
If the five-perspective table reads as a quarter's work, start with two and a promise. Publish the application perspective — it serves the audience that asks the most questions — and the executive view, which is small enough to curate by hand while the mechanics mature. Tell the other audiences what is coming and when, which costs a paragraph on the landing page and buys patience. Two well-edited perspectives that answer real questions will do more for the portal's reputation than five generated ones nobody shaped, and the requests that arrive in the meantime — "could we get a view of the data landscape?" — are the best possible input for designing the third, because they arrive with a named audience and an actual question attached, which is precisely the material a perspective is made of.