ArchiMate defines dozens of viewpoints (e.g., Stakeholder Viewpoint, Application Cooperation Viewpoint, Technology Viewpoint) rather than expecting one master diagram to serve every audience. Why does the language rely on viewpoints, and how would you decide which viewpoint(s) to produce for a given stakeholder?

## The problem viewpoints solve An ArchiMate model of any real enterprise quickly grows to hundreds or thousands of elements spanning business, application, technology, motivation, and implementation/migration content - far more than any single diagram can present without becoming an unreadable wall of boxes and lines. Viewpoints are ArchiMate's answer to this problem: a **viewpoint** is a formally defined selection of which element types, relationship types, and layers are relevant to a particular stakeholder's concern, used to generate a filtered, purpose-built diagram from the underlying model rather than hand-drawing a new picture each time. ## What a viewpoint definition contains Mechanically, a viewpoint definition specifies: - which of the roughly fifty ArchiMate element types may appear (e.g. the **Technology Viewpoint** restricts itself to technology-layer elements, plus perhaps the application components assigned to that infrastructure, but excludes business-layer detail) - which relationships are shown - sometimes a suggested visual notation or layout convention ArchiMate's specification ships with a standard catalog of named viewpoints grouped by purpose: - **basic viewpoints** (e.g. an Introductory Viewpoint for orientation, a Layered Viewpoint for a simplified cross-layer trace) - **viewpoints for specific stakeholder concerns** (a Stakeholder Viewpoint itself, showing drivers/assessments/goals for a motivation discussion) - **viewpoints for specific layers or cross-layer relationships** (Application Cooperation Viewpoint, Business Process Cooperation Viewpoint, Infrastructure Usage Viewpoint, and others) Crucially, these named viewpoints are a starting catalog, not an exhaustive fixed list - organizations regularly define custom viewpoints tailored to a recurring stakeholder question they face repeatedly. ## Why not one canonical diagram Why the language insists on this instead of one canonical 'the architecture diagram': the underlying philosophy is that architecture exists to serve the concerns of many different stakeholders who have fundamentally incompatible information needs. - A **CFO** deciding whether to fund a modernization program needs a simple, capability-level view connecting cost to business outcome - showing them a diagram with every application interface and network segment doesn't inform their decision, it obscures it. - Conversely, a **network engineer** planning a firewall change needs exactly that interface- and segment-level detail, and a simplified capability view is useless to them. Trying to serve both audiences with a single diagram either overwhelms the executive or under-informs the engineer - viewpoints resolve this by letting the same underlying, single source-of-truth model produce multiple honest, purpose-fit projections, each true to the model, but each showing only what its audience needs. ## Choosing one for a stakeholder The practical process of choosing a viewpoint starts with identifying the stakeholder's actual concern - the specific question they're trying to answer, not just their job title. | The question being asked | What it points to | |---|---| | 'What will change for my team's systems during this migration' | calls for something like a Migration viewpoint scoped to the relevant plateau/gap | | 'does this proposed design violate our security principles' | calls for a viewpoint that surfaces motivation-layer principles alongside the technology elements being assessed | | 'what's our overall application landscape' | calls for the Application Cooperation Viewpoint | A skilled architect often needs to compose or lightly customize a standard viewpoint rather than use one off-the-shelf, because real stakeholder questions rarely map exactly to the standard catalog. ## The trade-off The trade-off with heavy viewpoint use is consistency-maintenance overhead and the risk of **viewpoint proliferation**: if every stakeholder conversation spawns a new custom viewpoint, an organization can end up maintaining dozens of view definitions, each needing to be regenerated whenever the underlying model changes, and reviewers need to understand which viewpoint they're looking at to correctly interpret it. A related, subtler risk: because a viewpoint is a filter, it can hide a problem that would only be visible in a different viewpoint - e.g., a Technology Viewpoint reviewer approves an infrastructure change because it looks clean, without realizing it breaks a business-layer service-level dependency that would only be visible in the Layered Viewpoint. ## When a viewpoint goes stale A failure mode seen in real EA practice: teams generate a viewpoint once for a specific presentation, then keep reusing that same static export for months as the underlying model changes, so the diagram silently drifts out of sync with the actual model - viewers trust a stale picture because it still looks authoritative. ## Where regeneration pays off A concrete real-world usage: a large telecom's enterprise-architecture team maintains a single underlying ArchiMate repository and, for each quarterly investment-committee review, regenerates: - a **Motivation-oriented viewpoint** for the committee - a **Layered Viewpoint** for delivery leads to see cross-layer impact - an **Application Cooperation Viewpoint** for solution architects doing detailed design All three views are generated fresh from the same model just before the meeting specifically so no one is working from a stale or inconsistent picture.