Currently Being Moderated

BACKGROUND

In the first and second parts of this blog, I focused on why it is so difficult to define the value of Enterprise Architecture.

The Value of Enterprise Architecture - Part 1- Introducing the problem

The Value of Enterprise Architecture - Part 2 - Why is it so difficult to define?

In the third part, I summarized the main benefits of EA to show where to start to look to define that value.

The Value of Enterprise Architecture - Part 3 - Summarising the key benefitsThe Value of Enterprise Architecture - Part 1- Introducing the problem

In the fourth and fifth part, I showed how to construct a model to start to observe and measure that value for architecture stakeholders.

The Value of Enterprise Architecture - Part 4 - Applying Value Management

The Value of Enterprise Architecture - Part 5 - Example value models

This is the final concluding part of my blog series on EA value.

 

SO WHAT NOW?

From reviewing the literature and work available, it is clear there is no silver bullet or magic solution to defining EA value, and no stepwise guide or method to follow.

Most experts agree that EA does contribute important benefits, that these increase the more mature an organization’s approach to EA is, and that it is relatively straightforward to identify anecdotal examples. However, there is no clear method for defining that value, and then measuring it.

In order to solve that problem, one would need to define a series of standardized measures, and analyze these over time, to make more concrete correlations. The process to rigorously collect the required structured data across many organizations and industry types has not yet been defined. If this were to be achieved, and the data analyzed, one could then make clearer statements and conclusions on the topic.

If organisations are to develop “mature enterprise architecture..... demonstrating that business strategy will be pervasively understood and supported within EA and across business and IT”, (Ref. 1), and one of top challenges identified for EAs is to be addressed (Ref. 2), it is clear that the topic of value management is going to be key in 2011-12.

Value Management typically follows four key steps:

 

  •  Value Identification - where we identify the benefits to be gained, baseline the current state, and develop conservative estimates of what we can achieve ; guided by architecture stakeholders and their priorities as it will be impossible to measure everything;

 

  • Plan Benefits Realization – where we design and identify effective measures, develop a value model, build a measurement process and get agreement from those stakeholders;

 

  • Execute Realization Plan and Evaluate Results – where we review progress against the plan and take necessary corrective actions, and ensure we communicate the results to those stakeholders;

 

  • Establish Potential for Further Improvements – by identifying additional changes or investment needed.

 

It is clear Enterprise Architects in future will need to be:

 

  • Much clearer on what they are delivering and be able to measure this; although demonstrating what is going on does not always demonstrate overt value, it does define what is happening. This awareness of what is happening is key if people are to buy into the results of EA;

 

  • Much clearer on the organization’s business goals and the required organizational performance to deliver these, and be able to measure these; otherwise how can they ever hope to relate their activities to real business value?

 

  • Be able to construct and explain a value model of the above to their stakeholders; otherwise they will not be able to spell out the desired value of EA via the explicit benefits gained from it.

 

As part of value identification, it is typical to create a business case. A similar approach can be adopted for EA where one can define the tangible and intangible benefits can be gained against the costs of setting up and running an EA practice in an organization.

Figure 1 below shows an example business case structure, based on the some of the example benefits identified in this paper. This addresses both sides of the EA equation; namely those related to business value and those related to technical value. The technical part mostly addresses the TCO and TCI side of potential benefits. The business value side addresses the contribution that EA can have on the business objectives of an organization (Ref.3).

 

Business Case

Figure 1 – Structuring EA Benefits into a Business Case

 

In this way, Enterprise Architects will be more able to gain the support and resources they need to support their organization effectively. Successful EA programs are ones that are visible to senior executives and provide evidence of their business contribution based on solid metrics, scorecards and reporting systems. These will demonstrate the impact of EA on both IT and Business investments and how such an approach can reduce cost and complexity, mitigate risk, and enable new opportunities to be exploited.

 

 REFERENCES

  1. Enterprise Architecture Hype Cycle (2010) Gartner.http://www.gartner.com/it/page.jsp?id=1417513
  2. ASUG Enterprise Architecture Best Practices Survey – (October 2010) Aggregate Findings Report. ASUG.  http://www.asug.com/EventsCalendar/EventDetails/tabid/150/EventID/2024/Default.aspx
  3. Von Rosing and Van den Dungen (2011) - SAP Lead Enterprise Architect Development (LEAD) Program.

Comments