Stakeholders, concerns, and viewpoints

Stakeholder management is not a workshop warm-up exercise. It is the step that prevents architecture from producing elegant material that answers the wrong question. TOGAF C220 Part 3 describes a specific stakeholder management technique that guides the architect through a structured process.

The technique works in a clear sequence:

1. Identify stakeholders. Determine who has an interest in, authority over, or exposure to the architecture effort and its outcomes. This goes beyond the obvious executives and includes regulators, operational staff, external partners, and end users.
2. Classify stakeholders. Group stakeholders by their role, power, and relationship to the architecture. TOGAF provides a set of categories (covered in section 9.3 below) that help ensure no important group is missed.
3. Identify stakeholder concerns. For each stakeholder or stakeholder group, determine the specific issues, risks, questions, or outcomes that matter to them. A concern must be specific enough to shape what the architecture shows.
4. Select viewpoints. Choose the architectural framing conventions that will address each set of concerns. A viewpoint is not a diagram template. It is a set of conventions that defines what a particular audience needs to see.
5. Produce views. Create the actual architecture representations using the selected viewpoints. Each view is tailored to address the concerns of a specific audience.
6. Maintain engagement. Stakeholder management is not a one-off activity. Concerns evolve as the architecture progresses, and new stakeholders may emerge. The architect must keep the stakeholder map current throughout the ADM cycle.

The technique matters because it connects every architecture output to a real audience with real questions. Without it, the team risks producing artefacts that are technically complete but practically useless because nobody asked for them and nobody knows how to use them.

TOGAF uses four terms that form a chain. Each one builds on the previous one, and collapsing them into a single concept is one of the fastest ways to produce weak architecture communication. Let us look at each term with its exact TOGAF definition and then explain what it means in everyday language.

Stakeholder.

Concern.

Viewpoint.

View.

The chain works like this: you identify the stakeholder, discover their concerns, select a viewpoint that addresses those concerns, and produce a view that the stakeholder can actually use. Skip any link in that chain and the architecture output will be weaker.

TOGAF provides a set of stakeholder categories to help architecture teams ensure they have not missed any important group. These categories are not mandatory labels. They are a checklist that helps the team think broadly about who matters. Here is the full set:

• Corporate functions (e.g. the board, CEO, CFO, COO). These stakeholders care about enterprise-wide direction, investment logic, and whether the architecture supports strategic goals.
• End-user organisation (the business units and departments that will use or be affected by the architecture outcomes). They care about how changes affect their daily operations, processes, and service delivery.
• Project organisation (programme managers, project managers, and delivery teams). They care about scope, timeline, dependencies, and whether the architecture gives them clear enough direction to deliver.
• Systems operations (IT operations, infrastructure, service management). They care about operability, resilience, monitoring, incident response, and whether new systems can be supported with existing capabilities.
• External stakeholders (regulators, standards bodies, partners, suppliers, customers). They care about compliance, interoperability, data quality, and contractual obligations.

In a regulated enterprise like London Grid Distribution, the external stakeholder category is unusually important. Ofgem, NESO, the Energy Networks Association, and end consumers all have distinct concerns that the architecture must address. Treating "external" as a single bloc would miss the differences between a regulator's compliance interest and a consumer's service-quality interest.

The difference between useful stakeholder analysis and decorative stakeholder analysis lies in the quality of the concerns captured. Generic labels like "cost," "risk," or "customer experience" are too broad to shape architecture output. They sound like concerns, but they do not tell the architecture team what to show, what to hide, or what decision the output must support.

Here is a practical method for getting from generic labels to real concerns:

• Ask what decision the stakeholder must make or influence. A CFO who says "cost" may actually need to decide whether to fund a platform replacement or extend the current system. That is a concern the architecture can address with a comparison view showing total cost of ownership under both options.
• Ask what failure they are most worried about. Not the workshop slogan, but the specific failure that keeps them up at night. An operations director who says "risk" may actually be worried about whether a specific system outage could cascade into a broader service failure.
• Ask what evidence would make them trust the architecture pack. A regulator who says "compliance" may need to see an evidence trail showing that data-publication obligations are met, with clear accountability for each obligation.
• Ask what they would challenge if the architecture proceeded without answering their concern. This reveals which concerns are truly decision-critical versus which are nice-to-have.

The test for a well-captured concern is simple: can an architect use it to decide what to include in a view and what to leave out? If the answer is yes, the concern is specific enough. If the answer is "it depends," the concern needs more work.

Different audiences need different things from architecture, even when they are discussing the same initiative. Understanding why is essential for producing architecture that actually changes decisions.

Executive audiences need decision implications, accountabilities, investment logic, and the shape of change. They do not need interface specifications. An executive view should answer questions like: "Where should we invest? What are we choosing not to do? What are the consequences of that choice?"

Operational audiences need service impact, workflow consequence, resilience, and what changes in day-to-day control. They do not need strategy narratives. An operational view should answer: "How does this change affect my team's daily work? What new skills or processes do we need? What happens if this system goes down?"

Regulatory and assurance audiences need evidence trails, obligations, controls, and where accountability sits. They do not need technology stack details. A regulatory view should answer: "Can you demonstrate that this obligation is met? Who is accountable? Where is the evidence?"

Technical and integration audiences need data boundaries, interfaces, dependencies, and building block choices. They do not need business-case justification. A technical view should answer: "What data flows between these systems? What are the interface contracts? What dependencies must be resolved before we can build?"

When a team produces one master diagram and calls it "the architecture," it usually reveals that viewpoint selection did not happen. The artefact may be impressive as a poster, but it is unlikely to improve any specific decision for any specific audience.

The London Grid Distribution case provides an excellent opportunity to see stakeholder management in practice. From Module 8 you know the enterprise boundary includes internal functions, regulated interfaces, and external partners. Now we need to identify the specific stakeholders within that boundary and understand their distinct concerns.

Ofgem (the energy regulator). Ofgem sits outside London Grid's org chart but inside the effective enterprise boundary. Its concerns are specific and consequential: are performance standards being met? Is published data accurate and timely? Are consumer interests protected? Can the distributor demonstrate compliance with licence conditions? The architecture must produce views that show evidence trails, obligation coverage, and accountability chains. A technology stack diagram would be useless for Ofgem.

NESO (National Energy System Operator). NESO coordinates national energy planning and balancing. Its concerns centre on data exchange: does London Grid publish accurate planning data in the right format and at the right time? Are interface specifications followed? Can NESO trust the data it receives? The architecture must address interoperability and data-quality concerns through views that show data flows, format compliance, and update frequencies.

The executive team (CEO, CFO, COO). The executive team cares about investment decisions, risk exposure, regulatory standing, and whether the transformation programme is on track. Their concerns are: is the investment justified? What are we choosing not to do? What happens if we do nothing? The architecture must produce executive-level views that show strategic direction, investment logic, and risk implications without technical detail.

Operations leadership. Operations manages the live electricity network. Its concerns are about service continuity: will this change affect network reliability? What happens during the transition? How do we maintain service while systems change? Do we have the skills and processes to operate the new systems? The architecture needs operational views showing service impact, transition risks, and operability requirements.

Network engineers and planners. These are the specialists who design and maintain the physical network. Their concerns are technical and specific: how do changes to data systems affect network modelling? Will new systems integrate with existing SCADA and DMS systems? What data do we need to do our jobs? The architecture needs detailed technical views showing data flows, system interfaces, and integration dependencies.

Cyber and telecoms teams. These teams manage security across OT, IT, and telecoms estates. Their concerns are about trust boundaries: where are the security perimeters? How do new systems affect the attack surface? What evidence do we need for OT security assurance? The architecture needs security views showing trust boundaries, network segmentation, and resilience evidence.

Consumers and connection applicants. End users care about service quality: how long will it take to get a connection? Is published information accurate and accessible? Will service improve? The architecture must consider the customer journey even though individual customers are not in the room during architecture reviews.

Developers and third-party data users. External developers and businesses that use London Grid's published data care about accessibility, format consistency, and reliability. Their concern is simple: can I trust and use the data you publish?

Notice how different these concerns are. A single master diagram could not possibly address Ofgem's compliance evidence needs, the CTO's investment logic, and a network engineer's integration requirements at the same time. That is exactly why the stakeholder-concern-viewpoint-view chain exists.