EABV Model

The Enterprise Architecture Business Value Model (EABV M) clarifies the concept of EA business value by defining it and describing it in a greater context. Furthermore, it serves as basis for storing assessments along with goals and metrics in the in the EABV FW Repository. The need for such a model stems from the fact that no clear definition or common understanding for EABV exists within our partner company, and even in literature. We already gave the definition and the description of the conceptual EABV model in Section 3.7 whereupon the EABV M is based. The problems which are to be solved with this model are outlined in Section

4.1.1. From this needs, we can derive the objectives for this artefact which are summarized as follows:

 Define EABV in an integrated and consistent way throughout the organization by providing an EABV metamodel

 Provide a basic way to support a common understanding of EABV

 Provide a basis for storing assessments including goals and metrics that are reusable As we can see, this artefact possesses mainly informative character besides being a reference for implementation purposes. The EABV M is illustrated in Figure 5-3 as a conceptual UML class diagram in order to convey the fundamental concept of our approach. The importance of conceptual modelling is further discussed in (Wand and Weber 2002). While employing an UML class diagram notation on a conceptual level, it has to be noted that alternate modelling languages could be adopted. This conceptual class model marks the starting point for the subsequent data modelling approach described in Section 5.3.1. The key points of this model are formulated as follows:

 Strategy from Stakeholders defines Goals

 Goals‘ Performance is measured by an Assessment by employing Metrics  Goals have Critical Success Factors

 Key Performance Indicators are Metrics to measure Critical Success Factors  Performance determines and is translated into Business Value

 Goals drive Business Value

As we can perceive from the model, the set of attributes constitute a template for goal, metric, and business value. We will describe those in the next sections along with the conceptual data model.

5.3.1. Conceptual Data Model

Our data modelling efforts start with the conceptual data model. Herein, we choose the most important entities to explain the basic nature and layout of our approach. It is a high level description for what is relevant to the business. In our case, how EABV is assessed. The conceptual data model is depicted in Figure 5-4 using the Crow’s foot notation. Although the choice of notation is arbitrary, we opted for this notation as the data architects of our corporate partner employ it and therefore alleviates common understanding in this given organizational environment. As we can see, an assessment is conducted by stakeholders which have different forms of participation depending on their roles and responsibilities. An assessment yields results. These resemble communicated EABV, the satisfaction of the information need. Communicated EABV results are considered as information products in the form of EABV reports. It comes to no surprise that we need various stakeholders to conduct an assessment. An assessment needs goals as it is driven by them. For these goals, we need several metrics that measure those goals. Consequently, we designed a goal-driven approach to assess EABV. Just employing metrics alone without the relation to any sort or goals is rather likely to be a failure (Dekkers 1999). We will further define these entities in the following subsections and take a closer look at the EABV M when instantiating it by describing the logical data model and physical database in Section 7.3.1 and in Appendix A.

5.3.2. Assessment

An assessment is a method or process that informs us about current performance of an enterprise function or components thereof. Performance can be described as purposeful actions taken today to produce meaningful results tomorrow (Neely 2004). Assessment is not only about measuring performance. It also comprises the activities of analysing performance data, communicating results, and the evolvement that is triggered by setting actions towards an improvement based on those results (cf. Sec. 5.3). As already mentioned in Section 2.6, we are focusing on continuous EA assessments.

5.3.3. Goals

A goal is a statement of intent to direct an organization which is used to measure an organization’s (stakeholder’s) success, and serves as time-bounded milestone for an organization (stakeholder) to demonstrate progress. This definition is based on the definitions of goals and objectives in (The Open Group 2011a). For our purposes, objectives are sub-goals that are measured. Our model give us the goals’ structure and the description of content based on the software-level goal formulation by (Basili et al. 2009). Basically, by using this template, we can insert new goals that are precisely described and can be reused. Additionally, it determines how goals are stored. Every goal has a name usually stating the basic intent. Activity describes what needs to be done to achieve this goal. The focus further explains the key aspect of this activity. The asset clarifies which resource or asset respectively is integrated, reconfigured, gained or released. This is in alignment with the activity description. The critical success factor constitutes the target or magnitude that stating whether the goal was successfully achieved or not. Success can be defined in terms of making progress towards strategic goals, but often success is simply the repeated, periodic achievement of an operational goal (e.g. 99% server uptime).

We also need to be aware in which timeframe this goal needs to be achieved. The scope limits the activity to certain domains, areas of application, or objects. Constraints give a description what kind of limits or boundaries will be encountered while aiming to achieve this goal. For example, we might have a limited budget or personnel availability. Relations inform us about which goal is impacted by this goal and vice versa. This reflects the content of a strategy map as we will describe later in Section 5.5.5.

When focusing on operational level assessment, we can opt to choose already defined project goals if appropriate. This is the usually the case when we have pure EA projects. In case of projects with only partly EA contribution, it proves to be useful to choose goals that are aligned

to project goals, but emphasize on the actual EA contribution and the objectives related to this effort. An example goal is outlined in Table 5-3. We will revisit goals as part of our case study in Section 7.3.5.1.

Name Name of the goal Activity Increase

Focus Area Customer satisfaction

Asset Product X

Critical Success Factor 15% reduction of customer complaints

Timeframe 12 weeks after release

Scope SAP products

Constraints Product price and functionality

Relations Can conflict with…/Has synergies with…

Perspective EA BSC perspective (cf. Sec. 5.5)

Table 5-3: Example goal

5.3.4. Metrics

In general practice, the terms metric, measure and indicator are often confused or used interchangeably. In some instances, this may pose no problem due to their actual similarity. Nevertheless, we want to distinguish between those terms by providing clear definitions (Bundschuh and Dekkers 2008).

Measure – The aim of measures is to describe certain aspects and characteristics of business functions. Measures are mainly used for reporting and controlling purposes. Consequently, they are quantitative and are applied to processes, services, projects, etc. Measures are considered as absolute measures as they can be retrieved from business data without the need of prior calculation.

Metric – Metrics are used to evaluate processes, services, projects, etc. and thereby enable benchmarking capabilities. They serve as common denominator for comparisons between two or more observed measures. They are usually calculated and therefore are considered as relative metrics. The aim of metrics is to deliver decision support, i.e. they should incorporate the capability to let decision makers infer future performance as well as assist in various planning processes. Metrics can be critical success factors which inform the stakeholders what conditions and requirements must be met in order to achieve a certain goal. Moreover, they can indicate how effective that particular goal was achieved.

Indicator – An indicator, similar to metrics, are used to compare performance to a baseline or particular result. They are collected over time and are mostly used to predict or understand

trends. A key performance indicator is an indicator (or metric respectively) that is tracked against a critical success factor.

Notably, we decided to use the term metric for our conceptual model as it encapsulates measures. Moreover, depending on the context a metric can be used as an indicator. During the definition of our metrics for our metrics template based on (Vasconcelos et al. 2007), we came across special cases, namely a Boolean metric which simply indicates whether a certain condition is satisfied. By definition, this would be a measure due to its absolute character but we deem it not very practical to provide a separate measures template for such cases and therefore, some metrics are actually (basic) measures. As with the goal template, the metric template defines the representation of a metric within our assessment approach. It is illustrated in Table 5-4 and described more detailed in the Appendix A.2.19 Furthermore, we outline the goal-metric alignment for our focus project in Appendix B.1.4.

Name Name of the metric Acronym Acronym of the metric

Description Description of the outcome of the EA contribution

Computation Formula or algorithm of the metric to specify how it is computed

Implementation Describes how this metric is implemented and used

Accountability Stakeholder responsible for this metric

Cost Cost of employing the metric

Scale Possible values for the metric

Unit Unit of the metric

Architectural

levels Relevant architectural levels, i.e. where is the metric used (e.g. business architecture) Dependencies Describes dependencies to other metrics

Qualities Related EA qualities, such as conceptual integrity, simplicity, cost etc.

Table 5-4: Metric template

5.3.5. Business Value

We defined EABV already in Section 3.7. The business value template is the actual representation of EABV and is the core of what will be reported. It is illustrated in Table 5-5 while described more detailed in the Appendix A.2.11. Notably, influencing factors on performance and lag effects are reflected in the enabler and inhibitor attributes. Outcome can be linked to specific projects, services, or processes and also describes the impact of the outcome. For the actual report, we also include the date of the data collection, which method was used to analyse data, and what tools were employed.

EABV Short statement of EABV

Outcome Description of the outcome of the EA contribution

Source Description or link to the sources of the EABV, e.g. an event or stakeholder. If applicable, we also

describe lag effects here.

Receiver Description or link to the receiver of the EABV, e.g. an event or stakeholder

Enabler Description or link to the enabler of the EABV, e.g. an event, a stakeholder, or an external factor

Inhibitor Description or link to the inhibitor of the EABV, e.g. an event or stakeholder, or an external factor

Table 5-5: Business value template