Capability-based Planning with ArchiMate
Linking Motivation to Implementation
Adina Aldea
1,2
, Maria Eugenia Iacob
1
and Jos Van Hillegersberg
1
, Dick Quartel
2
and Henry Franken
2
1
Centre for Telematics and Information Technology, University of Twente, Enschede, The Netherlands
2
BiZZdesign, Enschede, The Netherlands
Keywords: Capability-based Planning, ArchiMate, Enterprise Architecture, Strategy Planning, Business IT Alignment.
Abstract: This paper proposes a methodology for capability-based planning (CBP) and investigates how it can be
modelled with ArchiMate. This can be considered an important step in aligning Business and IT. By having
a common language to express organisational plans, enterprise architects can engage business leaders to
plan organisational change based on business outcomes, rather than projects, processes and applications.
This is possible because CBP is centred on realising strategic goals by focusing on what an organisation can
do, rather than how it can do it. In order to determine a methodology for CBP we look at current research
and practice, and propose a generic set of steps. Based on this, we analyse the ArchiMate 2.1 Specification
for suitability and propose the addition of the Capability and Metric concepts. In the last section we validate
our proposed methodology and metamodel with the help of a case study.
1 INTRODUCTION
In today’s dynamic environment, organisations need
to be ready and able to plan and implement change
at a quicker pace. Organisations that rely on
previous success and persist with strategies that have
worked in the past have shown a decline in
performance in situations of radical environment
change (Audia et al., 2000).
Strategic management research has investigated
for the past few decades how organisations can gain
and maintain competitive advantage in such
dynamic situations. This has led to the formulation
of multiple theories, with a focus on Resources
(Barney, 1991) and Capabilities ((Teece and Pisano,
1994), (Eisenhardt and Martin, 2000)) as a source of
competitive advantage. Since the resource-based
theories have been criticised to have major
limitations (Kraaijenbrink et al., 2010), the focus has
shifted to capability-based theories as a source for
competitive advantage.
One of the most recent large-scale applications
of capability-based theories can be seen in the
defence sector. In the past decade, CBP has become
a standard in defence planning throughout the
NATO alliance (De Spiegeleire, 2011) and has been
widely adopted by the Defence community (TTCP)
(Hales and Chouinard, 2011).
The need for CBP in the context of organisations
has become more apparent in the recent years. More
and more researches identify capabilities as the way
to link business and IT ((Danesh and Yu, 2014),
(Stirna et al., 2012)), to link business outcomes to IT
(Miklos, 2012), and all-in-all as a solution for
improving the business and IT alignment ((Lee and
Song, 2011), (Zdravkovic et al., 2013)).
Given this increased interest in capabilities, both
in theory and in practice, it is no surprise that this
concept has recently surfaced in enterprise
architecture (EA). EA frameworks such as TOGAF
(Open Group, 2011), have already introduced basic
notions of CBP and its role in designing, planning
and implementing organisational change. An
approach to integrate resources and capabilities in
ArchiMate, a modelling language for EA which is
often used with TOGAF, has already been proposed
by Iacob et al. (2012). One of the main issues
addressed by CBP in this context is providing
architects and business people with a common
ground to initiate discussions in terms of business
outcomes (increased output and quality, lower costs,
revenue growth, improved market share) instead of
projects, processes and applications (Scott, 2009).
Even though CBP is already being used with EA
frameworks, there is little research into how to
design, assess, implement and monitor capabilities,
352
Aldea A., Iacob M., Van Hillegersberg J., Quartel D. and Franken H..
Capability-based Planning with ArchiMate - Linking Motivation to Implementation.
DOI: 10.5220/0005468103520359
In Proceedings of the 17th International Conference on Enterprise Information Systems (ICEIS-2015), pages 352-359
ISBN: 978-989-758-098-7
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
and also how to use this in a real case (Miklos,
2012). Preliminary research presented by
Papazoglou (2014) describes a capability-based
methodology that can be used in collaboration with
TOGAF and modelled with ArchiMate. Although
this research presents interesting ideas it still has
several limitations regarding the possibility of
making iterations, the large number of assumptions
made and the validation of the method which was
done by using a fictitious case study.
The goal and contribution of this paper is to
propose a methodology for CBP that can be used
independently of other domains such as strategic
management or EA, but also in collaboration with
these domains. Furthermore we investigate if and
how the proposed CBP methodology can be
modelled with ArchiMate. The ArchiMate
modelling language was chosen as a basis for this
work because it already contains a series of strategic
concepts, an extension for the concepts of Capability
and Resource has already been proposed by Iacob et
al. (2012) and Azevedo et al. (2013), and it is also
one of the most used modelling languages for EA.
We validate our proposed methodology and
modelling with the use of a case study.
The research methodology we follow in this
study is design science as proposed by Peffers et al.
(2007), which has also shaped the structure of this
paper. The introduction presents the problem
addressed in this paper together with the
contribution of the proposed approach. Section 2
includes a presentation of the CBP methodology
developed by the authors. In Section 3 we assess the
suitability of the ArchiMate core modelling
language and its extensions. Section 4 contains a
validation of our proposed methodology and
metamodel with the help of a case study. The paper
concludes with conclusions, discussion, limitations,
and future work (Section 5).
2 CBP METHODOLOGY
In practice, there are many views on capabilities,
mainly because they are being used in many
different domains. In the defence industry, a
capability refers more to what you would like to be
able to do in a specific situation (e.g. war), rather
than the ability, capacity or potential that an
organisation, person or system possesses (Open
Group, 2011) in any type of situation, opportune or
not. We will introduce a basic and simple view on
capabilities and illustrate this with an example.
Simply said, a capability is the ability of an
organisation to employ resources to achieve some
goal (Iacob et al., 2012). For example, a Customer
data management capability is the ability of an
organisation to manage the personal information of
customers in databases. Thus, we see capabilities as
the ways in which enterprises combine resources,
competences, information, processes and their
environments to deliver value to stakeholders. They
describe, in general and high-level terms, what the
business is able to do (Open Group, 2011).
The most common use of capabilities is in the
context of CBP. According to the Open Group
(2011), CBP focuses on the planning, engineering,
and delivery of strategic business capabilities to the
enterprise. The TTCP is currently using a CBP
system that describes generic steps, the input
required to be able to do CBP, an assessment tool,
and the desired outcome of CBP (Taylor, 2005).
However this method is too general and more related
to the defence domain. Similarly, the RAND
Institute has proposed a method for improving CBP
in the American Department of Defence. Although
this method is comprehensive, it is intended for
military use, therefore it has a focus on risk
management and scenario analysis. We have
developed our CBP methodology based on the
research of Papazoglou (2014), the guidelines of
TOGAF (Open Group, 2011), of TTCP (Taylor,
2005) and of the RAND (Davis, 2002).
We identify the following activities in CBP:
Map, Assess, and Plan. These activities are
typically executed in successive cycles, where some
may need more or less attention, depending on what
drives the respective planning cycle.
2.1 Mapping Capabilities
One of the first steps of CBP is determining the
capability map, which contains all the business
capabilities of an organisation. The planning of the
business improvements should be defined based on
this capability map.
2.1.1 Identifying Capabilities
Typically, any ability of an organisation can be
considered a capability. However capabilities should
be defined in a consistent manner. The following
guidelines are proposed for doing this. Thus, they
Should be defined by using a language that is
understandable by all relevant stakeholders. One of
the main benefits of using CBP as a link between
Business and IT is that it provides a common
language that all stakeholders can understand (van
Capability-basedPlanningwithArchiMate-LinkingMotivationtoImplementation
353
Gils and van Dijk, 2014). In order to achieve this,
capabilities should be expressed using general and
high-level terms (Open Group, 2011). This will
ensure that both business leaders and enterprise
architects can understand what a capability means in
terms of their business.
Should express what the organisation is able to
do, not how it does it. According to the Open Group
(2011), a capability is the ability that an
organisation, person, or system possesses. Therefore
it focuses on what an organisation is able to do and
abstracts from how the capability is actually
achieved (van Gils and van Dijk, 2014). By
following this logic, a capability can be defined by
using nouns, not verbs (Ulrich and Rosen, 2011).
Should not be redundant. A specific capability
should appear only once on a capability map,
regardless of how many processes, applications, etc.
realise it (Ulrich and Rosen, 2011). This is a
consequence of the fact that capabilities should be
defined independently of how they are realised.
Should be measureable. Capabilities can be used
to guide investment decisions, based on the business
outcome(s) they help achieve. Therefore, if the value
that is expected to be delivered by improving a
capability is not objectively identified, an
organisation might make investments that might not
yield the expected returns. Thus capabilities should
be defined using the SMART guidelines in order to
avoid ambiguity (Open Group, 2011)
Can be defined vertically or horizontally.
Capabilities can be defined down any lines that an
organisation wishes to improve, such as process,
function, organisational, etc. Therefore capabilities
can become lines of optimisation for an
organisation. For example, an organisation that
defines capabilities along the lines of processes will
optimise their process performance. An organisation
that defines capabilities down functional lines will
be optimised based on business functions (Open
Group, 2011). Consequently it is advised for
organisations, depending on their preference, to
choose vertical or horizontal optimisation and define
their capabilities accordingly.
Can be decomposed into sub-capabilities. It is
usual that high-level capabilities are decomposed
into more detailed capabilities. This decomposition
is particularly useful when making a capability map.
For a high-level planning and analysis, such a map
may contain main capabilities (level 1) and another
two levels of decomposition (level 2 and 3) of these
capabilities (Ulrich and Rosen, 2011). It is important
to keep the same level of detail for all the
capabilities within the same level.
2.1.2 Linking Capabilities
As mentioned before, CBP focuses on the planning,
engineering, and delivery of strategic business
capabilities to the enterprise (Open Group, 2011).
There are two main aspects to this statement. First of
all, it is stated that CBP deals only with the strategic
business capabilities of an organization. What is
meant by this is that there should be an emphasis on
those capabilities that provide strategic value. This
can be done by identifying which capabilities of an
organisation contribute to realizing a specific
strategy. Therefore the activities of CBP can start in
the later phases of strategy planning, after the
strategic objectives, KPIs, targets and initiatives
have been determined. This strategic guidance is
needed to begin CBP (Taylor, 2005).
Second of all, the statement prescribes what CBP
should do, namely the planning engineering and
delivery of these capabilities, or to put it differently
the entire process of obtaining them. It can be
further explained as a planning discipline, in which
enterprise change is defined, sequenced, coordinated
and managed in terms of capability increments. Thus
it has impact on and complements EA. This comes
in addition to projects and deliverables within the
frame of EA, and can, therefore, support project
portfolio management as well. In other words,
capabilities can be used as a higher level abstraction
of EA, where elements of the architecture realise
business capabilities. Project portfolio management
can help manage those projects that implement
enterprise transformation in steps and therefore the
realisation of the respective capability increments.
2.2 Assessing Capabilities
It is important for CBP to have capabilities that are
measurable. Therefore it is necessary to define
metrics for each capability. Besides having an
objective look at the outcomes of improving a
capability, defining metrics can help with assessing
the current and desired performance levels, with
monitoring progress, and with evaluating the
realised outcomes of the improvement (Taylor,
2005). We define a metric as the extent, quantity,
amount, or degree of something, as determined by
measurement or calculation.
2.2.1 Identifying Metrics
In the context of ArchiMate, Metric can be seen as a
specialisation of Driver. For example the Process
variance metric could be used to measure the level
ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems
354
of the Customer management capability. In this
example, the Process variance metric is a
decomposition of the higher level metric Operational
performance which is a strategic KPI/metric.
2.2.2 Analysing Capability Gaps
The purpose of this step is to determine the current
performance levels of each capability and compare
to the desired levels which will help realise the
strategic goals. The difference between these current
and desired levels is called a capability gap. Once
the capability increments have been identified for
each business capability, their performance levels
can be determined. This is achieved by assessing
each capability increment against each metric,
typically with a quantitative analysis. In case a
quantitative analysis is not possible, a qualitative
analysis with pseudo-performance levels can be
used. The following is an example of such
performance levels: One Very low; Two Low;
Three – Medium; Four – High; Five – Very high.
This information can be plotted in a spider chart
in which capability increments are assessed based on
their performance levels according to a several
metrics. Any number of metrics can be used to
assess the capability increments but a minimum of
three metrics are needed to make a spider chart.
The capability heat map can also be used as a
high level method for representing capability gaps
(Taylor, 2005). After assessing the relevant
capabilities in the capability map and determining
their desired future levels, a specific colour can be
assigned to their performance levels. For example, if
a capability is scoring very low on its performance
and the desired level is medium, it can be coloured
red. If a capability is scoring medium and the
desired level is high, then it can be coloured yellow.
If a capability is scoring medium and the desired
level is medium, then it can be coloured in green.
2.3 Planning Capability Increments
The purpose of this section is to plan the
improvements to a capability. Typically these types
of improvements are not all made at once, but they
are planned in capability increments, over time. This
implies that the improvement of a capability is
usually done in multiple capability increments, each
providing a part of the expected added value of
improving the capability (Open Group, 2011).
A capability roadmap can be used to sequence
and plan these capability increments over time
(Papazoglou, 2014). By using this method, it can
become easier to have an overview of when each
increment is supposed to be implemented.
Furthermore it can help with planning the
appropriate resources needed to realise each
increment and avoid not having resources available
because they are being used for other purposes.
In terms of EA, capability roadmaps can be a
very useful starting point for planning the necessary
architectural change. They can be used to plan the
work packages that help realise capability
increments. Furthermore they help link desired
business value to architectural change and to work
packages. Therefore investments in IT can be easier
justified as necessary for achieving strategic goals.
3 MODELLING CBP WITH
ARCHIMATE
Based on the methodology presented in Section 2 we
have identified several concepts which we use for
determining the suitability of the ArchiMate
language for CBP. A complete description of the
ArchiMate language can be found in the ArchiMate
2.1 Specification (Open Group, 2013).
- Mission, Vision, Strategy and Objective can be
modelled by using the concept of Goal, according
to Aldea et al. (2015);
- Analysis/Assessment can be modelled with the
concept of Assessment;
- Capability is defined as an organisation’s ability
to employ resources to achieve some goal. This
concept does not have a direct equivalent in
ArchiMate and was proposed as an addition by
Iacob et al. (2012) and Azevedo et al. (2013);
- Capability Increment is defined as a version of a
capability that represents an increase in the
performance of the capability. This concept also
does not have a direct equivalent in ArchiMate;
- Metric is defined as the extent, quantity, amount,
or degree of something, as determined by
measurement or calculation. ArchiMate does not
contain a concept that can express a measurement
assigned to another concept.
From this we can conclude that the current
specification of the ArchiMate language is not
sufficient for the purposes of CBP. Therefore we
propose the addition of the concepts of Capability,
Capability increment, and Metric. Figure 1 shows
how these concepts can be related to existing
ArchiMate concepts. This metamodel, which is
based on the work of Iacob et al. (2012) will be used
in this paper to model CBP with ArchiMate.
Capability-basedPlanningwithArchiMate-LinkingMotivationtoImplementation
355
Figure 1: CBP extension metamodel (Iacob et al. 2012).
It is worth noting that Capability increment is not
present at metamodel level. This is the case because
it is a version/variant of the Capability concept, and
not an independent concept within the metamodel.
The Capability increment can be modelled as a
specialisation of a Capability (at model level), where
a specialisation relationship is used to represent that
an increment is a version of the Capability (with a
certain performance level).
4 CASE STUDY
ArchiPharma is a large international organisation
that has many geographically spread locations. It is
the result of many mergers and take-overs. They are
aware of the necessity to continuously change and
improve to reach their end goal of becoming the
leading provider of pharmaceutical services in the
world. To realize this ambitious goal they move their
strategy from a complete focus on product
leadership to a focus on operational excellence with
product leadership still present in the background.
The main issue the organisation is facing is that
it needs to comply to many governmental
regulations which change regularly. Thus the
organisation has to be agile, which is not easy, partly
because of the legacy application landscape. The
legacy is a result of the many mergers and take-
overs where landscapes are simply patched together.
These inefficiencies are directly influencing
interactions with customers when running daily
business. In order to deal with this issues they plan
an enormous transformation. Their main concern is
how to manage this. In the following sections we
show how we supported this transformation by
relating disciplines like strategy management, CBP
and EA, creating a holistic overview on the
transformation. The entire example of the
ArchiPharma organisation is modelled using the
ArchiMate language (2.1 Specification) and the
proposed added concepts of Capability and Metric.
4.1 Strategy Planning
Based on their strategy to excel at operations, the
organisation has as main objective to Centralise the
Information Systems. In order to measure the
performance of the Centralize IS objective they use
several strategic KPIs such as Process performance,
Process variance, and Information consistency.
By assessing how well the objective of
Centralize IS can be fulfilled at the moment, we can
see there are several problems that stand in the way
of successfully realising it. The objective is assessed
based on the metrics that are associated with it
(Figure 2). It appears that the Process performance
metric scores low because there are Multiple and
inconsistent CRM databases; Process variance
metric scores low because it is Difficult to comply
with new regulations due to complex landscape;
Information consistency metric scores low because
there is a Non-uniform way of billing customers.
Figure 2: Example objective assessed based on metrics.
4.2 Capability-based Planning
In order to proceed with implementing the chosen
strategy and objectives, a capability map has been
developed. This map contains several main
capabilities and their decomposition into sub-
capabilities. Figure 3 illustrates an excerpt from the
capability map of ArchiPharma.
Next, the capabilities which are needed to realise
the chosen strategy and the objectives associated to
it are identified (Figure 4). These are the strategic
capabilities, in the context of the chosen strategy.
The underlying architecture which realises each
capability is determined. We take the example of the
ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems
356
Customer management capability.
Figure 3: Excerpt of the capability map.
Figure 4: Capabilities related to strategy.
The part of the architecture which is needed to
realise this capability is modelled in a plateau
(Figure 5).
Figure 5: Architecture elements that realise a capability.
We consider that Customer management increment
1 is the current version of the Customer management
capability, and the Customer management increment
2 is the next version of the capability, which will
help realise the objectives and strategy. With this in
mind, increment 1 and 2 are assessed according to
the three metrics (Figure 6). Of course the end goal
is that the capability will score very high on all
metrics, but that is for the following increments (3,
4, 5, …, n).
Since there are at least three metrics defined for
this capability, and thus for its increments, a spider
chart can be made. This spider chart shows us in a
more graphical way the same information that is
available in the capability scorecard (Figure 7).
Based on the assessment of the capabilities we
Figure 6: Capability scorecard.
Figure 7: Capability spider chart.
can build a capability heat map. In our example, the
Customer management capability can be coloured
red since the gap between de current and desired
performance levels is fairly large. By looking in
depth to its decomposition we can see that also
Customer data management and Customer billing
and collection management can be coloured red
since the gap between the current and desired
performance levels is also fairly large (Figure 8).
Figure 8: Capability heat map.
Now that the capabilities that need to be improved
have been identified, a capability roadmap can be
designed. In our example, we plan the improvement
of the Customer management and the Governance,
Risk and Compliance management capabilities over
the next 7 quarters (Figure 9).
4.3 Enterprise Architecture
As mentioned before, a capability is realised by core
elements of the EA. This can be modelled by using a
realisation relation between the capability concept
Capability-basedPlanningwithArchiMate-LinkingMotivationtoImplementation
357
and the elements of the ArchiMate core. In our
example, we model the architectural elements
needed to realise the Customer management
capability increment 2, as shown in Figure 10. The
plateau concept can be used to organise the
transformation planning needed to implement the
capability increment.
Figure 9: Capability roadmap.
Figure 10: Architecture elements realising a capability
increment.
Figure 11: Plateaus that realise capability increments.
For each of the defined plateaus there is at least
one program that will realise it. Each of these
programmes can have at least one work package
(project) that they are composed of.
Figure 11 illustrates such an approach in the
context of the ArchiPharma case. By having a
relation between work packages/programs and
capabilities it is possible to make a roadmap in
which it is made clear which work package/program
contributes to realising which plateau, which
capability increment, and lastly which capability. In
our example, we can see in Figure 12 that there are
three work packages/programs which help realise
the desired version of the Customer management
capability. The timeline shows in which period of
time these work packages/programs are supposed to
be implemented, in which period of time a specific
architecture and capability increment will exist.
Figure 12: Roadmap with programmes linked to the
capabilities they improve.
5 CONCLUSIONS
In this paper we propose a methodology for CBP. In
order to do this, we look at existing literature and
practice, and design methodology that can be used
independently, or in combination with strategic
management and EA. Based on this methodology we
assess the suitability of the ArchiMate modelling
language. We show that the language does not
include all relevant concepts needed to model CBP.
With the addition of the Capability concept (with
Capability increment as specialisation) and the
Metric concept (as a specialisation of Driver) it is
possible to model all aspects of CBP. The first
question to answer when considering adding a
Capability concept to ArchiMate is: Does ArchiMate
ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems
358
need a Capability concept? If an existing concept
can suffice, then there would be no reason to add
another to the language. Following the proposal of
Iacob et al. (2012), we argue that a capability is
fundamentally different than a business process,
business function, business service and business
interaction. A capability, as it is also defined in
TOGAF, is on a different level of abstraction than
the business layer concepts of ArchiMate. Based on
this we can state that a capability can be realised by
elements of an architecture, such as business
process, business function, business service and
business interaction.
By being able to use CBP as a link between
strategy management and EA it can be possible to
achieve a Business and IT alignment. Therefore we
suggest that further research should be done in order
to investigate this possibility.
There are several limitations to the research we
have presented. We have determined that the
ArchiMate language is not sufficiently developed at
the moment to support CBP modelling. Further
research is needed in order to determine if the
proposed added concepts are sufficient. Also, we
have validated our proposed methodology and
metamodel with the help of one case study.
Although this is sufficient for stating that our
approach is viable for the organisation under
analysis, we cannot state that it is applicable for all
organisations. Therefore further research needs to be
done in order to investigate the generalizability of
our methodology and metamodel.
ACKNOWLEDGEMENTS
The authors thank Bill Poole from Journey One for
the work he has done on this topic, which has been
an inspiration for this research.
REFERENCES
Aldea, A., Iacob, M.E., Van Hillegersberg, J., Quartel, D.,
Franken, H. & Bodenstaff, L., 2015. Modelling
strategy with ArchiMate. In 30th ACM Symposium on
Applied Computing (SAC). Accepted.
Audia, P.G., Locke, E.A. & Smith, K.G., 2000. The
paradox of success: An archival and a laboratory study
of strategic persistence following radical
environmental change. Acad. of Man. J., 43, 837-853.
Azevedo, C.L., Iacob, M.E., Almeida, J.P.A., Van Sinderen,
M., Pires, L.F. & Guizzardi, G., 2013. An ontology-
based well-founded proposal for modeling resources
and capabilities in ArchiMate, In 17th IEEE EDOC, 39-48.
Barney, J. 1991. Firm resources and sustained competitive
advantage. Journal of management, 17, 99-120.
Danesh, M.H. & Yu, E., 2014. Modeling Enterprise
Capabilities with i*: Reasoning on Alternatives.
Advanced Information Systems Engineering
Workshops, 2014, 112-123. Springer.
Davis, P.K., 2002. Analytic architecture for capabilities-
based planning, mission-system analysis, and
transformation. DTIC Document.
De Spiegeleire, S., 2011. Ten trends in capability planning
for defence and security.The RUSI Journal, 156,20-28.
Eisenhardt, K.M. & Martin, J.A., 2000. Dynamic
capabilities: what are they? Strategic management
journal, 21, 1105-1121.
Hales, D. & Chouinard, P., 2011. Implementing Capability
Based Planning within the Public Safety and Security
Sector. DTIC Document.
Iacob, M.E., Quartel, D. & Jonkers, H., 2012. Capturing
business strategy and value in enterprise architecture
to support portfolio valuation. In 16
th
International
EDOC, 11-20.
Kraaijenbrink, J., Spender, J.C. & Groen, A. J., 2010. The
resource-based view: a review and assessment of its
critiques. Journal of management, 36, 349-372.
Lee, H. & Song, Y.T., 2011. Bridging Enterprise
Architecture Requirements to ArchiMate, Springer.
Miklos, J., 2012. A meta-model for the spatial capability
architecture. J. of Theoretical and Applied IT, 43.
Open Group, 2011. TOGAF® Version 9.1, Van Haren.
Open Group, 2013. ArchiMate® 2.1, Van Haren.
Papazoglou, A. 2014. Capability-based planning with
TOGAF® and ArchiMate®. Master thesis, University
of Twente.
Peffers, K., Tuunanen,T., Rothenberger,M.A. &
Chatterjee, S., 2007. A design science research
methodology for information systems research. J. of
management information systems, 24, 45-77.
Scott, J., 2009. Business Capability Maps: The Missing
Link Between Business Strategy and IT Action.
Architecture & Governance magazine.
Stirna, J., Grabis, J., Henkel, M. & Zdravkovic, J., 2012.
Capability driven development–An approach to
support evolving organizations. The Practice of
Enterprise Modeling. Springer.
Taylor, B., 2005. Guide to Capability Based Planning.
Meeting Proceedings of RTO-MP-SAS-055—
Analytical Support to Defence Transformation: The
RTO Studies, Analysis and Simulation Panel (SAS)
Symposium, 26–28 April, 8-1.
Teece, D. & Pisano, G., 1994. The dynamic capabilities of
firms: an introduction. Industrial and corporate
change, 3, 537-556.
Ulrich, W. & Rosen, M., 2011. The Business Capability
Map: The" Rosetta Stone" of Business/IT Alignment.
Cutter Consortium, Enterprise Architecture, 24.
Van Gils, B. & Van Dijk, S., 2014. The practice of
enterprise architecture: experiences, techniques, and
best practices, BiZZdesign Academy B.V.
Zdravkovic, J., Stirna, J., Henkel, M. & Grabis, J., 2013.
Modeling business capabilities and context dependent
delivery by cloud services. Advanced Information
Systems Engineering. Springer, 369-383.
Capability-basedPlanningwithArchiMate-LinkingMotivationtoImplementation
359