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.
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:
There are architecture states:
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:
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:
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.
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.
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.