Enterprise Architecture – Will Yours Fail?


Source – B. Shaw, Principal, BRS-Management.com - 2010


More than 66% of Enterprise Architecture initiatives fail.  And that’s a conservative estimate based on a Rotterdam University survey in back in 2008 1.  Before that in 2007, the Gartner Group predicted 40% of all EA programs would be terminated by 2010 because of failure 2. Well, here we are past 2010 and success rates are not much better.  Have we learned nothing in this time?  Will your EA initiative be among the unlucky two-in-three that flounders?


The last several years have seen a wealth of discussion, expert opinion, and blogging contributions on the subject; much of it valuable stuff.  Here’s a summary of analysis and opinions on why many EA initiatives fail.


Unrealistic Expectations – Most EA projects have some kind of triggering event, such as a troubled integration project or chronic problems implementing IT changes. There is an expectation, partly due to the hype about EA, that putting an EA framework in place will solve these problems.  But EA success is only as good as the organization’s existing capabilities. EA frameworks only organize what is already there.  It takes collective expertise to work with existing material, fill in what’s missing, and fashion it into a tactical vision and plan.  It’s like having a house architecture framework of the basement, main, and second floor levels, with a series of separate room plans for the whole house.  If there is no skilled architect to organize the rooms into strategic floor plans, the architecture is useless.


Emphasis on Technology Instead of Business – According to EA surveys, the top three drivers for implementing EA are better strategic planning, improved business agility, and improved business-IT alignment 3.  These are Business related imperatives, yet most EA implementations focus mostly on technology and application consolidation.  Most, if not all, of the architecting is done by technical architects.  The business people typically issue a strategy and then disengage from the development to wait for a completed architecture to address their business drivers.  As a result, business artifacts often fail to represent the business perspective or even communicate meaningfully to business area users of the Enterprise Architecture. 


Poor Organization Support – To many employees, an Enterprise Architecture is just a fancy name for a new place to find corporate documentation. It does not provide them with any perceivable benefits in their day to day work.  In some cases, it may add some extra effort to support new standards or business rules. EA artifacts have strategic and tactical value; they are not used in projects per se. Therefore, those not involved in the EA program development or its use in planning and managing corporate change will always question its value.  The kind of corporate-wide communication and EA education programs that are required to overcome resistance and achieve enterprise buy-in are often neglected.


So now that we are armed with this knowledge, why are EA projects still failing?  Well, as they say, ‘it’s complicated’.  Here are a few additional factors.


Firstly, EA implementation is a collaborative effort.  It involves a lot of people from different areas and with different levels of expertise.  To make it work, there has to be a belief in the motives and a common understanding of the goals and benefits. This has to be communicated and directed from the top as part of the communication program mentioned above for the whole enterprise, but with specific emphasis for the initiative’s participants. Also, the intended user community, which is typically as diverse as the contributor group, has to be well defined. If the whole collaborative effort is left managed loosely, participants will either grudgingly contribute, or will develop their own perceived goals and benefits and work toward them instead. Too often, artifacts are developed to be meaningful and beneficial to the originator, not the EA user community. 


Secondly, EA implementation is work and work costs money. Simply adding EA tasks on top of a resource’s existing workload, no matter how convincing the rallying argument is, is not going to result in dedicated work. The EA development has to be set up and managed as an ongoing project, with resources identified and committed with funding.  Trying to engage subject matter experts and other resources without allocating blocks of funded effort is only going to frustrate the analysts and architects who depend on their time to develop accurate and complete artifacts. As for business and executive resources, they must be included in the plan and must be committed to the required effort involved in expressing and communicating business strategies and objectives.  Simply sitting in the captain’s chair and commanding ‘make it so’ will not result in an effective Enterprise Architecture.


And thirdly, the EA implementation has to be viewed as a continuous commitment.  There is no real project end and consequently no real point to calculate ROI.  It is an evolution, best to start small and simple and develop detail and complexity over time, as adoption among the user community matures.  Many organizations establish artifact detail level standards and framework completeness targets that exceed EA users’ needs and result in long implementation times. Many do not get past the Current State or Baseline Architecture.


In summary, there are many things that influence the success of an Enterprise Architecture initiative.  The potential for success or failure is largely a reflection of the organization’s existing culture, politics, and cohesion. Looking at other’s performance is not always a good indicator on how your initiative will turn out. But by all indications, be clear, be reasonable, and start small are good starting points.




1 Jonathan Broer for Rotterdam University, commissioned by IDS Scheer , summer 2008

2 J-D Muller, Market-Visio Oy, October 2008

3 Aris Expert Paper, ‘Why Two Thirds of EA Projects Fail’, June 2009