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
Enterprise architecture management, Business capabilities, Business entities, Dependency analysis.
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 reflected in a growing number of
publications on definition, 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.
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-
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, identification 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;
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).
In Proceedings of the Second International Conference on Innovative Developments in ICT, pages 11-20
DOI: 10.5220/0004471100110020
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 defined 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 reflected 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
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 fields of research.
The authors followed a design science approach
in order to contribute to the identified area of re-
search through the building and evaluation of inno-
vative artifacts designed to meet identified 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 findings from a pro-
found literature study as well as practitioner’s ex-
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-
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 first refinement 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 first 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 findings pre-
sented in this paper is given in the following section.
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 findings is presented. The
related literature is structured as follows
Enterprise Architecture Management (books and
Concept of business capabilities, definitions, and
Concept of business entities, definitions, and vi-
EA model: Relation of business capabilities and
business entities
In 2008, Aier (Aier et al., 2008) and
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) finding
from an empirical survey among EA practitioners is
a list of typical elements of an EA model, which does
include data elements and information flows, 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 definition.
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 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 benefits 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 fields 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:
time. While the first 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 defining 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
& Projects
& 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 Definitions
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
defined as a functional building block of the business
which supports the business models and the business
strategy, i.e. it defines the organization’s capacity to
successfully perform a unique business activity. A
business capability fulfills the following characteris-
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 defined 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 defined 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 specific application.
Consequently, they should be considered as a part of
the business architecture since they reflect 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, fig-
ure 1).
Available literature sources do not include a defi-
nition of the business entities in the sense considered
here. Therefore, we derive a definition and their char-
acteristics from the definition 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
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 reflect 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 A
Capability B
Capability E
Visualization Rules
Capability on level 1
with name „Capability
Capability on level 2
with name „Capability
Capability A
“Capability A” (level 1)
„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 five. The authors point
out that such a representation can be applied e.g. to
define the functional scope to deliver a given ser-
vice to the customer and therefore it may be used as
a comprehensive requirements model for the service
4.1 Overview
The goal of the presented method is the identification
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
Drill Down
Business Entity
1 2 3
Capability /
Business Entity
Drill Down
Business Entity
1 2 3
Figure 3: Capability Dependency Analysis Method.
4.2 Dependency Analysis
4.2.1 Phase 1: Scoping on Business Architecture
The goal of the first 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 definition 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 first 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
Business Entity A Business Entity B
Business Entity
Business Entity
Business Entity
Business Entity
Business Entity Map: Viewpoint
Business Entity
Business Entity
Business Entity
Business Entity
Business Entity
Business Entity
Business Entity
Business Entity
Visualization Rules
Entity A1
Business Entity on
level 1 with name
„Business Entity A“
Entity A
Business Entity on
level 2 with name
„Business Entity A1“
Entity A
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 define 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 beneficial. 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 refine the scope
definition by identification 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-
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 defines 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
Business Entity
Business Entity
Business Entity
Business Entity
Capability A
Business Entity
Business Entity
Business Entity
Capability B
Business Entity
Business Entity
Capability E
Business Entity
Business Entity
Business Entity
Visualization Rules
Entity A
Capability with name
„Capability A“
Business Entity with
name „Business Entity
Capability A
Entity A
“Capability A”
is owner of
„Business Entity A“
Capability A
Entity A
“Capability A”
„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 significant 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 refined 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 finally
refined by identification 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 first 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 identification of the necessary ad-
ditional data to be collected. This top-down depen-
dency analysis may be followed by a bottom-up iden-
tification of further dependencies which complete the
scope definition. 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. fixed
line telephone, mobile, and internet has increased in
the last years. In order to be able to address this trend
and to optimally fulfill the customers’ needs the con-
sidered company decided to merge two main strategic
business units - fixed and mobile business units - and
establish a better understanding between the business
and IT. A significant 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 reflected the consolidated business
We assume the availability of the information about el-
ements of the EA model, including their interrelations
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 define the scope of the target CRM system and
its possible impact on the overall architecture. The
mentioned viewpoints were used to define the scope
of this system. In the first 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 identified 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 define 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 defi-
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 first phase,
the used and then owned business entities were exam-
ined. This analysis resulted in extension of the scope
definition by definition of dependencies to some busi-
ness capabilities in the area of billing, product lifecy-
cle management, and service management. The heat
map was refined by marking of business capabilities
and business entities which have relations to the ini-
tially defined core business capabilities and business
The goal of the last phase was to define 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 defined 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 findings were integrated
in the scope definition 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 first 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 defining 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 defi-
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.
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
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 refine 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-
cific 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 sufficient 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 reflect the reality in many companies - there
may be support needed - e.g. in form of guidelines -
to fulfill 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 justification 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 find out to
which extend are they able to support this method and
subsequently to define the elements of the tool meta
model, functionalities, views and workflows 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 defining
the cases in which these methods may be preferred.
Referring to use cases - also mentioned in the previ-
ous paragraph, it would be finally attention-catching
to define the method extensions applicable for the de-
fined set of use cases, e.g. acquisition of a business
capability, out-souring, or pattern-based strategy.
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-
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,
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.
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-
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,
Freitag, A. and Helbig, R. (2009). Finanzpla-
nung und steuerung von Unternehmensarchitekturen.
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
aftsstrategie zur optimalen IT-Unterst
Dpunkt Verlag, Heidelberg, Germany, 1st edition.
Keller, W. (2009). Using Capabilities in Enterprise Archi-
tecture Management.
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
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