A METHOD FOR BUSINESS CAPABILITY DEPENDENCY

ANALYSIS

Andreas Freitag, Florian Matthes, Christopher Schulz

Technische Universit

at M

unchen, Boltzmannstrasse 3, 85748 Garching bei M

unchen, Germany

Aneta Nowobilska

Detecon International GmbH, Oberkasseler Strasse 2, Bonn, Germany

Keywords:

Enterprise architecture management, Business capabilities, Business entities, Dependency analysis.

Abstract:

Business capabilities are a key element of a modern Enterprise Architecture Management (EAM) approach.

They are the core component of a business architecture and essential for communication between business

and IT. There is an enormous interest among academics and practitioners reﬂected in a growing number of

publications on deﬁnition, use cases, and experiences from case studies. However, due to the innovative

character of business capability approaches, many issues have not been subject to structured research yet. One

topic that has not been addressed so far, is the analysis of dependencies between business capabilities, which

is a crucial aspect for the integration of new business capabilities. This paper presents a three-phase method

to systematically identify dependences between business capabilities and to other elements of the Enterprise

Architecture (EA). We built this method on the assignment of the business entities to business capabilities.

Based on existing visualizations, we developed a business entity map and an information ownership map to

support the analysis. We applied a design science approach to develop the method which has been tested

during application in the three companies. Additionally, we illustrate the method with a case study from the

telecommunication industry.

1 INTRODUCTION

Business capabilities are an essential element of a

modern Enterprise Architecture Management (EAM)

approach. In the last years, they are the core com-

ponent of business architecture and are essential for

communication between business and IT (Barroero

et al., 2010; Scott et al., 2010). The concept and appli-

cation of business capabilities is addressed by numer-

ous publications originating from different sources,

for example analyst reports, conference proceedings,

consultants, EA practitioners, as well as from aca-

demics.

Business capabilities focus on the enterprise’s

ability to perform activities from a functional perspec-

tive, for example conduct ”customer management” or

”direct sales”. Supplementary, business entities are

the corresponding elements of the business architec-

ture that represent the information needed to imple-

ment a business model. Examples are a ”customer

contract” or a ”sales offer”. The combination of both

concepts provides a common terminology for busi-

ness and IT stakeholder.

Business capabilities are applied in a large variety

of EAM tasks which include architecture description

(e.g. as-is landscape, SOA modeling), architecture

analysis (e.g. business strategy support, dependencies

between elements, identiﬁcation of functional redun-

dancies, data quality analysis, business process analy-

sis), architecture planning (e.g. investment, target ar-

chitecture, SOA modeling), preparation of decisions

(e.g. sourcing, selection of solutions or technologies),

as well as for communication and visualization activi-

ties (e.g. demand management, change management)

(Brits et al., 2007; Barroero et al., 2010; Keller, 2009;

Klinkm

uller et al., 2010; K

onig et al., 2005; Weber

and Schmidtmann, 2008).

The majority of the use cases mentioned above de-

pends on the availability of information about rela-

tions between single elements of the enterprise archi-

tecture (EA). For example the capability-based doc-

umentation of the as-is landscape requires knowl-

Schulz C., Freitag A., Nowobilska A. and Matthes F. (2011).

A METHOD FOR BUSINESS CAPABILITY DEPENDENCY ANALYSIS.

In Proceedings of the Second International Conference on Innovative Developments in ICT, pages 11-20

DOI: 10.5220/0004471100110020

 SciTePress

edge about the relation between a business capabil-

ity and applications. The single elements and their

relationships are represented in an enterprise’s EA

model (Barroero et al., 2010; Buckl et al., 2011).

Innovation is an especially important aspect in

EAM and management of business capabilities (Brits

et al., 2007; Cullen et al., 2006). The directions

for innovation are deﬁned in an enterprise’s business

strategy and considered the corresponding business

model. Both determine the need for new business ca-

pabilities that are required to support innovative prod-

ucts, services or technologies and therefore need to

be reﬂected entirely in the enterprise’s business ca-

pability model. Consequently, the model has to in-

clude business capabilities needed in future that have

to be planned and established, as well as those that

are implemented today. For example, a future ”direct

sales” capability can be the result of a growth strategy

that builds on modern information and communica-

tion technologies (ICT).

New business capabilities have to be integrated

seamlessly into the existing landscape. The establish-

ment of a ”direct sales” capability, for example will

have requirements concerning other business capabil-

ities, e.g. regarding ”customer management” and re-

quirements concerning the availability of information,

e.g. the business entity ”customer contract”. This ap-

plies equally to the case of internal development and

to an external acquisition.

Therefore, when establishing new business capa-

bilities, a dependency analysis for business capabili-

ties has to deliver transparency about related business

capabilities and business entities. Additionally, the

analysis has to consider other related architecture ele-

ments, e.g. applications, databases, or infrastructure.

Even though they do not belong to the business ar-

chitecture, their relations can result in a dependency

between business capabilities and business entities.

Using the example of establishing a future ”direct

sales” capability, the availability of customer man-

agement solution (application architecture) or con-

nectivity (communication infrastructure) can result in

strong dependencies to the ”customer management”

capability or the business entity ”customer contract”.

A comprehensive literature analysis performed by

the research group revealed, that a concrete method

to analyze dependencies between business capabili-

ties is missing. As a possible starting point, the rela-

tionships between the single elements in an EA model

show that business capabilities are directly and indi-

rectly connected to other architecture elements (Buckl

et al., 2011). Therefore, we build on the poten-

tial of an EA model to support a dependency anal-

ysis in our research. An architecture viewpoint is

a graphical representations of the overall EA model

that are meaningful to stakeholders to enable com-

munication and common understanding (Buckl et al.,

2011; International Organization For Standardization,

2007). However, the visualization of the relationship

between business capabilities and business entities on

a business architecture level has not been addressed so

far.

In this paper, a method for analysis of dependen-

cies between business capabilities is presented. The

method is based on an EA model and the business

capability map, an existing architecture viewpoint.

Additionally, the authors introduce the business en-

tity map and the information ownership map as corre-

sponding new architecture viewpoints.

The remainder of this paper is structured as fol-

lows: Section 2 gives a short summary on the research

approach applied. Section 3 provides an overview on

existing EA-related business capability and business

entity literature. Section 4 introduces a method for an-

alyzing business capability dependencies, as well as

architecture viewpoints for business capabilities and

business entities which have been applied success-

fully in the real-world business environment. Finally,

section 5 concludes by summarizing the article and

outlining further ﬁelds of research.

2 RESEARCH APPROACH

The authors followed a design science approach

in order to contribute to the identiﬁed area of re-

search through the building and evaluation of inno-

vative artifacts designed to meet identiﬁed business

needs (Hevner et al., 2004). According to (March

and Smith, 1995), an artifact refers to all innovations

attempting to create utility for an organization: con-

structs, models, methods, and instantiations.

The research activities to develop the contribu-

tions presented in this paper follow (Hevner et al.,

2004)’s guidelines for understanding, executing and

evaluating the research.

• Design as an artifact

The presented method to analyze dependencies of

business capability is a viable artifact. It is de-

scribed comprehensively enough to be further ap-

plied to solve real world issues.

• Problem relevance

The artifact addresses the problem of identifying

and analyzing dependencies of business capabili-

ties, which are necessary for numerous use cases.

This relevance arises from the ﬁndings from a pro-

found literature study as well as practitioner’s ex-

periences.

INNOV 2011 - Second International Conference on Innovative Developments in ICT

• Design evaluation

The artifact as been evaluated in the business en-

vironment (observational evaluation).

• Research contributions

In this work, we present a method for analysis of

dependencies of business capabilities, which has

not been published so far.

• Research rigor

During three construction and evaluation phases,

applicability and generalizability of the artifact

has been ensured.

• Design as a search process

The artifact has been designed iteratively, incor-

porating feedback collected in the real-world busi-

ness environment.

• Communication of research

The artifact is published in this paper to make it

available to both, management and technology au-

diences.

According to (March and Smith, 1995) and

(Hevner et al., 2004), design science research com-

prises two phases “build” and “evaluate”, which are

processed cyclically. After building the initial ver-

sion of the artifact, it was applied in the context of

a real-world case study in the telecommunications in-

dustry. After a ﬁrst reﬁnement incorporating lessons

learned, a second iteration was conducted by applica-

tion in two projects in the energy and insurance indus-

try. Consequently, the method presented in this paper

is the outcome of three iterations.

Prior to the ﬁrst building phase, the authors con-

ducted a profound literature analysis for capability

resources according to proven guidelines (Webster

and Watson, 2002) to provide the baseline of exist-

ing knowledge and identify existing gaps. A short

overview on publications relevant to the ﬁndings pre-

sented in this paper is given in the following section.

3 RELATED WORK

3.1 Literature Analysis

We conducted a thorough analysis of existing publi-

cations regarding the concept and application of busi-

ness capabilities and business entities. Our team

investigated the following sources of EA and EA-

related resources: EA literature reviews, our research

group’s EA literature database, and online search.

Due to the limited space available in this publication,

only a summary of these ﬁndings is presented. The

related literature is structured as follows

• Enterprise Architecture Management (books and

frameworks)

• Concept of business capabilities, deﬁnitions, and

visualizations

• Concept of business entities, deﬁnitions, and vi-

sualizations

• EA model: Relation of business capabilities and

business entities

In 2008, Aier (Aier et al., 2008) and

Sch

oenherr (Sch

oenherr, 2009) published their

work on EA literature and a survey on the common

EA practice. One of Aier’s (Aier et al., 2008) ﬁnding

from an empirical survey among EA practitioners is

a list of typical elements of an EA model, which does

include data elements and information ﬂows, but

does not contain capabilities. The same applies to the

majority of EA books, published between 2005 and

2010, e.g. (Bernard, 2005; Engels et al., 2008; Keller,

2006; Niemann, 2008). The authors implicitly or

explicitly address business entities or similar archi-

tecture elements. But they neither include business

capabilities explicitly in the EA model, nor provide

concrete methods for using them. However, there are

a few EA books that address business capabilities.

The book of Ross, Weill and Robertson “Enterprise

Architecture as Strategy” (Ross et al., 2006) is an

exception in this case. They apply business capabil-

ities as an instrument for business and IT planning.

However, the authors seem to presume a common

understanding of business capabilities and thus do

not provide an explicit deﬁnition.

A well recognized standard for EAM, The Open

Group Architecture Framework (TOGAF) (The Open

Group, 2009) comprises a method for planning, en-

gineering, and delivery of strategic business capabil-

ities to the enterprise (”capability-based planning”).

Business capabilities in TOGAF consist of three di-

mensions: people (training and professional develop-

ment), process (concepts, business processes, infor-

mation management), and material (infrastructure, in-

formation technology, equipment) (The Open Group,

2009). Furthermore, TOGAF differentiates between

horizontal and vertical capabilities. Additionally, it

introduces the concept of capability increments to

structure the advancement of capabilities by planning

and measuring the development of the single dimen-

sions with key performance indicators (KPI). From

an information perspective, TOGAF differentiates be-

tween logical and physical data assets as well as data

management resources. Nevertheless, information is

not explicitly represented in the business architecture,

but part of the information systems architecture.

A METHOD FOR BUSINESS CAPABILITY DEPENDENCY ANALYSIS

A few authors released dedicated publications for

the topic of business capabilities. Barroero, Motta

and Pignatelli (Barroero et al., 2010) state, that the

“current TOGAF version recognizes the business

component requirements but misses how to bridge

those requirements with a data, application and tech-

nology architecture”. The authors propose an exten-

sion to TOGAF to link business changes to data, ap-

plication and technology architecture. Brits, Botha

and Herselman (Brits et al., 2007) introduce a con-

ceptual framework for business capability modeling

consisting of a matrix for analysis and feedback loops

for development. Their work includes a listing of def-

initions for different types of capabilities and a com-

pilation of relevant approaches from strategic think-

ing, innovation to operations and information mod-

eling discipline. Furthermore, Keller (Keller, 2009)

explains the basic idea of capability-based modeling

and provides a set of examples for the use of capa-

bilities in EAM. Klinkm

uller et al.(Klinkm

uller et al.,

2010) identify a need for visualization of business ca-

pabilities in the context of business analysis. They

introduce a three-dimensional visualization which il-

lustrates vertical (logical composition) and horizontal

(dependencies) relations between business capabili-

ties. K

onig et al. (K

onig et al., 2005) in turn introduce

a novel concept for modeling and analysis of business

processes, called ”capability map”. It has been de-

veloped on the basis of resource-based Theory (RBT)

and competence-based Theory (CBT). The practical

applicability and potential beneﬁts are illustrated in

their paper with an example from the banking indus-

try. In the German EA community,

several additional

publications are available by academics, consultants,

and practitioners (e.g. (Berneaud, 2009; Freitag and

Helbig, 2009)), which address different ﬁelds of ap-

plication for business capabilities. Additional related

literature can be found in the following research do-

mains: service-oriented enterprise (Cherbakov et al.,

2005), service-oriented architectures (often referring

to technical capabilities and web services) (Homann,

2006), business component modeling (often referring

to application component development) (McDavid,

1999), as well as commercial publications describing

consultancy services offerings or EA tool capabilities

(BOC-Group, 2009; Bredemeyer et al., 2003).

Regarding the concept of business entities, we per-

formed a search for the terms ”information architec-

ture”, ”business entities”, ”business information”, and

”business data”. Evernden and Evernden (Evernden

and Evernden, 2003) give a comprehensive overview

on information architecture and its development over

German translation for capability:

“Gesch

aftsf

ahigkeit”

time. While the ﬁrst generation in the 1980s fo-

cused on developing standalone applications, the sec-

ond generation around the 1990s applied these ideas

at an enterprise level across multiple applications.

The current, third generation, focuses on business in-

formation rather than technology. Additionally, the

authors motivate the need for structuring informa-

tion by means of a map and the need for a business-

oriented language to describe the relevant entities.

Several publications on business process modeling

(BPM) and information systems modeling (ISM) mo-

tivate the need to take an informational perspective

into consideration (Giaglis, 2001; White, 2004). The

modeled elements itself either refer to systems archi-

tecture or represent granular entities that are used for

business process analysis. The same applies for ana-

lyzed literature on information architecture is related

to data structures in a system (e.g. information group-

ing and applied terminology) (Barker, 2005) or the

interaction between system and user (Toms, 2002).

Matthes et al. have developed an EA model con-

sisting of horizontal architecture layers and vertical

cross-cutting aspects (Lankes et al., 2005; Matthes

et al., 2008), which has recently been enhanced with

abstraction layers (Buckl et al., 2011). Cross-cutting

aspects cover concepts that are not directly part of

the EA structure itself but may be linked to any ele-

ment in a layer in different ways (e.g. linking goals or

KPIs, a linkage subjecting EA concepts to standard-

ization, or deﬁning a project scope). Architectural

layers comprise the company’s EA structure, rang-

ing from business & organization level, over applica-

tion & information level to infrastructure & data level.

Abstraction layers complement the architectural lay-

ers by describing the EA concepts on the correspond-

ing architectural layer on a logical level. Hence, they

focus on the functionalities provided, whereas details

of the actual realization of the functionalities are hid-

den. Figure 1 shows the latest version of the model

with business capabilities. A recognized EA model

is also included in TOGAF (”TOGAF Content Meta-

EA Model

Business Capabilities

& Projects

& Standards

Infrastructure & Data

Infrastructure Services

Application & Information

Business Services

Business & Organization

Strategies

& Projects

Principles

& Standards

Questions & KPIs

Visions & Goals

Figure 1: EA Model (following (Buckl et al., 2011)).

INNOV 2011 - Second International Conference on Innovative Developments in ICT

model”) and also contains capabilities and business

entities (The Open Group, 2009).

3.2 Deﬁnitions

A business capability is an element of the business

architecture layer (Barroero et al., 2010). Based on

the analyzed literature, a business capability can be

deﬁned as a functional building block of the business

which supports the business models and the business

strategy, i.e. it deﬁnes the organization’s capacity to

successfully perform a unique business activity. A

business capability fulﬁlls the following characteris-

tics:

• stability: independent from the organizational

model, technologies, and vendor solutions

• horizontal structure: complete and non overlap-

ping decomposition of the enterprise

• vertical hierarchy: can be broken down into more

granular capabilities

• encapsulate and abstract from resources

Business capabilities should be deﬁned at least by

a unique and comprehensive name and a descrip-

tion. Example instances of business capabilities are

“customer contract management”, “campaign man-

agement”, or “inquiry handling”.

A business entity streamlines the information nec-

essary to deliver the business capabilities. Thus they

have to be comprehensive for business stakeholders

and should be deﬁned in a business language. At

the same time they need to be rigorous enough to

be used as a requirement basis for development of

concrete data models, e.g. for a speciﬁc application.

Consequently, they should be considered as a part of

the business architecture since they reﬂect the busi-

ness point of view on the information and are asso-

ciated with business capabilities which are a part of

this layer too. Currently, comparable architecture el-

ements are often modeled as an element of lower ar-

chitecture layers (see exemplary sebis EA model, ﬁg-

ure 1).

Available literature sources do not include a deﬁ-

nition of the business entities in the sense considered

here. Therefore, we derive a deﬁnition and their char-

acteristics from the deﬁnition of business capabilities:

• stability: independent from the organizational

model, technologies, and vendor solutions

• horizontal view: complete and non-overlapping

representation of the business information needs

of the enterprise necessary to realize a given busi-

ness model

• vertical view: can be broken down into more gran-

ular entities

• encapsulate and abstract from resources

In order to capture the sense of a business entity it is

obligatory to formulate its name and description. Ex-

amples of business entities are ”‘customer”’, ”‘con-

tract”’, or ”‘incident”’.

3.3 Viewpoints

A popular architecture viewpoint for visualization

of business capabilities is a business capability

map (Keller, 2009; Klinkm

uller et al., 2010; K

onig

et al., 2005; Weber and Schmidtmann, 2008). It is

a visual representation of the main functions in the

enterprise which are necessary to support the com-

pany’s business model and which reﬂect the com-

pany’s strategic direction. Usually, a business capa-

bility map is illustrated as a set of capabilities which

can be gradually detailed forming hierarchies. Figure

2 shows an exemplary capability map.

Capability Map: Viewpoint

Capability C Capability D

Capability

Capability A

Capability

Capability B

Capability

Capability E

Capability

Symbols

Visualization Rules

Capability

Capability on level 1

with name „Capability

A“

Capability

Legend

Capability on level 2

with name „Capability

A1“

Capability A

Capability

“Capability A” (level 1)

contains

„Capability A1“ (level 2)

Figure 2: Capability Map.

Barroero at al. (Barroero et al., 2010) analyzed

a few approaches in search for a method to link

and visualize the business capabilities and extracted

among other approaches the enhanced Telecom Ap-

plication Map (eTOM) which decomposes the enter-

prise into generic business processes representing the

main functions down to level ﬁve. The authors point

out that such a representation can be applied e.g. to

deﬁne the functional scope to deliver a given ser-

vice to the customer and therefore it may be used as

A METHOD FOR BUSINESS CAPABILITY DEPENDENCY ANALYSIS

a comprehensive requirements model for the service

design.

4 CONTRIBUTION

4.1 Overview

The goal of the presented method is the identiﬁcation

and analysis of dependencies of business capabilities.

Figure 3 gives an overview on the method consisting

of three phases, which are described in this section.

The gray boxes indicate the architecture viewpoints

used in phase one and two and the use of the EA

model in phase three.

Dependency Analysis

Capability /

Business Entity

Dependency

Analysis

Drill Down

Scoping

Capability

Scoping

Business Entity

Scoping

1 2 3

Capability /

Business Entity

Dependency

Analysis

Drill Down

Scoping

Capability

Map

Business Entity

Map

Dependency

Viewpoint

Enterprise

Architecture

Model

1 2 3

Figure 3: Capability Dependency Analysis Method.

4.2 Dependency Analysis

4.2.1 Phase 1: Scoping on Business Architecture

Level

The goal of the ﬁrst phase is scoping of a given prob-

lem statement using the business capability map and

business entity map. The necessary input to this step

is a deﬁnition of the problem which is supposed to

be analyzed using the capabilities dependency analy-

sis method. Furthermore, the documented respective

maps - as a common understanding of the business

model and the necessary information - are compul-

sory in order to conduct this investigation.

A business entity map has not been considered in

available publications so far. In analogy to the busi-

ness capability map, a business entity map visualizes

the information necessary to deliver the business ca-

pabilities. A basic business entity map comprises a set

of business entities which gradually detail one another

forming hierarchies. Figure 4 shows the architecture

viewpoint business entity map.

As a ﬁrst step, the scope of the considered prob-

lem is projected on the business capability map. In the

next step, a similar activity is conducted with respect

to the business entity map. Dependent on the consid-

ered problem statement, the order of these two steps

may differ. In cases which are strongly data centric,

Business Entity D Business Entity E

Business Entity C

Business Entity

Business Entity A Business Entity B

Business Entity

Business Entity Map: Viewpoint

Business Entity

Symbols

Visualization Rules

Business

Entity A1

Business Entity on

level 1 with name

„Business Entity A“

Business

Entity A

Legend

Business Entity on

level 2 with name

„Business Entity A1“

Business

Entity A

Business

Entity A1

“Business Entity A”

(level 1) contains

„Business Entity A1“

(level 2)

Figure 4: Business Entity Map.

it may be more comfortable to start with the business

entity map analysis since the stakeholders can then

usually deﬁne the relevant information more easily as

supposed to work with the functional view directly.

On the other hand, in the process management envi-

ronment, starting with the functional scoping will be

more beneﬁcial. Dependent on the required level of

detail of the considered problem, scoping by drilling

down different levels of capabilities or business enti-

ties may be required. The steps referred here are thus

to be performed iteratively leading to development of

a complete view on the referred problem. Finally, the

results of the problem scoping based on the both maps

need to be documented, for example in form of a so

called ”heat map” pointing out relevant business ca-

pabilities and business entities by color coding (Buckl

et al., 2011). The results of this phase are both or one

of the maps on the relevant level of detail with the

problem scoping marked as a ”heat map”.

4.2.2 Phase 2: Dependencies on Business

Architecture Level

The subsequent phase aims to reﬁne the scope

deﬁnition by identiﬁcation of dependent business

capabilities based on the known assignment of the

business entities. The analysis of dependencies in

this phase can be considered twofold:

• in terms of relationships of business capabilities to

the business entities, e.g. to answer the question

which information is necessary to be provided /

exchanged to/by the business capability

• in terms of relationships between business capa-

bilities.

INNOV 2011 - Second International Conference on Innovative Developments in ICT

For each of the above cases, an information own-

ership map is an indispensable input. The information

ownership map is a viewpoint which visualizes the as-

signment of business entities to business capabilities

based on the ownership principle. The assignment of

information ownership deﬁnes formal accountability

for a business entity, which implies a number of rights

and responsibilities (Dama International, 2009; Data

Governance Institute, 2010). Besides others, these in-

clude assurance of availability and quality of informa-

tion, as well as provision of information to its users

while guaranteeing appropriate use, as well as adher-

ence to security and compliance demands. The infor-

mation ownership map informs if a given business en-

tity is owned by a business capability, i.e. it is owned

by it or of the business entity is only used by the ca-

pability but owned by a different business capability.

Figure 5 shows the architecture viewpoint.

Information Ownership Map: Viewpoint

Capability C Capability D

Business Entity

Capability A

Business Entity

Capability B

Business Entity

Capability E

Business Entity

Symbols

Visualization Rules

Business

Entity A

Capability with name

„Capability A“

Capability

Legend

Business Entity with

name „Business Entity

A“

Capability A

Business

Entity A

“Capability A”

is owner of

„Business Entity A“

Capability A

Business

Entity A

“Capability A”

uses

„Business Entity A“

Figure 5: Information Ownership Map.

In order to develop a complete picture of the de-

pendencies of the considered business capabilities,

one can proceed as follows. First, the business entities

which are used by the business capability are consid-

ered in search of those which own them. The depen-

dencies discovered in this way inform about sources

of information used in the given business capabil-

ity. In the second step the business entities which are

owned by the given business capability are the sub-

ject of analysis. Learning about the relations of these

business entities to other business capabilities (which

have them assigned as used) is signiﬁcant information

on the destination in which the information needs to

be delivered. Conducting these steps iteratively will

lead to a gradual enrichment of the preliminarily per-

formed scoping. In the last step, it needs to be docu-

mented on the available maps. An output if this phase

is therefore a reﬁned problem scoping based on the

business capability map and business entity map.

4.2.3 Phase 3: Dependencies across Enterprise

Architecture Layers

In the last phase the scope of the problem is ﬁnally

reﬁned by identiﬁcation of relevant architecture ele-

ments from other layers of the EA model. Conse-

quently, the EA model with relations between the con-

tained architecture elements (for instance in the sense

of an architecture repository) is a required input here

The ﬁrst step in this phase relies in analysis of busi-

ness capabilities along of the EA model, i.e. across

various architecture layers relevant for the considered

problem. In the course of this extensive analysis some

gaps in the availability of quality of the available in-

formation about architecture elements may be discov-

ered. In this case, a further optional step, may take

place which aims at identiﬁcation of the necessary ad-

ditional data to be collected. This top-down depen-

dency analysis may be followed by a bottom-up iden-

tiﬁcation of further dependencies which complete the

scope deﬁnition. Finally, the documentation produced

until now - business capability map and business en-

tity map with dependencies to each other and to other

architecture elements - is updated and represents the

result of the third phase.

4.3 Case Study

The business capability dependency analysis ap-

proach presented in this paper was applied in a multi-

national telecommunication company. Due to dynam-

ics and saturation of the telecommunication market,

the pressure to offer convergent products, i.e. ﬁxed

line telephone, mobile, and internet has increased in

the last years. In order to be able to address this trend

and to optimally fulﬁll the customers’ needs the con-

sidered company decided to merge two main strategic

business units - ﬁxed and mobile business units - and

establish a better understanding between the business

and IT. A signiﬁcant imperative in order to enable a

common product offering was development of com-

mon language for the merged companies.

Consequently, it was decided to develop a capa-

bility map which reﬂected the consolidated business

We assume the availability of the information about el-

ements of the EA model, including their interrelations

A METHOD FOR BUSINESS CAPABILITY DEPENDENCY ANALYSIS

model and the strategic direction of the merged busi-

ness units - to ensure delivery of convergent products

and services (e.g. one bill for all products). This

merger - with a particular customer-focus - implied

a challenge in the area of management of customer

data. It was necessary to ensure data harmonization

and a common understanding of the main business

objects like customer, contract or product as a founda-

tion for a successful integration. These premises re-

sulted in a common framework including a business

capability map, a business entity map and an infor-

mation ownership map which delivered a functional

and data view on the enterprise and were later a ba-

sis for development of a common CRM system which

enabled offering of convergent products by both busi-

ness units.

The method described in this paper was applied

to deﬁne the scope of the target CRM system and

its possible impact on the overall architecture. The

mentioned viewpoints were used to deﬁne the scope

of this system. In the ﬁrst phase, the business capa-

bilities were considered which were supposed to be

provided by the target CRM system. It should be no-

ticed that using business capabilities as opposed to IT

functions (in the sense of functionalities of applica-

tions) to create a target architecture vision is a very

innovative approach, which has not been applied in

this company by then. Since the customer data plays

a key role in the CRM area, also the main business

entities were identiﬁed which were supposed to be

relevant in this context. This scoping of the relevant

business capabilities and business entities was docu-

mented as a heat map showing the scope of the tar-

get CRM system. This heat map turned out to be

a very successful project-overarching communication

instrument and a very appropriate scope illustration

which proved much understood by the business which

often accelerated agreement.

In the considered context it was crucial not only

to deﬁne the scope of the core CRM system, but fore-

most to reliably identify its dependencies to other sys-

tems (in the sense of dependencies of the business ca-

pabilities in the area of CRM to other business ca-

pabilities). The clarity about these relationships was

seen as an essential element of the requirements deﬁ-

nition in particular in the architecture transition phase

when parts the current CRM systems in each busi-

ness units were to be shut-down and replaced by the

new CRM. A novel approach to analyze dependencies

based on the information ownership map was applied.

For each of the business capabilities on level two and

three which were declared in scope in the ﬁrst phase,

the used and then owned business entities were exam-

ined. This analysis resulted in extension of the scope

deﬁnition by deﬁnition of dependencies to some busi-

ness capabilities in the area of billing, product lifecy-

cle management, and service management. The heat

map was reﬁned by marking of business capabilities

and business entities which have relations to the ini-

tially deﬁned core business capabilities and business

entities.

The goal of the last phase was to deﬁne the depen-

dencies to other elements of the EA model which was

well documented on the meta model level. Since there

was no information about the complete EA model

available, it was decided to capture the necessary in-

formation, however only within the scope deﬁned so

far. As a result, the process landscape, as well as ap-

plications and standard platforms were documented

which were supposed to be impacted by the devel-

oped CRM system. These ﬁndings were integrated

in the scope deﬁnition and extended the created heat

map in the top-down direction.

The approach applied in this project proved to be

very successful and was recognized as very innova-

tive. For the ﬁrst time the business capability map

and business entities map and foremost the knowledge

about the dependencies between then was applied in

the context of development of the target system. The

knowledge about dependencies allowed conducting a

reliable analysis of the interfaces of the target system

to other systems but as well deﬁning the impact of the

implementation of this system on the business pro-

cesses and the infrastructure. Finally, the architecture

viewpoints used within the projects for the scope deﬁ-

nition were very well perceived by the involved stake-

holder both from the business and IT and they estab-

lished a strong foundation for the subsequent CRM

system design phase.

5 CONCLUSIONS

In this paper, we presented a method for analyzing

business capability dependencies. Business capabil-

ities are a core element of the business architecture

with high relevance for communication between busi-

ness and IT. Additionally, they are applied in the ma-

jority of EAM use cases, such as architecture descrip-

tion, architecture analysis, or decision making in the

sourcing context. Business capabilities are especially

relevant to support strategic planning and innovation.

The establishment of new business capabilities which

contribute to growth implies a necessity to integrate

them seamlessly into the existing landscape. The lat-

ter implies the availability of knowledge about the de-

pendencies of the business capabilities to one another

as well as to other elements of the enterprise architec-

INNOV 2011 - Second International Conference on Innovative Developments in ICT

ture.

The developed method builds on existing re-

sources available in the literature and regularly ap-

plied in practice: the EA model and the business ca-

pability map viewpoint. On this basis, the authors de-

rived a business entity map illustrating the informa-

tion necessary for the business capabilities as well as

the information ownership map illustrating the depen-

dencies between the functional and the data view and

being the basis for the method introduced here.

As a foundation for the developed artifact, we per-

formed a profound literature analysis and provided a

short overview on existing EA-related business capa-

bility and business entity resources. Following a de-

sign science approach, we examined the developed

artifact in practice. It has been successfully applied

in the real-world business environment and lessons

learned have been integrated to reﬁne method and

architecture viewpoints. The resulting three-phase

method to identify the dependencies of business capa-

bilities was illustrated by a case study from a telecom-

munication industry.

This paper is of course subject to some limita-

tions. The developed method was validated in three

companies and one of these cases was described here.

There is surely a potential to illustrate further cases of

application of the method developed here extending

the list of possible scenarios and contributing to spe-

ciﬁc extensions and variations. Interestingly enough

would be to show which limitations this method may

have if applied for small and medium-sized compa-

nies and if it is applicable at all. Some practitioners

may certainly be interested in the details of applica-

tion of the described method in the mentioned com-

panies - the generalized method description provided

here may not be sufﬁcient for those who want to apply

it in practice. Last but not least, we assumed the avail-

ability of certain artifacts in the enterprise while will-

ing to apply the presented dependency method. This

may not reﬂect the reality in many companies - there

may be support needed - e.g. in form of guidelines -

to fulﬁll the requirements to apply this method. They

are: development of the business capability map and

its anchoring in the EA model in terms of the depen-

dencies to other architecture elements. Finally, the de-

pendency analysis method requires further evaluation

and justiﬁcation in order to prove its general applica-

bility and relevance.

Next to addressing the possible limitations of this

paper elaborated on above, there are further research

potentials which may be derived from this paper. One

of our ideas refers to the issue of the tool support for

the analysis described here. Obviously, multiple busi-

ness capabilities and business entities may result in

hundreds of relationships. Their analysis may be very

exhaustive if performed without support of any soft-

ware. It would be interesting to examine the exist-

ing tools (not only in the area of EAM) to ﬁnd out to

which extend are they able to support this method and

subsequently to deﬁne the elements of the tool meta

model, functionalities, views and workﬂows which

are required by this approach and which would be ac-

cepted by the business and IT.

Since the method to identify dependencies of busi-

ness capabilities is based here on business entities, it

would be interesting to make a study on further EA

elements which may be used in the dependency anal-

ysis of business capabilities like products, processes

or technology elements and in the same time deﬁning

the cases in which these methods may be preferred.

Referring to use cases - also mentioned in the previ-

ous paragraph, it would be ﬁnally attention-catching

to deﬁne the method extensions applicable for the de-

ﬁned set of use cases, e.g. acquisition of a business

capability, out-souring, or pattern-based strategy.

REFERENCES

Aier, S., Riege, C., and Winter, R. (2008). Unternehmen-

sarchitektur - Literatur

uberblick und Stand der Praxis.

Wirtschaftsinformatik, 50(4):292–304.

Barker, I. (2005). What is information architecture? KM

Column, (April).

Barroero, T., Motta, G., and Pignatelli, G. (2010). Business

Capabilities Centric Enterprise Architecture, volume

326, pages 32–43. Springer, Boston, USA.

Bernard, S. A. (2005). An Introduction to Enterprise Archi-

tecture. AuthorHouse, Bloomington, USA, 2nd edi-

tion.

Berneaud, M. (2009). Der Unterschied liegt in der IT. GI-

Geldinstitute, page 3.

BOC-Group (2009). Business Capability Management.

Bredemeyer, D., Malan, R., Krishnan, R., and Lafrenz, A.

(2003). Enterprise Architecture as Business Capabili-

ties Architecture.

Brits, J.-P., Botha, G., and Herselman, M. (2007). Concep-

tual Framework for Modeling Business Capabilities.

In Proceedings of the 2007 Informing Science and IT

Education Joint Conference, pages 151–170.

Buckl, S., Matthes, F., and Schweda, C. M. (2011). Infor-

mation model building blocks.

Cherbakov, L., Galambos, G., Harishankar, R., Kalyana,

S., and Rackham, G. (2005). Impact of service ori-

entation at the business level. IBM Systems Journal,

44(4):653–668.

Cullen, A., Orlov, L. M., Radjou, N., Hoppermann, J.,

Peyret, H., and Sessions, L. (2006). Enterprise Ar-

chitecture’s Role In IT-Enabled Business Innovation.

A METHOD FOR BUSINESS CAPABILITY DEPENDENCY ANALYSIS

Dama International (2009). The DAMA Guide to The Data

Management Body of Knowledge. Technics Publica-

tions, Bradley Beach, USA, 1st edition.

Data Governance Institute (2010). Assigning Data Owner-

ship.

Engels, G., Hess, A., Humm, B., Juwig, O., Lohmann,

M., Richter, J.-P., Voß, M., and Willkomm, J. (2008).

Quasar Enterprise: Anwendungslandschaften ser-

viceorientiert gestalten. Dpunkt Verlag, Heidelberg,

Germany, 1st edition.

Evernden, R. and Evernden, E. (2003). Third Generation In-

formation Architecture. Communication of the ACM,

46(3):95–98.

Freitag, A. and Helbig, R. (2009). Finanzpla-

nung und steuerung von Unternehmensarchitekturen.

Controlling-Portal.

Giaglis, G. M. (2001). A taxonomy of business process

modeling and information systems modeling tech ...

International Journal of Flexible Manufacturing Sys-

tems, 13(2):209–228.

Hevner, A. R., March, S. T., Park, J., and Ram, S. (2004).

Design Science in Information Systems Research.

MIS Quarterly, 28(1):75–105.

Homann, U. (2006). A Business-Oriented Foundation for

Service Orientation.

International Organization For Standardization (2007).

ISO/IEC 42010:2007 Systems and software engineer-

ing - Recommended practice for architectural descrip-

tion of software-intensive systems.

Keller, W. (2006). IT-Unternehmensarchitektur. Von der

Gesch

aftsstrategie zur optimalen IT-Unterst

utzung.

Dpunkt Verlag, Heidelberg, Germany, 1st edition.

Keller, W. (2009). Using Capabilities in Enterprise Archi-

tecture Management.

Klinkm

uller, C., Ludwig, A., Franczyk, B., and Kluge, R.

(2010). Visualising Business Capabilities in the Con-

text of Business Analysis, volume 47, pages 242–253.

Springer, Berlin/Heidelberg, Germany.

onig, W., Beimborn, D., Martin, S. F., and Homann,

U. (2005). Capability Map : Eine alterna-

tive Darstellungsweise f

ur Unternehmensprozesse aus

ressourcenorientierter Sicht. SCS-European Publish-

ing House.

Lankes, J., Matthes, F., and Wittenburg, A. (2005). Soft-

warekartographie als Beitrag zum Architekturman-

agement, pages 305–330. GITO-Verlag.

March, S. T. and Smith, G. F. (1995). Design and natural

science research on information technology. Decision

Support Systems, 15:251–266.

Matthes, F., Buckl, S., Leitel, J., and Schweda, C. M.

(2008). Enterprise Architecture Management Tool

Survey 2008. Chair for Informatics 19 (sebis), Tech-

nische Universit

at M

unchen, M

unchen, Germany.

McDavid, D. W. (1999). A standard for business architec-

ture description. IBM Systems Journal, 38(1):12–31.

Niemann, K. D. (2008). From Enterprise Architecture to IT

Governance: Elements of Effective IT Management.

Vieweg Verlag, Wiesbaden, Germany, 1st edition.

Ross, J. W., Weill, P., and Roberts, D. C. (2006). Enter-

prise Architecture as Strategy: Creating a Foundation

for Business Execution. Mcgraw-Hill Professional, 1st

edition.

Sch

oenherr, M. (2009). Towards a Common Terminology in

the Discipline of Enterprise Architecture, pages 400–

413. Lecture Notes in Computer Science. Springer,

Berlin, Heidelberg, Germany.

Scott, J., Cullen, A., and An, M. (2010). The Anatomy Of

A Capability Map.

The Open Group (2009). TOGAF ”Enterprise Edition” Ver-

sion 9.

Toms, E. G. (2002). Information interaction: Providing a

framework for information architecture. Journal of the

American Society for Information Science and Tech-

nology, 53(10):855–862.

Weber, U. and Schmidtmann, V. (2008). Differentiate. Der

neue strategische Imperativ f

ur den CIO.

Webster, J. and Watson, R. T. (2002). Analyzing the Past to

Prepare for the Future: Writing a Literature Review.

MIS Quarterly, 26(2):xiii—-xxiii.

White, S. A. (2004). Introduction to BPMN. BP Trends.

INNOV 2011 - Second International Conference on Innovative Developments in ICT