Capability-based Planning with ArchiMate

Linking Motivation to Implementation

Adina Aldea

1,2

, Maria Eugenia Iacob

and Jos Van Hillegersberg

, Dick Quartel

and Henry Franken

Centre for Telematics and Information Technology, University of Twente, Enschede, The Netherlands

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

 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

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