One Diagram, Four Stakeholders: Scoping the View
An insurer is preparing architecture materials for a program review. Four stakeholders will attend: (a) the CIO, who wants a one-page view of how IT supports the claims value stream; (b) the security officer, who wants to know which application components touch customer PII and what technology nodes host them; (c) a business process owner, who wants the detailed steps of 'Assess Claim' including the business roles involved; (d) a solutions engineer, who wants the internal wiring of the 'Claims Engine' component. The architect has drafted a single large diagram containing every element from all four concerns - roughly 180 elements - and plans to present it to everyone 'so no one feels left out.' Feedback from a prior review was that stakeholders 'couldn't find their part' and 'the diagram was unreadable.'
1. Explain, using ArchiMate viewpoint concepts, why the single 180-element diagram fails, and propose how many views to produce and what each should contain.
Read the worked answer
Why it fails: A viewpoint selects the subset of the model relevant to a stakeholder's concern and the notation to express it. A view is the instantiation of a viewpoint. A 180-element diagram is not a viewpoint - it is the whole model rendered, which by definition serves no single concern and violates the purpose of viewpoints (relevance and abstraction). Prior feedback ('couldn't find their part') is the classic symptom of an unscoped view.
Proposed: four views, one per concern.
- (a) CIO - value/capability view: business services, value stream or capability, and the application services that support them. Coarse-grained; hide internal component wiring.
- (b) Security officer - data/technology view: application components, the data objects (PII) they access, and the technology nodes hosting them; include access relationships. This is a focused cross-layer view.
- (c) Process owner - business process view: the 'Assess Claim' process decomposed into sub-processes, business roles, and business objects; application detail suppressed.
- (d) Solutions engineer - application structure view: internal components, interfaces, and application services of the Claims Engine.
Judgement rule: number of views ≈ number of distinct concerns, not number of stakeholders (two stakeholders with the same concern share a view). Each view must be defensible as 'this answers stakeholder X's question and omits what they don't need.'
2. The CIO asks for 'just one diagram that shows everything, but simplified.' How should the architect respond, and what ArchiMate mechanism supports the answer?
Read the worked answer
Respond by separating completeness from presentation. The model (the repository) can and should be complete; a view is a projection of it. 'One diagram showing everything, simplified' is a request for a summary viewpoint, not for the full model shrunk.
The ArchiMate mechanism: abstraction/aggregation in the view - collapse detail into higher-level elements (e.g., show a single 'Claims Platform' application component instead of its sub-components; show a capability instead of the processes realizing it), and rely on the underlying model to hold the detail. Optionally offer a layered overview (business → application → technology) with only the services at each boundary, which is the standard 'how IT supports the business' summary.
What to refuse: do not present the 180-element diagram with smaller fonts or color-coding as a substitute for scoping - that is a presentation fix to a modeling problem. Tell the CIO: 'The complete model is in the repository and queryable; here is the one-page summary view of it, and here are the detailed views for those who need them.' This preserves traceability while respecting the viewpoint principle.