Enterprise Architecture often tries to address and balance different stakeholder viewpoints. But that doesn't work often. Why? Let's paraphrase Abraham Lincoln:
"You can
please all of the stakeholders some of the time, and some of the stakeholders all the time, but you cannot please all the stakeholders all of the time."
These cynical lines can be easily applied to the all-mighty role of enterprise architecture when it tries to somehow balance a wide range of stakeholder views.
Enterprise Architecture using TOGAF emphasizes the need for proper stakeholder management, devoting the entire Chapter 24 to the subject, as well as step 2 in phase A: in which Architecture Vision is used to describe the process for identifying stakeholders, concerns, and business requirements.
It is almost impossible to keep all stakeholders satisfied The majority of EA Projects involve large architectural landscapes and require large-scale changes - which means there will be a lot of stakeholders, and you can be sure that their worries and priorities are not the same. With many simultaneous projects, pressure to use scarce resources and the diversity of needs that follows, pleasing the stakeholders becomes increasingly more challenging.
We cannot keep everyone pleased all of the time. So, what can we do?
TOGAF Enterprise Architecture provides simple guidelines that little above common sense. It suggests identifying the influential stakeholders at the beginning of the project and using their input to adapt the architecture, which guarantees their support, allows the use of more resources and generally raises the chances for architecture to succeed. TOGAF likewise advises how to improve communication with powerful stakeholders and how to show changes that are addressing their concerns. TOGAF explains how to document concerns and define stakeholder viewpoints. But there are some things TOGAF does not emphasize:
- The majority of stakeholders does not understand EA or architectural issues. Help them by being a translator. One of the key roles of the enterprise architect is to translate stakeholder's concerns into architectural requirements.
- Find groups of stakeholders who would benefit from the similar architecture changes, or who are affected by the same architecture limitations. This probably sound obvious, but many architects tend to overlook this one. By finding stakeholders that are affected by the same issue (often in different ways), your chances are rising, and you should build momentum and make things better.
- Stakeholders are resistant to cooperation for two main reasons:
1. Resources are limited, so they don't want to see them spent on things that don't seem relevant.
2. They lack information to make such decision.
The enterprise architect can do something in both cases. First, it can develop an architecture to build business capabilities. This proposal should be a continuous change, where just one project creates an architectural foundation for future options. Second, it can provide a wider architectural picture, which shows how each of the stakeholders benefits from the transformation.
ConclusionBefore saying we cannot please all of the stakeholders, we should demonstrate an architecture that could address their concerns. By using TOGAF guidelines and translating concerns into architectural solutions, we can show that a set of architectural components can bring us closer to making everyone happy.
keywords: Enterprise Architecture, TOGAF, TOGAF Stakeholders, Enterprise Architecture TOGAF
