It was Abraham Lincoln, the 16th American president, who is attributed with saying, “You can fool all the people some of the time, and some of the people all the time, but you cannot fool all the people all the time.” It seemed appropriate to adapt these rather cynical lines so that they might apply to the omniscient role of Enterprise Architecture when it attempts to somehow address and balance a diverse range of stakeholder views and viewpoints:
You can please some of the stakeholders some of the time, and some of the stakeholders all the time, but you cannot please all of the stakeholders all of the time.
TOGAF makes a big point of the need for good stakeholder management, devoting the whole of Chapter 24 to the subject, while Step 2 in Phase A: Architecture Vision describes the process to Identify Stakeholders, Concerns, and Business Requirements.
It is Impossible to Satisfy Each and Every Stakeholder
Most EA projects cover large swathes of the architecture landscape and often require sweeping, large-scale changes – so there are bound to be a lot of stakeholders and you can bet that their concerns and priorities are not the same.
Stakeholder pleasing becomes much more complex, because there will be many simultaneous projects, and this only increases the diversity of needs and the pressure to use scarce funding and resources. In just the last week I’ve worked with a company that is currently running just over 50 projects, and for some of my larger clients, for example in the banking world, this might go up to more than 150 concurrent projects (and because of the size of most global banks, this isn’t even a complete enterprise-wide picture).
So… we can’t please everyone all of the time! What can we do – either to please the optimum number or to do the right thing in difficult circumstances?
TOGAF provides some simple guidelines that are little more than common sense. It suggests that we make sure that we identify the powerful stakeholders early on, and use their input to shape the architecture, which ensures their support, helps the engagement win more resource, which in turn makes an architecture engagement more likely to succeed.
TOGAF also looks at how to improve communications with key stakeholders and how to tailor outputs and work products to show how changes are addressing their concerns. TOGAF shows how to do this by documenting concerns, and defining stakeholder views and viewpoints.
But there are some additional things that TOGAF doesn’t emphasize – so let me list a few key tips and reminders:
- Most stakeholders don’t speak EA, and even those comfortable with the concept of enterprise architecture struggle to understand architectural issues. So help them by being a translator. One of your key roles is to take stakeholder concerns and translate them into architectural requirements (which might be described in the Architecture Vision, the Statement of Architecture Work, or descriptions of the baseline and target architectures). When a business manager says that his customers can’t get the information they need, translate this into the constraints in the current architecture (account-centric systems, inconsistent data structures, redundant application functionality) and explain how the target architecture addresses these constraints (simpler process architectures, restructured customer-centric data, and an integrated application architecture).
- Find groups of stakeholders who are affected by the same fundamental architectural limitations, or who would benefit from the similar architectural improvements. This might sound obvious, but it gets overlooked so frequently. Account-centric systems don’t only affect the business manager with customers that can’t get the information they need! By finding everyone that is affected by this issue – often in different ways – there is a greater chance of building momentum to make it better.
- Stakeholders fight their own corner and remain resistant to collaboration for two reasons. (A) Resources are scarce and limited, so they don’t want to see them frittered away on things that don’t seem relevant, and (B) they don’t have enough information available to help them make collaborative decisions. The EA team can do something about both reasons. Firstly they can develop architectural proposals that create, build and grow business capabilities. Such proposals should be a continuous evolution, where one project creates architectural components that are the foundation for future options. But too often projects perpetuate diverse or redundant architectural components, and there is little thought given to the longer term options that each transition architecture provides. Secondly they can provide information that shows the bigger architectural picture, and that shows how each stakeholder can get what they need while also contributing to something larger. This is exactly what architecture is good at doing (or should be good at doing)! By translating stakeholder concerns to show the constituent architecture building blocks and their context (in the form of an Enterprise Pattern), the EA team demonstrate how they can please each stakeholder.
Lets go back to my opening quote: If we work with stakeholder concerns it is very difficult to please them all, and the reason is very simple – we haven’t demonstrated which parts of the architecture are preventing them from doing things, or we haven’t shown how a different architecture could resolve their problem.
By translating concerns into architecture constraints and options, we can show that it is a set of interrelated architectural components that are necessary to make everyone happy.
So let me close with another 19th century quote, generally attributed to the British social reformer Jeremy Bentham; by translating concerns to the constraints or options in our architectural specifications we can hope to please most stakeholders by delivering “the greatest good for the greatest number.”