A Process Approach for Capability Identification and Management
Matthias Wißotzki
Institute of Business Information Systems, University of Rostock, Albert-Einstein-Straße 22, Rostock, Germany
Keywords: Enterprise Architecture Management, Capability Management, Capability Engineering, Design Science
Research.
Abstract: Enterprises reach their goals by implementing strategies. Successful strategy implementation is affected by
challenges that an enterprise has to face and overcome. Enterprises require specific capabilities in order to
be able to implement strategies in an effective way and achieve desired results. The demand for a systematic
capability management approach is thus growing. This paper introduces a general process for identifying,
improving, and maintaining capabilities in an enterprise. This process is based on an integrated capability
approach that results from a number of investigations performed over the past years. Comprised of four
building blocks, the capability management process represents a flexible engineering approach for
capability catalog developers and designers.
1 INTRODUCTION
Organizations have to be more sensitive towards the
implementation of business strategies and their
consequences on, e.g., processes, customers, and / or
application systems. In fact, while enterprise
structures are becoming increasingly complex,
changes inside such structures have frequently
presented enterprises with challenges over the last
decade. Economic success depends on sound
strategies that support the realization of defined
goals. Therefore, it is not only important to be aware
of existing challenges and problems but also to
continuously gather and assess information about
organizational knowledge, responsibilities, available
resources, and processes required for strategy
implementation (Wißotzki et al., 2013).
Enterprises are equipped with various
capabilities tailored to their situation and setting, but
many are not aware of them. For this purpose, an
integrated capability approach is needed that
supports the identification and description of
capabilities required for an effective
operationalization of enterprise strategies. These
capabilities should then be derived systematically
through a structured process, gathered and managed
in an enterprise-specific repository that we call
“capability catalog.”
This paper provides a description of a generic
capability management process, including a
preparation phase, a capability identification and
refinement phase to define and manage them in a
capability catalog, and an analyzing and
maintenance phase for update purposes by following
the design-science research paradigm.
1.1 Starting from Strategy
In general, strategies could be understood as
impulses for actions to be taken to reach a certain
goal. In the context of an enterprise strategies
supports an organization to achieve defined goals
with the aid of long-term planned behavioral
patterns. However, modern approaches of strategy
formation usually concentrate on the market
positioning of products and services and enabling
operationalization thereof inside a business model
(Simon et al., 2014).
However, there are two fundamental challenges
when it comes to the realization of strategies to
achieve defined goals: (1) The creation of an action
catalog for strategy realization, as well as
performance and liquidity planning, takes place in
the process of strategy formulation. Nonetheless, an
action catalog requires an enterprise to have a
structured view of its capabilities in order to be
effective. (2) Even though a strategy is designed for
long-term efforts, there is the requirement to remain
responsive to any changes in the business
environment.
This flexibility is essential in order to react to
204
Wißotzki M..
A Process Approach for Capability Identification and Management.
DOI: 10.5220/0005339502040212
In Proceedings of the 17th International Conference on Enterprise Information Systems (ICEIS-2015), pages 204-212
ISBN: 978-989-758-098-7
Copyright
c
 2015 SCITEPRESS (Science and Technology Publications, Lda.)

new drivers and constraints such as changed
customer needs, new technologies, or statutory
regulations (Wißotzki et al., 2013). Although this
requirement does not appear to be new, an
immediate ability to evaluate changes and
corresponding consequences is necessary, which
could be supported by a capability management
process (CMP).
1.2 Research Approach
The design-science research (DSR) approach was
applied for research investigation. DSR is a
construction-oriented problem solving paradigm in
which a designer creates innovative artifacts, in our
case the CMP (artifact type: method (March and
Smith 1995), answering questions relevant to human
problems, thereby contributing new knowledge to
the body of scientific evidence (Hevner and
Chatterjee, 2010). As a problem-solving paradigm,
design-science research resembles utility and its
artifacts have to be evaluated. Therefore, our
approach consists of two main stages.
The first stage is the problem investigation
rooted in empirical and conceptual research, e.g.,
conducting systematic literature analysis, surveys,
and expert interviews. We used a project-driven
method- engineering approach that is based on our
experiences in three different research projects: (1)
EACN Project (www.wirtschaftsinformatik-
rostock.de), (2) CaaS Project (http://caas-project.eu),
and (3) The Open Group Capability Improvement
Project (http://www.opengroup.org).
The second stage focused on preliminary
findings combined with the results of a first
executed action research cycle (Wißotzki et al.,
2014); hence, the proposed method called Capability
Management Process (CMP) is a part of a larger
body of a work in progress. The purpose is to
develop an appropriate management process for the
preparation, identification, organization, evaluation,
and maintenance of capabilities in enterprise
environments. It should provide clear guidance and
accommodate established state of the art and best
practices to overcome challenges described in this
chapter.
2 THE INTEGRATED
CAPABILITY APPROACH
As part of the CMP development, we propose an
integrated capability approach that supports the
identification of capabilities required for an effective
operationalization of a strategy. Using this approach,
capabilities should then be easier derived
systematically through a structured process and
gathered in an enterprise-specific catalog.
This approach was motivated by a requirements
catalog based on the demands of mentioned research
projects (cf. section 1.2) working within the
capability context. In order to identify an elementary
capability approach that considers the requirements
and delivers concrete descriptions of capability
elements we used different surveys, expert
interviews and systematic literature analysis whose
findings are summarized in (Wißotzki et al., 2013)
which involves the following capability definition: A
capability represents the ability of an enterprise to
join resources and information in order to support a
strategic goal. This combination is applied in
consideration of the specific context (used for
capability type definition) and executed in a defined
and repeatable activity or process for which certain
roles resp. actors take responsibility in order to
produce a desired outcome.
The definition forms the basis for the
architectural integrated capability approach as
assimilated part of the Business Execution Layer
(Simon et al., 2014).
At the current state we could distinguish three
capability types:
1. Business Capabilities (business context)
2. EAM Capabilities (architectural context)
3. IT Capabilities (IT context)
Basically, these types have different kinds of context
objects, which in turn depends on the area of
application (Bazire and Brézillon, 2005). For
instance, the context of business capabilities
represents a combination of objects of the business
architecture (e.g., product, market, or customer) and
management activities, whereas the EAM
capabilities context is defined as a combination of
architectural objects (e.g., application, information
flow, or component) and management functions
(Wißotzki et al., 2013).
However, referring back to the definition of a
capability it requires an additional set of elements to
be considered: the required information, roles/ actors
with competences to help create a specific outcome,
the relevant activities or processes, and appropriate
resources.
AProcessApproachforCapabilityIdentificationandManagement
205

3 THE CAPABILITY
MANAGEMENT PROCESS
We now return to the following question: What
kinds of capabilities are required for an
organization within a certain area of application in
order to achieve defined goals?
We deal with this question using the concept of a
capability catalog that describes a collection of
capabilities necessary to support the implementation
of an organization’s strategy. The subsequent
process is applied to support the identification and
creation of a capability catalog. This section offers a
description of our Capability Management Process.
The CMP consists of four building blocks (BBs),
each focusing on distinct contents and having
distinct outputs.
In short, the first building block sets preparation
conditions like problem, scope, and stakeholder
definition. The second building block designs the
capability catalog structure, whereas the third block
develops the detailed capability content. The
analysis and maintenance building block covers
catalog evaluation and maintenance issues (see
Figure 2). The following sections provide more
detailed explanations of each phase and sub-steps
involved in these phases.
3.1 Preparation (BB1)
The first building block defines conditions for the
capability catalog to be created and forms the outer
frame of the catalog. Therefore, the first building
block (BB1) will be divided into the four steps: (1)
Scope & Application Area; (2) Terms & Concept
Identification; (3) Capability Context Definition; (4)
Development Strategy Definition.
In the first step, called “(1) scope & application
area,” stakeholders and the focus of the required
capability model are clarified. The involved parties
have to agree on the application area and the goals
of the capability catalog that is to be created.
Accordingly, several questions are relevant here,
e.g.: What kind of support do stakeholders expect
from a capability catalog? Does the catalog cover
domain- or context-specific questions or is it used
for more general purposes? Who is involved in the
development of the catalog (e.g., managers, domain
experts, etc.)?
The understanding of the capability concept may
vary among the relevant stakeholders. Therefore, the
step “(2) terms & concepts identification” will
identify terms and common perspectives to define a
consistent capability concept. Starting with a general
example of the capability approach is intended to
create a common understanding of the perspective at
hand. Nevertheless, obtaining an overview of
already existing definitions and concepts in the area
of capabilities during preliminary stages is advisable
in order to either use or extend present standards.
Questions like: Are there existing capability
approaches, projects, catalogs, or maps in the
enterprise? How is the concept of capabilities
applied? should be answered here. Results of this
particular stage have to be documented and made
available for the involved stakeholders. At this point,
the global requirements of the capability catalog
development are defined, and the existing concepts
are compared and enhanced by missing components.
In the next step, the “(3) capability context
definition” activity is carried out. According to
(Abowd et al., 1999), a context describes any
information that can be used to characterize the
situation of an entity. As already depicted, the
integrated capability approach section is premised
not on an entity but on object-based concepts of the
enterprise architecture, i.e., descriptive elements
such as roles, information, or resources. Therefore,
the context of capabilities is broken down into
architectural levels. Referring to (Buckl et al., 2010),
capabilities have either a direct or indirect
relationship to (other) architectural objects. The
introduced descriptive elements are assigned to a
capability within this step in order to determine the
actual type (see Figure 1). Despite the analyses of
scope and application area, attention should be paid
to the fact that, for instance, the context objects for
business capabilities could depend on industry-
specific aspects, since business capabilities are able
to enhance both competitive advantages and core
competences due to their uniqueness, inimitability,
and contribution to the generation of better customer
value (Gartner, 2013). In this context, certain objects
or functions such as business objects or management
functions are defined as context objects, since an
interaction of these creates customer value.
Figure 1: Example for a Business Capability Definition
(Jigsaw Cube Image by Corso Ltd.).
ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems
206

Hence, this leads us to the “(4) development
strategy definition” stage. Here, two different
approaches can be distinguished: a new catalog is
developed or an already existing catalog is extended.
During the development of strategies, obtaining
management approval and support is necessary. In
addition, all relevant organizational units and
employees have to get access to required
information and documents. In fact, informing
relevant stakeholders about, e.g., the upcoming
activities and the corresponding timeframe is
essential in order to obtain the required support. The
relevance of the overall project to the enterprise, the
purpose of the capability catalog, a time schedule,
planned activities, the involved parties, a common
understanding of how capabilities will be applied.
The main objective here is to create openness among
the involved parties or, say, stakeholders to
upcoming analyses in order to have a positive
influence on both quality and correctness of the
identified capabilities. The need for personnel and
monetary resources required in the context of a
capability development project may have to be
justified during the step of BB1.
The quality of a developed capability catalog
depends on precise scoping and whether compliance
with guidelines for quality management is achieved.
These guidelines represent another important
component of this phase, as they contribute to
quality improvement of the development process
and allow an evaluation of the achievement of
objectives.
3.2 Catalog Design (BB2)
Subsequent to the determination of content within
the preparation stage, the design of the capability
catalog is initiated. Hence, capability candidates are
identified, collected, structured, and their
dependencies are defined: (1) Capability Candidate
Identification; (2) Structuring and Combining; (3)
Relationships Identification.
The phase starts off with the “(1) capability
candidate identification.” The focus of this activity
is the definition of the first capabilities. Prior to any
analyses, it is important to accurately define the area
of application and coordinate the required work (see
BB1). The area of application determines the content
and concepts being significant for the identification
process.
Therefore, the output of BB1 provides the basis
for the planning of required identification activities,
involved experts, and the effort estimation. For the
actual identification process, there are several
possibilities that have been successfully used in
other fields such as enterprise modeling. Here we
summarized different methods we used for analysis
with respect to their field of application within the
capability candidate identification stage.
CapStorming: The utilization of creativity
techniques such as brainstorming in the course of the
initialization process of a capability catalog is
helpful for the purpose of quickly seizing ideas and
combining these with existing concepts. Survey:
Represents the main technique for gathering
information in the context of descriptive capability
elements. Document Analysis: Is used for either
preparation purposes or as an initial step within the
identification process (e.g., existing strategy maps,
process models, domain architectures). Written
Cases: Are used in addition to surveys to identify the
time and material input necessary to carry out a
certain task. Moderated/ Participative/ Design
Thinking Workshop: Characterizes identification
activities and/ or solution development steps that are
applied in order to achieve consent among the
involved parties.
The initial activities for identifying capabilities
should be kept as short as possible. In general, these
initial activities result in a roughly structured
collection of individual capabilities or at least
capability ideas. The origin of the identification
process is a so-called “capability identification
matrix.” At the X-axis and Y-axis of the matrix, you
find the context objects. For a business capability
“market analysis”, e.g the X-axis contains a context
object called “market” (business object). At the Y-
axis, there are simplified management processes like
“planning”, “execution”, and “controlling”.
Consequently, the matrix cell at the intersection of
the “market” object and an analysis step of the
“planning” phase would then represent the “market
analysis” capability.
After collecting initial capability suggestions, the
results need to be analyzed (with regard to their
context), discussed, and, if necessary, restructured.
Within the step “(2) structuring and combining,”
redundant elements are removed and capabilities
that have a strong coherence as to content are
aggregated or further specified. Within this stage,
content-related aspects are combined to create a
catalog that is both easy and clear to understand. In
case there is a large amount of capabilities, which
could be aggregated or categorized. Accordingly,
similar capabilities are either pooled or integrated
using appropriate decomposition levels. It is
necessary to have this agreed by the involved
stakeholders and document questions and critical
AProcessApproachforCapabilityIdentificationandManagement
207

comments that may occur. Subsequent to the first
refinements of the capability catalog, participants
work on additional iterations with the aid of the
collected questions and critical comments in order to
suggest further changes and enhancements. The
objective of this step is to classify identified
capabilities, create a consistent structure, and fix
capability names and prepare stable descriptions.
Since the collected improvement suggestions
usually may not guarantee a sufficient, complete, or
consistent capability catalog, it is necessary to
conduct further analyses and reorganizations. In
addition to an improved level of detail that is
achieved in BB3, dependencies among capabilities
need to be identified and documented. During the
step “(3) relationships identification,” different
relationships are documented and analyzed. As a
result of identifying missing relationships, removing
inconsistencies, and discovering gaps, there is an
enhancement of both the knowledge represented by
the catalog and the understanding of capabilities
being available within an enterprise. Implicit,
undesired, or overlapping relationships between
capabilities have to be detected and adjusted. The
different relationships between capabilities can be
classified as follows: Informative Relationship:
Which capability depends on information provided
by another? Supportive Relationship: Which
capability is a prerequisite for another? Functional
Relationship: Which capabilities represent different
aspects in the same matrix column? For more
advanced results analysis methods like the “Business
Capability Dependency Analysis Method” (Freitag
et al. 2011) could be executed.
3.3 Develop Details (BB3)
Creating a capability catalog is typically an iterative
process that is completed once every capability is
described in a sufficient level of detail for
supporting the strategy implementation of an
enterprise. Thus, the third building block is
responsible for the refinement of already achieved
results by applying the following steps: (1) Catalog
Content Layer Definition; (2) Capability Content
Engineering; (3) Develop & Test Views.
The initial step of the third building block (BB3),
“(1) catalog content layer definition,” addresses the
definition of the content and associated depth in
order to provide both a final structure and order of
the capability catalog. This step is important in case
the catalog needs to achieve a high level of detail in
the terms of content (e.g., by specifying descriptive
elements and defining evaluation criteria). We used
a three-level approach for the content layer
definition. The capability identification matrix
represents the first level and is used to identify
contextual capabilities. At the second level, i.e. the
capability content, descriptive elements are
specified. Finally, different kinds of evaluation
criteria are developed at the third level.
After specifying the number of content layers
covered by the catalog, a systematic analysis of the
identified capabilities as part of the “(2) capability
content engineering” step is advisable. Here, the
capabilities are actually described in further detail.
According to (Ulrich and Rosen, 2011), the
following list presents a number of basic principles
for the capability content engineering process: (i)
Capabilities define what is done, not how to do
something; (ii) Capabilities are nouns; (iii)
Capabilities are defined in terms of their application
area (i.e., there should be no technical terms for
describing business capabilities); (iv) A capability
should be enduring and stable, not volatile; (v)
Capabilities are not redundant; (vi) There is one
capability map for an application area; (vii)
Capabilities can have relationships to other
capability types.
During the engineering process, the entire
capability catalog appearance may still be subject to
substantial changes. The catalog’s structures are
depicted with the help of models that support a clear
and consistent conception of the catalog. Prior to any
adjustment, a review of previous work is required.
Afterwards, an elaboration or refinement of the
descriptive elements can be carried out. An
elaboration of the “market situation analysis”
capability, for example, would be performed with
respect to the following questions: What information
is required in order to conduct a market situation
analysis? Which roles are able to provide
information and make decisions with respect to this
object? What resources are required to perform a
market situation analysis? How is a market situation
analysis performed and what kind of output is
produced? Are there already predefined activities or
a standard process for market analysis? Are there
any references of already defined capabilities to
logical objects of the enterprise?
The third building block is completed by the “(3)
develop & test views” step. When describing
capabilities in detail, it is necessary to ensure that
every capability is formulated in a general manner,
i.e. there should not be any connection to objects
such as particular applications or markets. However,
capabilities may be well linked to logical elements.
For instance, the connection between strategy, goal,
ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems
208

and corresponding capabilities for its realization
could be captured in a view. In general, views might
be applied to present specific sets of capabilities to
different kinds of stakeholder groups. In particular,
one of the following sample views might be created:
required maturity level vs. current maturity level of a
capability used for strategy implementation, costs of
creating a capability, dependencies between
capabilities, financial aspects (revenue, profit), or a
business capability overview. For presentation
purposes, different tools and technical measures
(multiple video projectors or monitor screens,
special software tools) may be used. This is to name
just a few examples: data and tree maps, radar
charts, parallel coordinates, cone trees, or layer
charts (Lengler and Eppler, 2007).
3.4 Analysis & Maintenance (BB4)
The last building block describes an important,
remaining stage in the context of analyzing and
introducing a capability catalog. In fact, this BB4
addresses the quality- and communication
management issues of a created catalog. The
paragraphs below describe these activities in detail:
(1) Evaluation Concept; (2) Catalog Evaluation &
Analysis; (3) Catalog Deployment &
Communication; (4) Catalog Maintenance.
Even though there are a lot of approaches dealing
with quality criteria and evaluation methods in the
context of, for example, business processes, there is
still little progress in the application area of
evaluating capabilities. Approaches most often build
on ordinary methods for quality control or are
impractical for the designated purpose. This might
have originated from an omitted preparation phase,
which is normally used to describe the quality
criteria a catalog has to satisfy.
The subject of the “(1) evaluation concept” step
can be the development process (the way the catalog
is constructed), the designed result (the catalog
itself), or both, which is necessary to produce rigor
and practical relevant artifacts. Due to practice-
oriented reasons, this section exclusively covers the
evaluation of capability catalogs itself. Accordingly,
the quality level and quality criteria have to be
elaborated during this stage to make measuring
possible. Appropriate criteria can normally be
derived from the goals predefined in the scoping of
the capability catalog. In addition to conducting an
overall review of general quality standards such as
completeness, accuracy, flexibility, linkage,
simplicity, intelligibility, and usability, it is
recommended to apply comprehensive evaluation
tools, e.g., capability maturity models, in case of
large capability catalogs. Maturity models may be
applied in the “(2) catalog evaluation” step. After
such an evaluation, the second building block can be
revisited and the feedback can be used as an input
for further iterations of catalog development.
The way of integrating a catalog into an
enterprise has a vital influence on the success of this
catalog. To this end, the “(3) catalog deployment &
communication” step addresses the implementation
resp. roll-out of a catalog in the organization. The
success of integrating a capability catalog depends
on two major elements: (i) The capability catalog
has a high-quality level; (ii) Stakeholders (e.g. board
level, business developers, line managers) are
satisfied with both the approaches and achieved
results. The completed capability catalog thus needs
to be formally presented to the steering committee
and contracting authority, respectively. This should
be delivered either in the form of an intermediate
presentation or as part of the project completion. It
thus needs to be ensured that the requirements of the
stakeholders are satisfied. To achieve this, accurate
planning and preparation is required. The project
team needs to be able to enhance the results of the
capability catalog creation process, i.e. converting
the final catalog version, descriptions, and
illustrations into an appropriate form of presentation.
Besides, changes in the domain knowledge and
management approaches can create the need for
improvements in the catalog (Lahrmann and Marx,
2010). For these reasons, the maintenance step will
be passed through, which is necessarily an iterative
process. Ensuring the catalog relevance over the
years, this step addresses the evolution of the model.
As an enterprise may have to meet new challenges
and capabilities need to be modified accordingly,
there is an ongoing “(4) catalog maintenance”
process in addition to evaluation methods applied to
create a high-quality capability catalog.
Accordingly, these are the following advantages of
the introduced process step: (i) Structure and
comprehensibility, (ii) Precise descriptions, (iii)
Simplified modifications and reorganizations of the
created catalog, (iv) Contributes to the
organizational learning and securing of
organizational knowledge.
Consequently, an improvement of both, quality
and usage period of the catalog is addressed within
the last step of this building block. Modifications in
the catalog structure as well as slight changes may
occur in this step. from lahrmann and marx 2010, we
adopted three of four extension patterns for the
purpose of catalog maintenance. a general update of
AProcessApproachforCapabilityIdentificationandManagement
209

Figure 2: The Capability Management Process.
capability catalog elements such as by adding new
descriptive elements or updating the evaluation
mechanism (e.g., maturity assessment procedure)
may be examples of the first pattern. it is also
possible to add new context objects or reorder their
configurations, e.g., by changing attributes that
might influence the identification process (section
3.2) or at least reconfigure the relationships between
different capabilities. although these extension
patterns challenge the metastructure of the capability
catalog to some extent, they would not require
passing the first building block and beginning the
development process again by redefining the scope,
as this would go beyond the scope of maintenance.
4 VALIDATION
In line with Duhan et al., 2005, the catalog
verification determines if the artifact represents the
developer´s concept accurately and it tests the model
against a set of theoretic evaluation methods.
Therefore, we proofed to what extend the
presented CMP meets requirements of a method in
context of a method engineering approach. In general
a method represents a prescriptive structure that
explains what to do in different situations and how
certain goals can be achieved (represented by phases
of the CMP). In this regard (Goldkuhl et al., 1997)
proposed an approach for establishing a series of
significant elements a method should consists of. The
first element we proofed is called method component
that consists of procedures, concepts and notations
cooperate (provided by building blocks and its
description of the individual phases). The structure
formed by the different method components is called
framework that covers the order of execution (BB1
 BB2  BB3  BB4). The perspective describes
another method element that provides issues like
philosophy, principles or objectives of the method
and provides the conceptual view on it (provided in
section 1.1 and section 2). Requirements form the
method element collaboration like roles and
collaboration techniques (brainstorming, mind
mapping, stakeholder analysis, communication plan)
are considered during the creation of the CMP
method (provided in BB2). Nevertheless, some
weaknesses were observed with regard to a
predefined notation for BB results, just some
suggestions are provided (see BB3) and no cohesive
notation concept. Furthermore, a more precise and
aligned concept for the collaboration forms should
enhance quality of the method. These are already
aspects we will consider in the next iteration. In
ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems
210

terms of a scientific validation and under
consideration of the DSR paradigm and its
recommended methods we used action research
cycles (ACR) and published the concept and first
validation results on ICEIS 2014 (Wißotzki et al.,
2014). More action research cycles are still in
progress with companies from the plane and train
manufacturing branch and utility industry that will
cover notation, collaboration and utility issues.
5 CONCLUSION / OUTLOOK
Enterprises reach their goals by implementing
strategies. Successful strategy implementation is
affected by challenges that an enterprise has to
overcome. Enterprises require specific capabilities in
order to be able to implement strategies efficiently
and achieve a specific outcome. A demand for a
systematic management approach to identify
capabilities is growing.
We presented a generic approach that can be
used to derive capabilities through a structured
process and gather them in an enterprise-specific
catalog for an effective operationalization of
enterprise strategies. A capability here describes a
certain combination of information, roles, activities/
procedures, and resources to support issues like
strategy implementation, planning purposes, or
transformation processes.
Following a four-building-block approach, we
described a straightforward and flexible process for
capability catalog developers and designers, which
allows the integration of descriptive elements for
different capability types. The CMP is based on the
approach of (Wißotzki et al., 2013) and it forms a
tool that facilitates the development of scientifically
well-founded capability catalogs aligned with the
design science research guidelines (Hevner and
Chatterjee, 2010). In particular, our approach
provides a building block covering the continuous
evaluation and maintenance in order to sustain
capability and catalog quality.
Additional detailed content of the building blocks
and corresponding steps will be provided by more
ACR executions and have only been mentioned to
some extent in this section 4. Our future research
will elaborate on this topic and demonstrate more
practical use cases of capability catalog development
projects. In fact, our aim is to focus more on use
cases and / or possible applications in order to
indicate the tradeoffs of our approach and to
evaluate and potentially extend the process.
REFERENCES
Abowd GD, Dey AK, Brown PJ, Davies N, Smith M,
Steggles P (1999) Towards a better understanding of
context and context-awareness. In: Proceedings of the
1st international symposium on Handheld and
Ubiquitous Computing, Karlsruhe, Germany, 27-29
September 1999.
Bazire, M., Brézillon, P. (2005), Understanding Context
Before Using It, In Dey, A. et al. (Eds.), Modeling
and Using Context, Lecture Notes in Computer
Science, Vol. 3554, Springer Ber-lin Heidelberg,
Berlin, Heidelberg, pp. 29–40.
Buckl S, Dierl T, Matthes F, Schweda CM (2010)
Building blocks for enterprise architecture
management solutions. In: Harmsen F, Proper E,
Schalkwijk F, Barjis J, Overbeek S (eds) Practice-
Driven Research on Enterprise Transformation,
Lecture Notes in Business Information Processing 69.
Springer, Berlin, pp 17-46.
Gartner (2013) Gartner executive program survey of more
than 2,000 CIOs shows digital technologies are top
priorities in 2013.
http://www.gartner.com/newsroom/id/2304615.
Accessed 07 February 2014.
Goldkuhl, G., Lind, M., & Seigerroth, U. (1997). Method
integration as a learning process. Jönköping
International Business School.
Duhan S, Levy M, Powell P (2005) IS strategy in SMEs
using organizational capabilities: the CPX framework.
In: Proceedings of the 13th European Conference on
Information Systems.
Freitag, A., Matthes, F., Nowobilska, A.,Schulz, C.: A
method for business capability dependency analysis.
In: International Conference on IT-enabled Innovation
in Enterprise (ICITIE2011), Sofia, 2011.
Hevner, A.R. and Chatterjee, S. (2010), Design research
in information systems: Theory and practice, Springer,
New York, London.
Lahrmann G, Marx F (2010) Systematization of maturity
model extensions. In: Winter R, Zhao JL, Aier S (eds)
Global Perspectives on Design Science Research,
Lecture Notes in Computer Science 6105. Springer,
Berlin, pp. 522–525.
Lengler R, Eppler M (2007) Towards a periodic table of
visualization methods for management. In: IASTED
Proceedings of the Conference on Graphics and
Visualization in Engineering (GVE 2007), Clearwater,
Florida, USA.
March, S. T.; Smith, G. G.: Design and Natural Science
Research on Information Technology. In: Decision
Support Systems 15 (1995) 4, S. 251-266.
Simon D, Fischbach K, Schoder D (2014) Enterprise
architecture management and its role in corporate
strategic management. Information Systems and e-
Business Management 12(1):5-42.
Ulrich W, Rosen M (2011) The capability map – the
rosetta stone of business/ IT alignment. The Enterprise
Architecture Advisory Service Executive Report
14(2), Cutter Consortium, Arlington, USA.
AProcessApproachforCapabilityIdentificationandManagement
211

Wißotzki M, Koç H, Weichert T, Sandkuhl K (2013)
Development of an enterprise architecture
management capability catalog. BIR, Springer, pp.
112–126.
Wißotzki M, Koç H (2014) Evaluation concept of the
EAM capability navigator. In: Proceedings of ICEIS
2014, Lisbon, Portugal.
ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems
212