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:
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:
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:
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:
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