Pages

Thursday, 13 June 2013

So what is Enterprise Architecture and why do most EA interventions fail?

The phrase 'Enterprise Architecture' brings up quite a few images in the business world. Some of them are positive, yet unfortunately, most of them are negative. A primary reason that MOST Enterprise Architecture interventions fail is because IT has tended to equate Enterprise Architecture with Technology Architecture (InformationWeek.com article March 26 2013). This is a major failing since Enterprise Architecture is actually a superset of a Technology Architecture, in other words, an Enterprise Architecture encapsulates a Technology Architecture.

Enterprise Architecture was born in 1987 as a means to help develop discipline in resolving increasingly challenging information technology (IT) issues. It encouraged a holistic approach to IT projects way beyond the mere nuts and bolts of technology identification, selection, installation and configuration. My previous article, "So what is Business Intelligence actually? Why do 80% of corporate BI projects fail?", and the fact that Gartner found that most Business Intelligence projects fail because they are seen only as technology implementations, demonstrated the importance of but one non-IT perspective within the Enterprise Architecture domain in the overall planning of a Business Intelligence programme. Today, as per the opening paragraph, Enterprise Architecture is seen more as a technology discipline, notwithstanding that a major part of the job of the enterprise architect is to translate the strategy of the organisation into various components, many of which are IT, but which also consider attributes including people and process.

As an aside, many corporations have embarked on massive but risky (from a continuity perspective) operating model projects over the last decade, mainly in an attempt to reduce operating costs and redundancy. While some of these have had a basis in Enterprise Architecture, amazingly, in spite of the considerable risk, many haven't. Interestingly, as a result of the integrated approach of an Enterprise Architecture, I also see how it can be a fundamental input into Enterprise Risk Management (aka Operations Risk Management) in that a host of factors are considered in concert in order to ensure a reasonable implementation of what could be quite a complex plan, as well as understanding the dependencies of various components on others, and thus where the operation's vulnerabilities are.

In an article published in Information Management of Jan 18 2013 on the worst Enterprise Architecture practices:

  • On the top of the list, as implausible as it seems, is failing to link the 'Enterprise Architecture', the overall Strategy of the organisation, as well as to the Budget of the organisation. Again, Enterprise Architecture is not Technology Architecture (which is incidentally second on the list), and ALL aspects of the business milieu actually make up a proper Enterprise Architecture. Whether referencing the newest TOGAF or the Zachman's taxonomy that started it all, note the critical role of Business Architecture. It's there, at the front, and at the top!
  • Items 5, 6 and 7 on the list are also very interesting, being Focusing on the language of Enterprise Architecture rather than the outcomes, Strictly adhering to the frameworks, and An ivory tower approach by IT respectively. It is a fruitless and frustrating effort to try and cram every business precisely into a chosen framework. This is because every business is different in an uncountable variety of ways. No matter how you try, there are square pegs that just won't go into round holes. A truly sustainably successful Enterprise Architect will have the corporate and political savvy to mould a framework around the requirements of the business, not to try and cram the business into a mould. The truly successful enterprise architect will focus on the outcomes of the Enterprise Architecture, which is essentially to ensure that the strategy of the business is translated and eventually represented as a set of IT change initiatives in the application, data and infrastructure layers, thereby ensuring that the strategy of the organisation will be justly enabled. Anything less is just IT posturing, and doesn't serve the interests of the business in the least.
  • Item 10 on the list is Missing performance measures. In many interventions, the performance measures of the Enterprise Architecture project, if there are any, pretty much relate to progress along a project plan. While that information may be useful to the project manager, it is not particularly useful to the business. Speaking from the perspective of the CEO and even of the Board, what's more important is which stages of the project have resulted in aspects of the organisational strategy being fulfilled, and where relevant, what the changes in revenue, cost and risk have been as a result of this fulfillment, which in turn, depend on things such as staff training, process throughput, asset productivity ... hmmm, I'm talking non-IT matters again...


In a sense, this article could just as easily have been entitled, 'Putting the Enterprise back in Enterprise Architecture', because it's a lack of focus on the ENTIRE enterprise that is clearly putting the practice of Enterprise Architecture in a bad light. If you represent one of those organisations that has a sustainably successful Enterprise Architecture practice, take note that most research houses and large vendors would be very interested in your story, whether it be Forrester, Gartner or IBM for that matter. Perhaps you should think of bringing your story to see the light of day, if only to encourage the rest of us and to show us how it's done!

No comments:

Post a Comment