Enterprise Architecture (EA) implicitly involves IT governance. When the goal is to implement an organization-wide approach, then a level of control over the investment decisions of the organization has to take place. After all, unless the Enterprise Architecture effort can exert control over the investment decision made in an organization, then how is that Enterprise Architecture effort going to be able to change anything. Further, unless it can change anything, how is it going to avoid being simply an expensive and largely futile documentation exercise for the current state? Exerting influence on decisions implies affecting them somewhat, and so governance of IT investment decisions and effective Enterprise Architecture cannot be disentangled.
Given that this is the case, it’s worth considering what this means for the success of an EA effort. Governance must necessarily involve overriding or changing decisions on specific projects from time to time. Unless, of course, the entire governance effort is simply a rubber stamp façade that is only designed to give the appearance of control.
I feel like I’ve made my point. With all of the above stated (and I would hope that what I’ve written seems to be more or less stating the obvious for more readers), I’m going to say that one of the classic ways that I’ve seen to mess up any EA program, small or large, is to neglect the question of IT investment governance. Specifically, how do you plan to implement any changes to the governance mechanisms that exist?
There are several different aspects of this question, and neglecting any of them is a good way to cause a failure in your Enterprise Architecture rollout. Today we’ll talk about stakeholder management and the groups of stakeholders, and why this is a problem.
There are plenty of stakeholders for Enterprise Architecture, and TOGAF (along with other resources) has a pretty decent chapter on the subject. But the governance aspect of EA has some specific stakeholders and concerns. Let’s examine what they are, and the steps necessary to mollify them.
First of these groups of stakeholders is, perhaps unsurprisingly, the IT project managers. Now, it’s the nature of IT project managers that they will tend to be opposed to any extra governance in so far as governance restricts their ability to execute their specific projects. This means that buy in will only come from an understanding from their executives that governance necessarily means restrictions. A roadshow to the executives concerned is going to be necessary in order to mitigate this as an issue, and to obtain their backing the governance an EA initiative requires.
The second key stakeholder group to consider is the IT governance personnel themselves. They are going to be concerned with how EA can ‘gum up the works’ of the review cycle - in other words, by introducing disputes into the review process with disputable review criteria. To address their concerns, the EA team will need to be able to demonstrate the clarity and enforceability of EA principles and procedures in a roadshow to these stakeholders.
Both groups of stakeholders have the ability to derail any EA initiative, and neglecting to get the buy-in from these groups is an easy way to set up any initiative for failure. Once you've engaged your stakeholders, you'll have their support.