Skip to Content

 

BACKGROUND

This is the second in a six-part blog post that address one of the most important topics facing Enterprise Architects; namely how to justify the value of Enterprise Architecture (EA).

The first part of the blog is published here. The Value of Enterprise Architecture – Part 1- Introducing the problem

In this part, I will focus on why it is so difficult to define such value.

 

THE $64,000 QUESTION…SO WHY IS IT SO DIFFICULT TO DEFINE?

 

Why is a lack of business case or value proposition such a problem for Enterprise Architects if surveys such as the ASUG/SAP EA Best Practices Survey (which I discussed in my first blog in this series) (Ref.1)  present clear examples?

The problem is anecdotal evidence of this is not new ; there are many examples of industry studies showing the potential value that EA delivers, largely from similar anonymised surveys and studies:

 

  • Ross (2004) found from a study of 103 firms that were most effective in achieving strategic objectives through EA initiatives had a greater relative profitability to their competitors. (Ref 2.)

 

  • Allega (2005) found empirical evidence from a 2001 survey of CIOs, which demonstrated the average cost per end user for IT functions with EA as $12,736, while without EA it was $27,709, showing that architecture best practice can reduce IT expenditure by more than 30 percent. (Ref 3.)

 

  • Recent research from EA Executive Board (2010) has found that increased EA Maturity can significantly impact project delivery performance demonstrating percentage improvements of more than 40% in on-time and on-budget performance. (Ref 4.)

 

Indeed anecdotal evidence can often easily be gathered within an organisation from its own architects’ experiences to show examples of the value of EA (Rosser 2006) (Ref 5. and 6.).

 

In the author’s own experience, the value of EA has often been justified based on cost avoidance of software procurement due to identification of overlapping functional scope of two or more proposed projects in an organisation, or the potential cost savings of IT support by standardising on one solution. The flipside of cost and risk avoidance of course must also be considered. Enterprise Architecture often also plays the role of a key shaper and instigator of visionary investments. Its structured approach can ensure that companies more effectively discover new opportunities by linking technology innovation to their business objectives. Enterprise Architects when citing anecdotal evidence should concentrate on both views.

 

Anecdotal examples are an important source of information to show that EA does achieve what it aims to do, and is contributing real value, but a more formal approach is needed to demonstrate value if we are to solve the common problem of a lack of business or value proposition.

This challenge is not new to the Business or IT world. It is generally alot easier to identify costs of doing something than the value delivered by it.

  

HOW WE PUT A VALUE ON CHANGE

 

In any “change”, we either decide to do new things, do the things we do already better, or stop doing things we are already doing. The value of doing these changes can be identified as:

 

  • Financial – i.e. by applying a cost/price or other valid financial formula to a quantifiable benefit, a financial value can be calculated of implementing such change;

 

  • Quantifiable – i.e. sufficient evidence exists to forecast how much improvement/value should result from the change; 

 

  • Measurable – i.e. the aspect of performance we wish to change is currently being measured but it is not possible to estimate by how much performance will improve when the changes are complete ; nevertheless we can track it;

 

  • Observable – i.e. by use of agreed criteria, we can decide, based on experience and judgment, to what extent the benefit has been realized.

The degree of explicitness of value we can define depends on what we change. For example, if we decide to stop doing something we already do (e.g. sending out paper invoices), or improve what we already do (e.g. process payments quicker); we should be able to explicitly define the financial value involved as the knowledge of the costs/value will be much more intimately known within an organisation.  (Ward and Daniel, 2006) (Ref 7.)

However, if we decide to do something new we haven’t done before (e.g. enter a new market, deliver a new product through a totally new channel) we are unlikely to have enough experience or knowledge to define the value to be created from that change, and little financial evidence to produce quantifiable benefits. (See Figure 1 below).

Figure 1: Explicitness of IT Value (adapted from Ward and Daniel 2006)

 

In the case of EA as a method of practice, we should be able to:

 

  • Measure the implications of EA using existing or new measurement techniques (if we measure the right things);

 

  • Observe the implications of EA (if we know the sorts of things to look out for).

EA is no different to any business change; the trouble is for many organisations it is a new support process where it is difficult, almost impossible, to quantify the value generated.

Allega (2005) concludes that the benefits of EA are almost impossible to define to a level of financial explicitness (Ref 3.).  Return-on-investment (ROI) calculations require the financial outcomes expected from a project in the form of additional revenue or cost savings to be forecast and compared to the costs of undertaking the project. Techniques used to determine the ROI of individual projects, are not valid when applied to EA, because the benefits cannot often not be allocated to EA itself. The use of EA deliverables are not applied, and the benefits are not visible from the short-term payback requirements of such techniques.

Furthermore, although applying EA achieves qualitative benefits (these will be discussed in Part 3 of my blog), any quantification of those results also depends on the effective application of other key techniques, which also would claim similar value.  For example, an EA may create a future-state roadmap, or architecture guideline, but if it is not used in creating a new service (because the organisation lacks say effective IT Service Planning); then the value of EA will be severely limited.

 

THE REAL PROBLEM

It is clear that Enterprise Architecture Best Practice provides a clear framework, principles, and method to deliver a design or roadmap or strategic advice; however, it will not be the EA steps that lead, for example, to lower IT spend.

 

It is the realized and implemented design, that will lead to that lower IT spend. For example, EA may contribute that a specific SAP Business Suite best practice is mostappropriate for an organization; however it is the running of that SAP Business Suite process that delivers the efficiency improvement, not the EA.

 

EA is a key competency, but a support process, analogous to other support processes e.g. strategic procurement. That support process ensures a proven way of working that then generates more efficient downstream results.

Stutz (2010) (Ref.8) summarises the difficulties facing those aiming to quantify the value of EA as:

 

  • The distance of EA from a company’s value chain; i.e. if the aim or objective of an organisation is to sell more of particular product it makes, EA should provide the guidelines and principles advising how the process is best supported by implementing CRM; but it is difficult to define how much more product the company will sell as a result of that.

 

  • The indirect and diluted effect of the enterprise architecture activities on company’s activities; i.e. although EA delivers the structured framework, and method that enables more effective IT Service Planning or Enterprise Portfolio Management, it is difficult to isolate that specific effect.

 

  • The time-lag between the initiated enterprise architecture activity and its generated benefits; i.e. the value of creating a corporate storage architecture roadmap now cannot be fully defined, as it is difficult to predict the cost and benefit of a project in two years time that would use that architecture or account for it. Most organisations’ financial processes focus on short-term payback and lack the benefits management techniques to track such benefits over many years.

However, just because an ROI cannot be demonstrated, this does not mean we should not try to identify the value of EA, or spell out the benefits gained from it. Indeed, the value from EA must be defined, and be convincing if Enterprise Architects are to receive any form of consistent support for their efforts, and for people to change their current ways of working. Other methods of measurement to Financial ROI must therefore be employed to define it.

Ward and Daniel (2006) (Ref.8) identify that it is not always possible or desirable to justify projects solely on the basis of financial measures, such as ROI.  If this was taken to extreme and we justified and measured all business change according to financial measures ;  the level of innovation or new processes/systems in an organisation would be squeezed out as such initiatives would be very difficult to cost justify as there would be no existing cost information available. Doing new things would simply not be financially justifiable or quantifiable. On the flip-side, projects with the largest or fastest financial return would take the lion’s share of an organisation’s investment.

So in short, given that EA for many organisations is “something new we must do”, we should look to measure and observe the impact of its introduction if we are to demonstrate its contribution, just like any business would if they decided to do something innovative. Typically the first step in this process is to define Process Performance Indicators (PPI) so that we can start to measure this contribution; this is discussed in later blogs.

In Part 3 of this blog, we will identify the different types of benefits gained through the application of Enterprise Architecture that can be used as a starting point to identify its value within an organisation. This will help Enterprise Architects focus on what to measure and what to observe.

 

REFERENCES

 

  1. ASUG Enterprise Architecture Best Practices Survey – October 2010 – Aggregate Findings Report. ASUG.
  2. Ross (2004) – Generating Strategic Benefits from Enterprise Architecture. Research Briefing Volume IV Number 3A. CISR Sloan School of Management – MIT.
  3. Allega (2005) – Enterprise Architecture Will Never Realize a Return on Investment. Gartner Research
  4. EA Executive Council (2010) “Create Impact in the First 100 Days-Executive Summary”. Available from  https://www.eaec.executiveboard.com/Public/ExecutiveSummary/Documents/First-100-Days_ExecSumm.pdf
  5. Rosser (2006) – Measuring the Value of Enterprise Architecture: Value Context. Gartner Research
  6. Rosser (2006) – Measuring the Value of Enterprise Architecture: Metrics and ROI. Gartner Research
  7. Stutz (2010) -How to Measure the Value of Enterprise Architectures – Deutschsprachige SAP-Anwendergruppe (DSAG). Zurich
  8. Ward and Daniel (2006) – Benefits Management: Delivering Value from IS and IT Investments – John Wiley & Sons.
To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Frank Schuler
    In my experience there is only one way to prove the benefit of IT architecture and that is to link IT investments to the business benefits via a structured top down IT architecture approach. I described this approach in a blog on SDN as well (“The value of IT architecture”).
    (0) 
  2. Gourav Khare
    In my opinion, many companies are still evolving from “Standarardized Technology” to “Optimize core” and still understanding what it mean to have fulltime EA team in place.
    I think to measure EA value you should focus on following (Ross):
    – Reduced IT cost per unit (operation/maintenance)
    – IT responsiveness to Business (how aglie IT is to business change)
    – Better Risk Management
    – Increased customer/management satisfaction

    EA is not one time project which ongoing process. For example implementing SAP business suite (as suggested by EA) brings cost saving and customer satisfaction, w/o EA probably organization will decide to build their own application or still managing complex web of legacy apps.

    Regards,
    Gourav

    (0) 

Leave a Reply