The Business Value of (Effective) Architecture

If your company has an annual capital budget of $100M for various project initiatives, then an effective Enterprise Architecture capability will generate $72.7M in additional annual business benefits in comparison to the normal (average) chaotic planning process that a typical organization realizes. Now that I have your attention, hear me out. There is some solid empirical data and rational financial model that support these numbers. Let me start this first of a 2-part blog series with some background data on one of the key challenges than an effective architecture capability can address.

Experienced IT professionals (anyone with grey hair or no hair) knows that the industry has a dismal project success rate.  The CHAOS survey which the Standish Group has been conducting periodically for about 15 years put’s it into perspective. In the most recent survey of global projects the success rate (on time, on budget and meeting specifications) is only 39%.  Failed projects that never finish account for 18%. Challenged projects (late, over budget, missing key features, or some combination of these) account for 43%. The statistics for large projects over $10M are even worse with only 10% success and a staggering 38% failures!


So what is going on?  Is everyone in IT idiots or is there something fundamentally wrong with the approach?  The CHAOS survey once again provides insights into the root causes which once again won’t surprise anyone with grey hair.  The top five reasons account for 60.6% of the root causes and are all factors that are directly impacted by an effective EA planning process:

  1. User Involvement 15.9%
  2. Executive Management Support 13.9%
  3. Clear Statement of Requirements 13.0%
  4. Proper Planning 9.6%
  5. Realistic Expectations 8.2%

Let me say this again. An effective EA capability addresses all of these factors by effectively involving the appropriate stakeholders that are impacted by changes in operational capabilities, by driving support and alignment of senior management, by clearly linking requirements to business strategies, by identifying all impacted operations and planning changes from a business perspective, and setting realistic expectations based on a holistic understand of the total transformation.

The knee-jerk reaction by many organizations when they come to realize that small projects have a better success rate than large projects is to simply not do large projects. While this does indeed help, there are simply some initiatives that can’t be broken up into small incremental efforts; you really do need a large project if you are doing a major organizational transformation like an acquisition, out-sourcing or in-sourcing a major area of the business, or rationalization of a portfolio of hundreds of applications.

But an effective EA program, like the BOST™ approach from Informatica’s Business Transformation Services team which has been around for over two decades, means that you don’t need to avoid large programs.  You can use Agile methods when it makes sense for incremental/iterative development and you can conduct large-scale enterprise transformations when those are justified.

Stay tuned for part 2 of this blog where I explain the financial model that concludes that the value of an EA program is $72M for an organization that has an annual capital budget of $100M.


  • Keith Goosen

    We referenced this in 95/96 (Amdahl Corp ca.) to illustrate the failure rate (professional services), particularly with Software projects. The ‘dollar drain’, – in the event of a comparison, seek the construction industry, normally there would be an investigation sought as to ascertain – Why did the bridge collapse(?), of course the build specification(s) do not change midstream. Essentially, the difference is with software projects, it gets swept under the carpet. Even more money gets thrown at the failed project, to protect the ego’s and the worst nightmare ever imagined, it gets restarted with the same requirements definition that was originally identified to have been found incorrect in the first place.
    It’s not the method …… (Peopleware) .