TOGAF Stakeholders - Views, Concerns, and Requirements

The TOGAF standard takes a formal modeling approach to understand stakeholder, concern, and view; this has led some to interpret that all representations of architecture are views prepared for any conceivable interest.

How to identify stakeholders, views, and concerns?

Stakeholders, views, and concerns are often explained in terms of a single architecture. For a large organization, we often need to consider also what an EA Landscape will actually contain:

• Multiple discrete architectures.
• Separated by purpose, detail, breadth, time, and recency

There are architecture states:

• Current
• Transition(s), and
• Target

An architect’s first obligation is ensuring the architecture addresses the preferences of the Enterprise. When the Practitioner preserves the stakeholder’s concern, the view to communicate with the stakeholder, and how the architecture will address their concern, something useful to govern against in addressing this obligation naturally emerges.

From a practical perspective, consider:

• Stakeholder: someone who has approval rights in the Target Architecture being explored by the current Architecture Project, and subsequently has decision rights to the suitability of the implementation
• Concern: a consistent set of subjects that capture the stakeholder’s interests and activities to consolidate requirements
• View: a representation of the EA Landscape that addresses a set of stakeholder’s concerns; either describe how the architecture addresses the concerns or demonstrate how the associated requirements are met

Determine stakeholders’ influence and interest

This process enables the team to easily see which stakeholders are expected to be blockers or critics, and which stakeholders are likely to be advocates and supporters of the initiative.

Work out stakeholder power 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 you need to adopt for engaging with them.

Stakeholders may be mapped out on a Power/Interest Grid and classified by their power and interest. There are other tools to map out stakeholders and how to influence them. For example, your boss is likely to have high power and influence over your projects and high interest. Your family may have high interest, but are unlikely to have power over it.

Position on the grid may show actions:

• High power / interested people: these are the people you must fully engage and make the greatest efforts to satisfy.
• High power / less interested people: put enough work in with these people to keep them satisfied, but not so much that they become bored with your message.
• Low power / interested people: keep these people adequately informed, and talk to them to ensure that no major issues are arising. These people can often be very helpful with the detail of your project.
• Low power / less interested people: again, monitor these people, but do not bore them with excessive communication.

Statement engagement strategy

Stakeholder management within businesses, organizations, or projects prepares a strategy using information (or intelligence) gathered during the following common processes. With a clear understanding of your Stakeholders, engaging and communicating can be achieved through a variety of channels based upon who the stakeholder is.

• High power, interested people: Manage closely. Best channels: Issue, Change Logs, Status Meetings
• High power, less interested people: Keep satisfied. Best channels: Steering Committee, Board Meeting Updates
• Low power, interested people: Keep informed. Best channels: In-Person, Video, Email Updates
• Low power, less interested people: Monitor. Best channels: Send Email, Status Reports

Mapping stakeholders with concerns and views

You can identify the stakeholder influences and interests with the power/interest matrix analysis above, then transcribes the findings to the table for further mapping of the concerns and requirements incrementally; or alternatively, you may go straight to the stakeholder map as provided below:

	Concern 1			Concern 2
	Power	Interest	Requirement	Power	Interest	Requirement
Stakeholder 1	High	Low		Low	High
Stakeholder 2	High	High		Low	Low
Stakeholder 3	Low	High		High	Low

The template above provides an extended TOGAF power/interest matrix analysis above by including concern and requirement. Missing requirements within a concern can either be a gap in information gathering or a demonstration the stakeholder is saying “this does not matter”. Knowing requirement or lack of preference in relation to power and interest directly facilitates trade-off. The trade-off is performed within a concern and between the concerns.

For simple EA projects, the traditional power/interest matrix stakeholder analysis may be sufficient, a large project resulting in multiple architectures this stakeholder map might be more appropriate.

Summary

Practitioners need to communicate with three broad communities: stakeholders, decision-makers, and implementers. Each of these communities uses architecture differently. Stakeholders are presented with views that address their concerns. This enables stakeholders to understand the architecture, engage in trade-off decisions, and finally approve the Target Architecture.