There’s a failure pattern that CIOs, PMs, and Enterprise Architects (EAs) run into again and again on automotive Tier 1 SAP S/4HANA global rollouts: the team produces a mountain of documentation, yet both the executive floor and the plant floor come away feeling that none of it actually answers their questions. The TOGAF® Standard addresses this problem directly by defining Stakeholder, Concern, Architecture View, and Architecture Viewpoint as a rigorous, formal model rather than a loose glossary of terms. TOGAF® states: “The TOGAF® Standard takes a formal modeling approach to understanding stakeholder, concern, and view” work · blog. That formal model is, in effect, a blueprint for making sure every deliverable can be traced back to a real stakeholder’s real concern. This article breaks down that modeling approach and shows, with a concrete example, how it applies to an automotive Tier 1 supplier’s SAP rollout.
The Structure of TOGAF’s Formal Modeling Approach
TOGAF’s content metamodel defines a set of elements — System-of-Interest, Stakeholder, Concern, Architecture Description, Architecture Viewpoint, Architecture View, Model Kind, and Architecture Model — connected through a relationship diagram with strict multiplicities (1-to-1, 1-to-many, and so on). TOGAF® defines Stakeholders as “individuals, teams, organizations, or classes thereof, having an interest in a system,” and Concerns as “interests in a system relevant to one or more of its stakeholders” work · blog.
The skeleton this diagram reveals is a five-step chain of traceability:
| Step | Relationship | What It Means |
|---|---|---|
| 1 | System-of-Interest has interests in Stakeholder | Multiple stakeholders have an interest in the target system |
| 2 | Stakeholder has Concern | Each stakeholder holds one or more concerns |
| 3 | Architecture Viewpoint frames Concern | A viewpoint (template) frames how a concern will be addressed |
| 4 | Architecture Viewpoint governs Architecture View | The viewpoint governs the actual view (deliverable) produced |
| 5 | Architecture View addresses Concern | The resulting view answers the original concern |
Archimetric’s analysis of this same model confirms the chain: “Architecture viewpoints frame concerns… Architecture views address concerns… Architecture viewpoints govern architecture views” work · blog · headings. The core value of this modeling approach, in other words, is making it possible to verify — after the fact — exactly which stakeholder’s concern a given deliverable, built with a given template, is actually answering.
Why This Matters for CIOs, PMs, and EAs: The Deliverable-Stakeholder Mismatch
TOGAF’s practical technique, Stakeholder Management, is built directly on top of this formal model. TOGAF® describes the analysis step as follows: “Work out stakeholder power, influence, and interest, so as to focus the Enterprise Architecture engagement on the key individuals. These can be mapped onto a power/interest matrix, which also indicates the strategy to adopt for engaging with them.” It goes on to say: “Identify catalogs, matrices, and diagrams that the architecture engagement needs to produce and validate with each stakeholder group to deliver an effective architecture model” work · blog · article length.
The failure that recurs across so many SAP implementations is that this final “validation” step gets dropped. An EA spends weeks producing a beautifully detailed solution architecture diagram — only to discover it never addresses the CFO’s actual concern about statutory ledger compliance across countries. Meanwhile, the plant VP’s real question — how the process migration will avoid shutting down production — has no corresponding deliverable at all. TOGAF’s modeling approach forces a one-to-one explanation of which view answers which concern, and that traceability is exactly what a CIO needs to defend the program to a steering committee.
Putting This Into Practice in an Automotive Tier 1 SAP S/4HANA Rollout
Consider an automotive Tier 1 supplier with global production sites rolling out an integrated SAP S/4HANA template (FI/CO, MM, SD, PP). Here, the System-of-Interest is the “global SAP S/4HANA integrated template.” The stakeholders involved, their concerns, and the corresponding viewpoints and views can be mapped as follows:
| Stakeholder | Concern | Viewpoint | Actual View / Model |
|---|---|---|---|
| CFO | Statutory ledger compliance per country and consistency of the global chart of accounts | Chart-of-Accounts mapping viewpoint | Country-CoA-to-global-CoA mapping table (generated from SAP FI configuration data) |
| Plant VP | Migrating modular production and cost-engineering functions without disrupting operations | Business process flow viewpoint | As-Is/To-Be process flow diagrams (generated from a process model in a tool such as Signavio) |
| IT Director | Maintainability and upgrade ease across a multi-instance landscape | System landscape viewpoint | Instance configuration diagrams and integration architecture diagrams |
| Local Country Finance Lead | Fit between local statutory requirements and the global template | Fit-to-Standard gap-analysis viewpoint | Gap analysis tables and a localization requirements list |
As this table shows, the viewpoint has to change depending on the concern. Showing the CFO a process flow diagram doesn’t answer their concern about statutory ledger compliance. Conversely, handing the IT Director a chart-of-accounts mapping table doesn’t tell them anything about the maintainability question they actually care about. TOGAF’s model exists precisely to force explicit management of these correspondences.
Embedding This Into the Four Steps of Stakeholder Management
In practice, this modeling approach fits neatly into each of TOGAF’s four Stakeholder Management steps — identify, classify, determine approach, and tailor engagement deliverables. During Phase A (Architecture Vision), as stakeholders and concerns are being identified, the team should simultaneously decide which viewpoint and which view each concern will require. TOGAF® itself notes: “Stakeholder analysis should be used during Phase A (Architecture Vision) to identify the key players in the engagement, and also be updated throughout each phase” work · blog · target audience. This is not a one-time exercise confined to Phase A — it’s meant to be revisited continuously. In an SAP rollout, that means the Stakeholder-Concern-View mapping should be reviewed at every major milestone: requirements definition, Fit-to-Standard workshops, and the go/no-go review before go-live.
Four Actions for CIOs, PMs, and EAs
First, at project kickoff, the CIO should visualize the key stakeholders and their concerns on a single map and secure explicit executive buy-in on it. Second, at every project milestone, the PM should include a review item asking exactly which stakeholder’s concern is being addressed by which deliverable. Third, the EA should maintain a catalog of viewpoints in advance, so that when a new concern surfaces, the team can quickly judge whether an existing viewpoint applies or a new one needs to be defined. Fourth, all three roles should build a shared habit into every deliverable review meeting: always ask which concern a given view is actually addressing.
Summary
TOGAF’s Stakeholder-Concern-View modeling approach is not an abstract theoretical exercise — it’s a practical tool for preventing the deliverable-stakeholder mismatch that shows up constantly in SAP implementation projects. Identify the stakeholders with an interest in the System-of-Interest, surface their concerns, produce deliverables using the right viewpoint, and verify that each one genuinely addresses the concern it was meant to answer. Running this chain in tandem with the four steps of Stakeholder Management strengthens the CIO’s accountability to the executive team, the PM’s accountability for the project plan, and the EA’s accountability for architectural decisions.
Reference Links
- The Open Group, “Architecture Content — Introduction,” The TOGAF Standard: https://pubs.opengroup.org/togaf-standard/architecture-content/chap03.html
- Archimetric, “Navigating Complexity: Stakeholders, Viewpoints, and Views in Enterprise Architecture”: https://www.archimetric.com/navigating-complexity-stakeholders-viewpoints-and-views-in-enterprise-architecture/
- The Open Group, “Stakeholder Management,” The TOGAF Standard, Version 9.1: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap21.html
- The Open Group, “24. Stakeholder Management,” The TOGAF Standard, Version 9.1: https://pubs.opengroup.org/architecture/togaf91-doc/m/chap24.html
Disclaimer
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
Leave a Reply