Additional Blogs by SAP
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert
0 Kudos


This is the fourth 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).

In this part, I will describe how to construct a model to observe and measure that value for architecture stakeholders.



Organisations rarely define or understand the relationship between the products of Enterprise Architecture and their defined business goals.

Stutz (2010) (Ref.1) summarised one of 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 organization 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.

This is a common problem in any normal value lifecycle management exercise.  Benefits Management and Value Modelling Techniques have been used for some time already to help organisations map objectives to deliverables and metrics.  Value lifecycle management takes an outline business case down to the next level, to map benefits to the required process changes and the specific solution design attributes required.

Swanton (2010)(Ref.2) provides the example of SAP which has made a major investment during the past six years in helping companies develop rigorous business cases, and understanding the process changes needed to generate value, and the measurements to ensure that it is achieved. These tools and services are wrapped in methodologies for value management and implementation, with the goal of getting customers to take the necessary steps to ensure that their projects deliver benefits.

When creating such a Value Model it is important to understand the metamodel or ‘object definitions’ of what is being mapped. If one can use existing standard industry metamodels, this will greatly improve the desired understanding of the model as the objects being mapped will be commonly understood. In Enterprise Architecture terms, the TOGAF 9 metamodel is the nearest the example of a common architecture metamodel. (Ref. 3)

Van den Dungen and Visser (2010) show how one can take the existing metamodels of TOGAF, and couple them to the metamodels of value management and performance management, in order to map the value of a key business change. (Ref. 4 and 5)



A strawman example is shown below in Figure 1, using typical objects from a combined TOGAF9 metamodel and value management metamodel to map the value of a Transformation Programme to its architecture components:

Figure 1 – Mapping the Value of a Transformation Programme

Further metamodel entities could, of course, be added such as Measures or Business Services.

Taking this a step forward, one can use the same technique, to demonstrate the value of an enterprise architecture practice. The fifth blog in this series will further explore this.


  1. Stutz (2010) -How to Measure the Value of Enterprise Architectures – Deutschsprachige SAP-Anwendergruppe (DSAG). Zurich
  2. Swanton (2010) - Vendor Focus for SAP: SAP Value Management Services - Gartner Research. Available from
  3. The Open Group Architecture Framework. (2009) Version 9. The Open Group.
  4. Von Rosing (2010) - How to apply Performance Management & Value Management to TOGAF Meta Model A and B -  Available from
  5. Van den Dungen and Visser (2010) Using the TOGAF 9 Meta Model to Measure Value in an Enterprise Architecture. Proceedings of The Open Group Conference Amsterdam, 18 – 22 October, 2010. Available from