Enterprise Architecture Value Framework (EAVF)

Enterprise Architecture Value Framework (EAVF) is a framework to quantify the benefits of Enterprise Architecture. EAVF uses the four perspectives of the Balanced Scorecard as a dimension in classifying EA benefits in line with the idea that the purpose of EA is to enable organizations to realize their business goals (Steenbergen and Brinkkemper, 2008) where the Balanced Scorecard is commonly used for structuring business goals.[1]

EAVF adds a second dimension to account for EA benefits' evolution over time. EA lifecycle has three main phases that may be discerned in the process from idea to delivered result: the development of the architectural artifacts (principles and models), the application of the architecture in projects, and the resulting changes in business processes and systems. In these three phases, different stakeholders are involved who may benefit in different ways. During the development of the EA artifacts, benefits may occur because conversations take place between architects and decision-makers, and experts about several aspects of the organization, from a holistic perspective. This may create awareness and insights. When the EA prescriptions are applied in business projects, benefits may occur because the EA insights enable better management of projects: risks for instance can be assessed more precisely or timelines can be predicted better. Finally, when parts of the target architecture have been implemented, the organization should be able to reap benefits such as increased agility, lower costs or greater operational efficiency. On the horizontal axis of the framework, the four perspectives of the Balance Scorecard as originally published by Kaplan & Norton (1992) are plotted, while on the vertical axis of the framework the three phases of EA from its development to its implementation and use of the results are shown. These perspectives and phases are discussed in more detail in an earlier paper (Plessius et al., 2012) in which the phases are coupled to TOGAF (2011) as well1. With the mutually independent dimensions of time and goal perspective, we have created a framework in which it should be possible to position every EA benefit reported. [2]

The Categories, Phases, and Dimensions of Enterprise Architecture Value Framework (EAVF) (See Figure 1.)[3]
To be able to measure value, an operational definition of value is adopted: “value is the contribution to the goals of the organization”. By this definition, value can be a contribution to the profit of the organization, but also a growth in customer satisfaction or in the agility of the organization. It may even be a decrease in productivity (which, when the goal is to increase productivity, is an example where value is negative). There are only four categories or perspectives to decision-makers in organizations. Hence, the value measurements will be carried out with respect to the following four perspectives:

  • Financial: the financial perspective can be characterized as the shareholders' view of the organization. The keywords here are costs, risk, and compliance.
  • Customer: the customer perspective is the organization. Customer satisfaction and market share are generally important questions here.
  • Internal: the internal perspective is its managers and employees. The focus is normally on internal efficiency and productivity, but work satisfaction accounts as well.
  • Learning & growth view. The central question is the continuity of the organization in the long term. Typical keywords here are innovation and change.

So, apart from being related to the goals of the organization, value evolves in time. This can take place during the development and implementation of EA in the operations (step 1) as well as after the operational changes are implemented (step 2). For the first step – towards the implementation of the EA – two logical phases can be discerned: the architecture development process, resulting in the target architecture, and the realization process aimed at implementing this target architecture. In the second step, when (parts of) the target architecture are implemented in operational processes and systems, we differentiate, based on reported benefits, between the value resulting from the plain use of the results and the re-use of these results, as stimulated by the EA, in different environments. These considerations have resulted in four phases in the model, which below are summarized and related to the familiar phases in the Architecture Development Method (ADM) of TOGAF9 as well:

  • Development: in the development phase, the EA is developed and maintained. This phase corresponds with the ADM phases Architecture Vision, Business Architecture, Information Systems Architecture (ISA), and Technology Architecture.
  • Realization: the realization phase is where programs are defined and projects are carried out to implement the changes defined in the EA. This phase corresponds with the ADM phases of Opportunities and Solutions, Migration Planning, and Implementation Governance.
  • Use: After the implementation, changes have been implemented in the organization and the time to collect the promised benefits has come. Monitoring the new architecture (Architecture Change Management in ADM) is a continuing activity in this phase.
  • Re-use: the Reuse phase is a seamless continuation of the Use phase and as such part of the phase Architecture Change management in ADM. However, after implementing parts of a new architecture, re-use of these parts may have a big influence on the next parts and thus yield value.

While the second axis of our model is defined by time, it is loosely coupled with organizational responsibilities as well. In general, the architecture function in an organization is responsible for the development phase while for the realization phase the change function (program and project leaders, portfolio managers, etc.) has the responsibility. In the use phase, the operational function takes over the responsibility and for the re-use phase, the architecture and change functions should both be responsible. Since in the model the two dimensions (perspectives and phases) are mutually independent, they can be combined into a framework: the Enterprise Architecture Value Framework (EAVF) as shown in figure 1.

The Enterprise Architecture Value Framework with horizontal the four perspectives of the Balanced Scorecard and vertical the four phases where value may be created.
Phases and Dimensions of Enterprise Architecture Value Framework (EAVF)
Figure 1. source: Hogeschool Utrecht, University of Applied Sciences

The primary strength of a complete framework is that it subdivides the value universe. For example, in the framework, each cell is focused on a specific aspect and timeframe which makes it easier to identify where benefits and costs may originate and who are the stakeholders. The difficult question remains however if the changes in value are (at least partly) the result of the EA.

See Also


  1. Definition of Enterprise Architecture Value Framework (EAVF)
  2. What is Enterprise Architecture Value Framework (EAVF)? Aisel
  3. The Categories, Phases, and Dimensions of Enterprise Architecture Value Framework (EAVF) Henk Plessius, Raymond Slot and Leo Pruijt

Further Reading