The Executive Summary That Wasn't
An architect presents a 60-element ArchiMate view to a steering committee of five executives. The view shows the full application and technology layers behind a customer onboarding journey. Ten minutes in, the CFO asks 'so what does this cost us and what changes?', the COO asks 'where does my team touch this?', and the CTO asks 'which of these boxes are we retiring?'. The architect answers each by pointing at elements and tracing arrows live. The committee asks for 'the same picture, but for us'. A colleague suggests simply hiding the technology layer and calling it an executive view.
1. Why did the single view fail this audience, and what does ArchiMate say about view purpose?
Read the worked answer
The view failed because it was built for completeness, not for a stakeholder concern. ArchiMate separates the model (the full repository) from the view (a selection relevant to a concern). A 60-element view spanning three layers answers an architect's question ('what is the full landscape?') but not an executive's ('what changes, what does it cost, who is affected?').
Live arrow-tracing is a symptom: the architect was doing the selection work verbally that the view should have done visually. Each executive had a different concern - cost/change (CFO), ownership/touchpoints (COO), retirement (CTO) - and one view cannot serve three distinct concerns well.
The ArchiMate answer is viewpoint-driven: identify the stakeholders and their concerns first, then select the elements and relationships that address each concern, then choose a notation. The model stays whole; the views are purpose-built slices of it.
2. The colleague suggests hiding the technology layer and calling it an executive view. Evaluate this.
Read the worked answer
Hiding a layer is a presentation trick, not a viewpoint. It may reduce clutter, but it does not answer any of the three questions:
- The CFO still cannot see cost or change.
- The COO still cannot see team touchpoints.
- The CTO still cannot see retirements - and hiding technology removes exactly the elements the CTO was asking about.
Worse, hiding a layer can break the view's coherence: if application services were serving technology services, removing the technology leaves serving relationships pointing at nothing, or silently drops the dependency the executives might need to understand risk.
A real executive viewpoint would instead:
- Select a small number of business-level elements (the onboarding journey, key services, the capabilities that change).
- Annotate change and retirement explicitly (e.g. colour or a state attribute) rather than relying on layer removal.
- Push cost and ownership into attributes or a companion table, since ArchiMate has no native cost element for this purpose.
Hiding is not selecting; selection is deliberate and justified by the concern.
3. Propose how many views to produce for this committee and what each should contain.
Read the worked answer
Three views, one per concern, all drawn from the same model:
- Change and cost view (CFO). Business services and processes on the onboarding journey, with the elements that change marked, plus the capabilities affected. Keep it to roughly 10–15 elements. Cost is carried as attributes or a side table, because ArchiMate does not model money natively here.
- Ownership and touchpoint view (COO). Business actors/roles and the business processes and services they own or participate in. This answers 'where does my team touch this' directly, using assignment and participation relationships. No technology layer.
- Retirement and lifecycle view (CTO). Application and technology components with their state (retained, retiring, new) made explicit. This is the one view where the technology layer is essential, not hidden.
All three derive from the single repository, so they stay consistent. Present the change view first, then take the other two as needed. The point is that each view is justified by a stated concern, not by what was convenient to hide.