Achieving Successful Enterprise Architecture
How to achieve Successful Enterprise Architecture Transformation?
by Aaron Tan Dani
Architectural transformations are very complex, and it is no wonder that as many as 90% of E.A. transformations fail. From my experience, these failures are due to various multi-faceted factors, but usually the root cause is the failure to entrench the culture of transformation within the organization.
How the transformation initiative is viewed from the very beginning will determine 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, it is almost certain to fail. In other words, if transformation is not a living, breathing culture within an organization, there is almost no hope for any E.A. success.
At the minimum, E.A. transformations need the following for it to take root within an organization:
A. Moving beyond project mentality
B. Continuity after the consultants leave
C. Buy-in at the board level
- Moving beyond project mentality
Some years ago, I met a client and he said he didn’t require our services because “I’ve already did 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.
There are at least two major problems with this view. Firstly, we are living in times where industries are continually being disrupted and within just a span of around two years, business fundamentals would have changed enough and hence a re-look at the enterprise architecture would be a necessity. Secondly, it takes at least two years for the first E.A. efforts to bear fruit. Since it usually isn’t possible to fix everything at once, much of the implementation must happen in phases.
In fact, as per the TOGAF iteration concept, Enterprise Architecture expressly deals with the concept of transition. Each E.A. phase or deliverable is viewed as just one of many transitions. Does this mean you’ll be perpetually fixing your architecture? Only if you perceive E.A. as discrete projects. But if you view it as part of your corporate culture, it’s part of business as usual.
- Continuity after the consultants leave
Once E.A. is viewed as part of corporate culture, the organization’s relationship to its consultants would naturally change. Consultants would be a catalyst and a check point, and the serious results will be achieved only after the consultants leave.
It is true that most E.A. transformations are implemented by consultants. There’s nothing wrong with that, since most organizations lack the in-house expertise to do this at the beginning. However, it is most unfortunate that, according to our analysis, most E.A. failures happen 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.
Firstly, nobody prepared the organization for what ongoing effort E.A. transformation would entail. This goes back to the previous point of organizations treating E.A. transformations as projects. A typical image of architectural transformation suggests a change in the blueprints, plans and wiring. In the IT context it usually means a change in the hardware, software and IT processes. And so, when the consultants leave, many organization would think since they now have a new set of blueprints and the system has been re-wired, with the software already upgraded, they’re all set to go. If only it were that simple and static organization.
Secondly, the seldom discussed dynamic of client-agency conflicts of interest inherent in the consulting arrangement. If the consultants were to train the client to do ongoing E.A. transformations well, it is certain that at some point, the organization would outgrow the need for these consultants. For this reason, you seldom see consultants offering training programs or on-the-job coaching solutions. They don’t want to kill the goose that lay the golden eggs.
The reality is that without a 100% transfer of skills, knowledge and processes from consultants, these 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 natively. But how many consultants are willing to do that?
- Buy-in at board level
From my experience, even the total support of the CEO isn’t enough. You need board level buy-in for the digital 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 to secure the budget. Any CEO would find E.A. transformations tough if he has an unsympathetic board. On the other hand, sometimes you have the CEO wavering. E.A. transformations that takes longer than a few quarters to make its presence felt on the bottom-line. These would be the times when the board must have the CEO in check in case he were to give up on transformation in order to chase “lower hanging fruit” that can impact the bottom-line much quicker.
As an enterprise, it is crucial to secure board level buy-in before seriously starting anything. In an E.A. transformation initiative, you are looking at building new business capabilities by leveraging on technology. Done right, this is nothing less than a re-imagination of the organizations’ business fundamentals. Such things never come easy.
Aaron Tan Dani, President of EA-Chapter, SCS [email protected]
Visit our website https://www.scs.org.sg/Chapter/ea-homepage.php and join our activities as part of the EA-Chapter to learn how you can implement Digital-Business-driven EA in your organisation.
Aaron Tan Dani, Founder and Chairman of Iasa Asia Pacific [email protected]
Visit our website http://www.iasahome.org to learn more about ITABoK (IT Architecture Body of Knowledge) skillsets and about the roles, scopes and impacts of EA Specializations (Business Architecture, Information Architecture, Software Architecture, Infrastructure Architecture and Solution Architecture).
