Architectural transformations are very complex, and it is no wonder that as many as 90% of Enterprise Architecture. transformations fail. From my experience, these Enterprise Architecture transformations fail due to various many-faceted factors, but usually, the root cause is a failure to entrench the culture of transformation within the organization.
What do I mean? I’m saying that how the effort is viewed at the start has everything to do with its success or failure. If it is viewed as a one-off project staffed principally by consultants, giving thick documentation as deliverable, and that the effort is not supported at the board level, we could almost predict failure, however well-run it is. In other words, if it is not a living, breathing culture within an organization, there is almost no hope for E.A. success.
Let’s examine some of these in detail. At the minimum, E.A. transformations need the following for its taking root as a cultural transformation within an organization:
A. Moving beyond the project mentality
B. Continuity after the consultants leave
C. Buy-in at board level
A.Moving beyond the project mentality:
Some years ago, I met a client and he said to me that he didn’t require our services because “I’ve already done E.A. two years ago, so I already have it.” In his mind, E.A. was a project with a defined start and end date. And when it was over, when the consultants leave, they ‘have’ E.A. in the organization.
There are at least two major problems with this view: Firstly, we are living in times where industries are being totally transformed, and I can bet that in 2 years, business fundamentals would have changed enough that necessitate a re-look at the enterprise architecture. Secondly, it takes at least two years for the first efforts of E.A. to bear fruit. Since it usually isn’t possible to fix everything at once, lots of the implementation must go in phases.
In fact, in the IT Body of Knowledge (ITABOK), Enterprise Architecture expressedly deals with the concept of transition. Each E.A. phase or deliverable is viewed as just one of many transitions. So you have transition 1, 2, and so on.
Does this mean you’d always be fixing your architecture? Such a view happens because E.A. is viewed as discrete projects. If you view it as part of the culture, like kaizen, then all these would just be business-as-usual.
B.Continuity after the consultants leave:
Once E.A. is viewed as a culture of transformation, the organization’s relationship to its consultants would change. Consultants would be a catalyst and a check point, and the serious results are gotten after the consultants leave.
The reality is that most E.A. transformations are implemented by consultants. There’s nothing wrong with this, since most organizations lack the in-house expertise or momentum to start. However, it is also tragic that if we analyze E.A. failures, most of the failures occur right after the consultants leave.
Quite simply, the client organization doesn’t know what next to do. Why is this so? There are at least two reasons, and they are inter-related.
One: Nobody prepared the organization for the ongoing effort E.A. transformation entails
This goes back to the previous point of organizations treating E.A. transformations as projects. And if we be honest, the image of an ‘architectural’ transformation suggests changing the blueprints, plans, and wiring – and in the IT context it usually means the hardware, software, and IT processes. Very few organizations would think of E.A. as a systematic way of building business capabilities through technology. And so, when the consultants leave, naturally the organization would think they now have a new set of blueprints, the place have been re-wired, the software upgraded, and we’re ready to go! If only it was like that.
Two: Client-Agency conflict of interests
Another less discussed dynamic is the client-agency conflict of interests inherent in the consulting arrangement.
If the consultants were to train the client to do ongoing E.A. transformations, it is certain that at some point, the organization would outgrow the need for these consultants, and it would negatively impact consulting revenue.
For this reason, you seldom if ever, see consultants offering training programs, or on-the-job coaching solutions. No one wants to kill the goose that lay the golden eggs.
The reality is that without a 100% download of skills, knowledge, and processes from consultants to the client organization, E.A. initiatives are bound to fail. Client and consultant must together create the conditions by which the internal organizational resources are able to power the E.A. transformation naively.
But honestly, how many consultants are willing to do that?
C.Buy-in at board level:
In an E.A. transformation initiative, we are aiming at building of new business capabilities through leveraging technology. Done right, this is nothing less than a re-envisioning of the organizations’ business fundamentals.
From my experience, even the total support of the CEO isn’t enough. You need board level buy-in for the transformation to succeed. If an organization is attempting to re-wire itself and how it does business, at some point these initiatives would have to be put up to the board for approval and for budget. Even the CEO would find EA transformations tough with an unsympathetic board.
Another reason is that CEOs must make the numbers, and E.A. transformations sometime take longer than a few quarters to make its presence felt on the bottomline. These would be the times an enthusiastic board would keep the CEO in check if ever the CEO is tempted to give up the transformation for “lower hanging fruit.”
If you don’t have board level buy-in, you can still start small with a proof-of-concept. But once you get to the enterprise scale, figure your approach to get board level buy-in before seriously starting.
About the Author: Aaron Tan Dani is a thought-leader in Digital EA and he is also actively driving Digital EA adoption and currently he is the Chairman of EA-SIG, Singapore Computer Society email@example.com, Chairman of Iasa Asia Pacific firstname.lastname@example.org and Chief Architect of ATD Solution email@example.com