How to have a Successful Enterprise Architecture Transformation
 /  Article / How to have a Successful Enterprise Architecture Transformation
How to have a Successful Enterprise Architecture Transformation

How to have a Successful Enterprise Architecture Transformation

By Aaron Tan Dani
Chief Architect, ATD Solution

Architectural transformations are very complex, and it is no wonder that as many as 90% of E.A. transformations fail. From my experience, these E.A. 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.

You might also be interested in …

Aaron Tan Dani
Aaron Tan Dani

<p><em>Chief Architect at ATD Solution | Founder and the Chairman of IASA Asia Pacific</em><br /> <em> Chairman of Enterprise Architecture SIG at Singapore Computer Society</em></p> <p>Aaron Tan has a strong passion on Enterprise Architecture and Business IT related fields. He strongly believe in Digital Transformation through Enterprise Architecture. He is also Chief Architect leading governments on Asia Pacific region towards Digital Transformation. Take a look on full <a href="http://atdsolution.com/enterprise-architecture/profile/mr-aaron-tan-dani/" target="_blank">profile of Aaron Tan Dani</a></p>

Related Posts

Digital Enterprise Architecture Seminar 2017
Upcoming Events
Digital Enterprise Architecture Seminar 2017

The Digital Enterprise Architecture Seminar 2017, is co-organized by IASA Chapter – An Association for all IT Architects and Singapore Computer Society (Enterprise Architecture SIG). It brings together local partners and communities, international and local industry leaders and practitioners to share on the best practices and skillsets that are required for the success in the new digital companies.

How To Reduce Technical Debt By Tapping The Enterprise Architecture
Article
How To Reduce Technical Debt By Tapping The Enterprise Architecture

Find out how to reduce technical debt by mapping business and user requirements in an enterprise architecture. The results will cut the costs of finding and fixing software defects in production software. Often, DevOps organizations neglect the critical connection between technical debt and enterprise architecture. Without the information that resides in EA

The Enterprise Architect As Product Leader
Article
The Enterprise Architect As Product Leader

As an attendee and speaker at this week’s Enterprise Architecture Summit in Orlando, I had the pleasure of meeting with and listening to numerous current and future enterprise architects (EAs). Normally, I’m not so fortunate; my “day job” is to be an analyst within our Tech Go To Market (GTM) practice, serving technology and service providers (TSPs) and helping them communicate effectively with buyers

Related Certification

Other Recources

ATD Solutions

Architecting Digital Transformation


Read More

Newsletter

Keep updated with our latest news, promotions, events and more.