Relativity (Stakeholder Frames)

Every observer sees the system from their own frame; none of them sees the whole truth.

Each stakeholder sees the same system through their own frame, so one system needs several views.

To an executive

Finance, operations and developers each describe the same system differently, and each is right. A proposal that does not answer their own questions will not win their support.

To an engineer

Produce different views for different concerns, such as cost, deployment, data and failure, rather than one diagram for all. Translate between viewpoints instead of defending one.

The idea

In physics, measurements depend on the observer's frame of reference. Two observers can measure the same event differently and both be right. The metaphor fits architecture well: a CFO, a developer and a regulator will describe the same system in completely different terms, and all be correct.

None of them sees the whole system, and neither does the architect. The architect's job is to translate between frames. This is why the architecture description standard, ISO/IEC/IEEE 42010, is built around stakeholders and their concerns: each viewpoint frames particular concerns for particular stakeholders, and each view applies that viewpoint to the system. No single picture serves everyone.

Why it works

People judge a system by their own concerns. An executive asks about cost, risk and time; an operations lead asks how it fails at night; a developer asks how to change it safely. A proposal that answers none of their questions will not win their support.

Several views reveal more than one. Cost, capability, deployment and data views each expose problems the others hide. Looking from several frames catches gaps a single diagram would miss.

Translation builds trust. Stakeholders who see their concern addressed in their language are more willing to engage with the rest of the design.

Where it applies

Proposals and funding requests, which must make sense to people who will never read a component diagram.
Architecture documentation, structured as a set of views for named audiences.
Cross-functional reviews, where security, finance, operations and product each bring a different frame.
Conflict between groups, where the disagreement is often about frames rather than facts.

How to apply

List the stakeholders and write down each one's main concerns, ideally in their own words.
Choose a view for each concern: cost and risk for executives, capabilities and outcomes for business leaders, components, contracts and failure modes for engineers.
Keep the facts consistent across views. The same decision, numbers and trade-offs should appear in every frame, with different emphasis.
Test the views with their audience. Ask a stakeholder to explain the view back to you; gaps show up quickly.

Example scenario

A platform proposal stalled when the architect presented it to the executive committee as a move to Kubernetes and a service mesh. The executives heard cost, risk and jargon, and asked for the proposal to come back later.

The architect rebuilt the pitch around the committee's own concerns: how much faster teams could ship changes, what it would cost over three years compared with the current estate, and how the risk of the migration would be managed in stages. The technology appeared only in an appendix. The same proposal was approved at the next meeting.

Questions to ask

What does this stakeholder care about most, in their own words?
Which view of the architecture answers their concern, and which just shows ours?
How would this decision look from their frame, and what would worry them?

When not to use it

When the facts are in dispute. If stakeholders disagree about what is true, reframing will not help; settle the facts first.
Deep technical design work among engineers who share a frame, where multiple stakeholder views add ceremony without insight.

How it misleads you

Telling each stakeholder only what they want to hear. Frames change the emphasis, never the facts. If the cost view and the engineering view tell different stories, you have created two architectures in people's heads, and the gap will surface at the worst moment.