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
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.
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?
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).