Capability-Based Planning

Capability-Based Planning
The Link between Strategy and

Enterprise Architecture
A White Paper by:

Adina Aldea, University of Twente & BiZZdesign
Maria Eugenia Iacob, University of Twente
Marc Lankhorst, BiZZdesign
Dick Quartel, BiZZdesign
Bill Wimsatt, Oracle
November 2016
Capability-Based Planning: The Link between Strategy and Enterprise Architecture
Copyright © 2016, The Open Group

The Open Group hereby authorizes you to use this document for any purpose, PROVIDED THAT any copy of this document,
or any part thereof, which you make shall retain all copyright and other proprietary notices contained herein.
This document may contain other proprietary notices and copyright information.
Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right under any
patent or trademark of The Open Group or any third party. Except as expressly provided above, nothing contained herein shall
be construed as conferring any license or right under any copyright of The Open Group.
Note that any product, process, or technology in this document may be the subject of other intellectual property rights
reserved by The Open Group, and may not be licensed hereunder.
This document is provided "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied
warranties, so the above exclusion may not apply to you.
Any publication of The Open Group may include technical inaccuracies or typographical errors. Changes may be periodically
made to these publications; these changes will be incorporated in new editions of these publications. The Open Group may
make improvements and/or changes in the products and/or the programs described in these publications at any time without
notice.
Should any viewer of this document respond with information including feedback data, such as questions, comments,
suggestions, or the like regarding the content of this document, such information shall be deemed to be non-confidential and
The Open Group shall have no obligation of any kind with respect to such information and shall be free to reproduce, use,
disclose, and distribute the information to others without limitation. Further, The Open Group shall be free to use any ideas,
concepts, know-how, or techniques contained in such information for any purpose whatsoever including but not limited to
developing, manufacturing, and marketing products incorporating such information.
If you did not obtain this copy through The Open Group, it may not be the latest version. For your convenience, the latest
version of this publication may be downloaded at www.opengroup.org/bookstore.
This White Paper is an informational document and does not form part of the TOGAF ® documentation set. Readers should
note that this document has not been approved through the formal Open Group Standards Process and does not represent the
formal consensus of The Open Group Architecture Forum.
ArchiMate®, DirecNet®, Making Standards Work®, OpenPegasus®, The Open Group®, TOGAF®, UNIX®, UNIXWARE®,
X/Open®, and the Open Brand X® logo are registered trademarks and Boundaryless Information Flow™, Build with Integrity
Buy with Confidence™, Dependability Through Assuredness™, EMMM™, FACE™, the FACE™ logo, IT4IT™, the
IT4IT™ logo, O-DEF™, O-PAS™, Open FAIR™, Open Platform 3.0™, Open Process Automation™, Open Trusted
Technology Provider™, Platform 3.0™, SOSA™, the Open O™ logo, and The Open Group Certification logo (Open O and
check™) are trademarks of The Open Group.
Business Architecture Body of Knowledge® and BIZBOK® are registered trademarks of Business Architecture Guide.
All other brands, company, and product names are used for identification purposes only and may be trademarks that are the
sole property of their respective owners.

Document No.: W16C
Published by The Open Group, November 2016.

Any comments relating to the material contained in this document may be submitted to:
The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom
or by email to:
ogpubs@opengroup.org
www.opengroup.org A White P aper P ublished by The Open Group 2

Table of Contents
Executive Summary................................................................... 4
Introduction .............................................................................. 5
Why is Capability-Based Planning Relevant? ............................................ 5
What is a Capability? ............................................................................... 7
What is Capability-Based Planning? ......................................................... 7
Capability-Based Planning Overview ......................................... 9
Capability-Based Planning and Enterprise Architecture ........... 11

Capability-Based Planning and the TOGAF Standard ............................... 11
Capability-Based Planning and the ArchiMate Standard ........................... 12
Capability-Based Planning Example ........................................ 15

Mapping Capabilities ............................................................................. 15
Assessing Capabilities ........................................................................... 19
Conclusions ............................................................................. 31
References............................................................................... 33
About the Authors ................................................................... 34
Acknowledgements .................................................................. 34
About The Open Group ........................................................... 35

Boundaryless Information Flow

achieved through global interoperability
in a secure, reliable, and timely manner
Executive Summary
Today, most organizations are faced with a more dynamic environment, which means
they need to undergo more frequent transformations to stay competitive and agile.
This can prove to be a difficult task since organizational transformations require not
only good alignment between strategy development and implementation, but also
good communication and understanding between business leaders and Enterprise
Architects.
In this White Paper we describe how a Capability-Based Planning (CBP) method is a

solution for the alignment between business strategy and Enterprise Architecture.
This method is intended to be used by Enterprise Architects to model at a higher level
of abstraction the current and desired abilities of an organization, in relation to the
organization’s strategy and its environment. Furthermore, with the help of
capabilities, Enterprise Architects can have common ground to initiate discussions
with business leaders in terms of business outcomes, while having a link between
what an organization can do with how it does it. The target audience of this White
Paper is business leaders, technology leaders, and program and portfolio managers.
The method presented in this White Paper aims to improve the integration and
interoperability between business and technology strategies through capabilities
management and planning. This approach is in line with The Open Group vision of
Boundaryless Information Flow™.

Introduction
In this White Paper we present our view on Capability-Based Planning (CBP) and its relation to other
domains such as strategy and Enterprise Architecture (EA). We recommend a method for CBP focusing on
mapping capabilities, linking them to the strategy and EA, assessing them according to several performance
indicators, determining gaps, and planning their implementation. We define the role of CBP as a bridge
between disciplines and illustrate it via the example of ArchiPharma, representing a real, but anonymized,
pharmaceutical organization. Furthermore, we demonstrate how the ArchiMate® 3.0 specification, an Open
Group standard, can be used to support the modeling of CBP, with the help of relevant concepts and
relationships. Moreover, the application of the TOGAF® standard supporting CBP will also be studied.
Why is Capability-Based Planning Relevant?

Today, most organizations are faced with a more dynamic environment, which means they need to undergo
more frequent transformations to stay competitive and agile. Knowledge is power. Knowing what your
organization can do (capabilities) and what resources are available can help make more informed decisions.
Thus, having this knowledge and a good process for strategy development and implementation can be vital
for success.
The field of EA is focused on designing, planning, and implementing organizational change. An EA is a

high-level description of the structure and operation of an organization. There are multiple alternative
frameworks for EA which are supported by methods, models, languages, and tools. However, these
frameworks are designed primarily as a communication mechanism between Enterprise Architects. A
business-focused view needs to understand explicitly “what” the business does and where investment will
reap the most value. This makes it difficult to elaborate required changes, which are reflected in the EA, in
terms that business leaders recognize. The problem can also be seen from the reverse perspective. In the field
of business, strategic thinking and planning deliver strategies and high-level goals which are not directly
reflected in the common EA models of an organization. These long-term and/or generic plans need to be
specified and made actionable in a way that both business leaders and Enterprise Architects can act upon
them (see Figure 1).

Business Focus
• Grow Earnings Per Share (EPS)

• Increase margins by lowering cost of sales and support
services
• Improve customer loyalty of brand image
People
Capability Process
Material
IT Focus
• Increase return on IT assets

• Eliminate redundant development work
• Reduce cost and time of delivery
• Assure and improve enterprise security
• Improve uptime to eliminate business system disruption
Figure 1: Capabilities are a Common Language for Business and IT Leaders
Planning organizational transformations based on capabilities can help to reduce this gap. Capabilities
provide a high-level view of the current and desired abilities of an organization, in relation to the
organization’s strategy and its environment (Ulrich & Rosen, 2011). Capabilities comprise people, processes,
and assets that can be measured, described, designed, and realized using EA approaches. In the ArchiMate
3.0 specification, a capability is defined as an ability that an active structure element, such as an organization,
person, or system, possesses or requires (ArchiMate 3.0, 2016).
The main goal of CBP is to help with planning of organizational transformations in terms of capability
changes over time (creation, improvement, or elimination/outsourcing of capabilities). CBP can be used to set
investment priorities that would deliver the most value to an organization, according to the organizational
strategy.
CBP is a powerful technique when it is used consistently across the organization. This means that business
leaders, Enterprise Architects, portfolio managers, etc. need to share the same understanding regarding the
definition of capabilities, which ones are relevant for a specific strategy, how they relate to the business
model of the organization, and what changes need to be made to these capabilities in order to create the most
value for all stakeholders.

What is a Capability?
In practice, there are many views on capabilities, mainly because they are being used in many different
domains.
Since CBP is a domain which requires collaboration between multiple types of stakeholders (e.g., business
leaders, Enterprise Architects, program managers, etc.), we recommend a more simplistic definition of a
capability, as follows: “a capability is a particular ability or capacity that a business may possess or
exchange to achieve a specific purpose or outcome” (Business Capabilities Guide, 2016). For example, the
capability “Customer Data Management” is the ability of an organization to accumulate and manage all
pertinent customer attributes and inter-related business data to navigate new market channels and optimize
customer retention.
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 high-level terms, what
the business is able to do (TOGAF 9.1, 2011) and not how it is performed. They can be synthesized by or
connected to other capabilities. Capabilities are meaningful points of investment for the purposes of
investment planning. That is, each capability must represent a current or potential scope of investment or
divestiture for business and/or technology change.
What is Capability-Based Planning?

The most common use of capabilities is in the context of Capability-Based Planning (CBP). According to the
TOGAF 9.1 standard, CBP focuses on the planning, engineering, and delivery of capabilities to the
enterprise. In other words, CBP is a technique for planning of investments in capabilities that contribute to
realizing a specific organizational strategy. These investments typically take the form of a business and/or
technology improvement project. In that sense CBP fulfills a very similar purpose to Project Portfolio
Management (PPM). CBP is not, however, an alternative to PPM; rather the two planning disciplines are
highly complementary and best results are achieved when they are employed together. While CBP focuses on
identifying and planning high-level capability improvements, PPM focuses on designing and executing the
project portfolios that will bring the most value to the organization, according to the organizational
transformation plans.
The CBP method is focused on planning the required improvements (over time) through a defined series of
capabilities that will help to achieve the specified business outcomes. That is, CBP focuses on sequencing the
delivery of business improvements in terms of value, as opposed to scheduling projects and the delivery of
solutions. These improvements are planned in terms of capability increments. A capability increment is a
version of a capability that represents a change in the performance/maturity of the capability. According to
the TOGAF standard, it is brought about by changes to Capability Dimensions such as People, Processes, and
Material (assets) realizing a capability, resulting in a modification in performance. It is possible to measure
this change in the performance of a capability by using metrics. A metric is the extent, quantity, amount, or
degree of something, as determined by measurement or calculation. Metrics can be both quantitative and
qualitative in nature, and can be used to assess, monitor, and evaluate the changes in the performance of
capabilities.
A CBP approach drives questions such as:
• Should our focus for this capability be strategic differentiation or lower costs?

• Is this a core capability or a supporting capability? Should we consider outsourcing work in this
capability? Do we have adequate skills?
• Do we want to invest more or less in this capability?
• Are we addressing the most-important gaps between what we are able to do at the moment and what
we should be able to do in the future?
• Do we have overlapping projects?
• Do we have redundant applications, or an inadequate organizational structure?
• When do we need to incorporate industry standards?
• Are we driving towards industry standards?
The benefits of organizational-wide CBP include:
• State-of-the-art Approach to EA for the Modern Business Model: The modern EA requires
responsive CBP to reduce the cycle of change, reduce maintenance effort and cost, and demonstrate
that business needs are driving IT planning and delivery. The modern business model must provide for
rapid on-premise and cloud application composition, for vendor managers to develop and integrate
new pricing models into supply chain systems, and customers to interact more directly and intimately
than ever before.
• Project Portfolio and Business Direction Alliance: CBP will provide the basis for channeling
investment funding into acquiring and/or sunsetting assets in the most effective and efficient manner
(e.g., the rationalization of assets across multiple capabilities).
• Integrated Enterprise Funding Model: CBP provides for a horizontal view of enterprise operations.
This horizontal and vertical integration of capabilities (in the form of people, process, and assets)
leads to a more effective holistic funding mechanism versus the prevailing project-at-a-time funding
approach.

Capability-Based Planning Overview

We identify the following activities in CBP. These activities are typically executed in successive cycles,
where some activities may need more or less attention and effort, depending on what drives the respective
planning cycle. For example, if an organization has a new strategic intent, and has a capability map designed
at a previous date, it is not necessary to create another capability map from scratch. It is necessary, though, to
keep the capability map up-to-date, thus to add the new capabilities that have been successfully
implemented/acquired, or remove the capabilities that are no longer part of the organization.
Capability map Capability metrics

Capability architecture Capability heat map
Capability motivation Capability gaps
Map Assess
Control Plan
Capability realization Planning scenarios

Capability monitoring Capability increments
Capability evaluation Capability roadmaps
Figure 2: CBP Generic Activities
Figure 2 illustrates these generic activities of CBP together with the expected outcomes from each of them.
The diagram illustrates the following activities:
Map
• Identify, describe, and relate the capabilities of the organization. This may be done at different levels
of aggregation/decomposition.
• Link capabilities to their motivation (strategic goals) and their implementation (resources,
competences, information, processes, etc. as represented by EA models).
Analyze
• Identify relevant metrics/KPIs (derived from strategic objectives) and score these metrics (e.g., in
terms of properties of the EA to which the capability is linked).

• Identify under/over-performing capabilities and missing capabilities (gap analysis) based on

performance targets derived from the strategy.
• Analyze for potential duplicates. Identify capabilities that exist in different parts of the organization
but might have different names which are actually the same thing.
Plan
• Plan increments over time and allocate resources. This requires collaboration with strategy
management (sponsor, decision-maker), PPM (focus on definition of projects, portfolios, resources),
and EA (focus on design, road mapping, migration planning, feasibility).
• Monitor and control the planning. Similar to the planning of increments, this activity also requires
collaboration with strategy management, PPM, and EA.
Improve
• Identify performance level of implemented capabilities and compare to expected level required to
meet outcome.
• Review and assess how capabilities have been implemented with respect to people, procedural steps,
and asset usage.

Capability-Based Planning and Enterprise Architecture

Organizations can employ CBP without EA and vice versa. However, integrating the two paradigms can
yield greater results.
Capability-Based Planning and the TOGAF Standard

The TOGAF standard is based upon the premise that business and technology change should be defined and
planned based on architecture descriptions. The primary purpose of an architecture description in the TOGAF
standard is to:
• Define a target architecture that meets the change initiative’s objectives and supports the Architecture
Vision
• Surface architecture gaps between the baseline and target states in order to scope the work necessary
to achieve the objectives through architecture roadmapping
CBP comes into play at several points during an ADM cycle:
• Phase A of the ADM (Section 7.4.4, Evaluate Business Capabilities): Performing a capability
assessment to define the scope of a project or strategy in terms of capability increments to be realized.
• Phases B, C, and D: Architecture descriptions are used to identify and describe the capabilities that are
needed to achieve the desired goals and the vision identified in Phase A.
• Phase E of the ADM (Section 13.4.9, Identify and Group Major Work Packages): Expressing
roadmaps in terms of capability increments in order to assist in sequencing work to deliver
incremental value across one or more transition states. It can also support Phase F through the
migration plan definition in which the different work packages have to be assessed based on the
existing and required capabilities and also the metrics that need to be defined to measure business
value and perform architecture governance.
The rest of the phases can also support CBP through architecture descriptions of the different capabilities:
business, information, technology, applications, physical assets, etc. These architecture descriptions are the
base to identify the gaps in Phases E and F. These architecture descriptions can also be used to deliver impact
analysis and identify the most critical capabilities in terms of the value they deliver, their cost, risk, etc.
Figure 3 illustrates the crucial relationships between CBP, EA, and portfolio/project management (TOGAF
9.1, Chapter 32, Figure 32-4). On the left-hand side, capability management is aligned with EA. The key is
that all the architectures will be expressed in terms of business outcomes and value.

Figure 3: Capability Relationships to Strategic Plan, Architecture, and Project Portfolio from the TOGAF 9.1 Standard
Capability-Based Planning and the ArchiMate Standard

The latest version of the ArchiMate standard, Version 3.0, introduces all the necessary concepts to model
CBP. The most important addition to the standard, compared to Version 2.1, is of course the concept of
Capability. Before the introduction of this concept, the Business process, Business function, Business service,
and Business interaction concepts were used to model capabilities. Other notable additions to the language
which help support the modeling of CBP are: Resource and Course of Action (as Strategy elements), and
Outcome (as a Motivation element). Furthermore, for the assessment of capabilities, the concept of Metric is
necessary. In the ArchiMate 3.0 standard, Metric is presented as an example of how the language can be
extended by specializing existing concepts and relationships. Metric is an example specialized concept
defined by the ArchiMate 3.0 standard to be a specialization of the Driver concept.
Moreover, the introduction of the Services relationship, previously known as Used by, between Capabilities
can allow the modeling of certain dependencies between these capabilities. These dependencies can be very
important when deciding on the transformation roadmap for capabilities, and can contribute to a better usage
of available resources and to a better understanding of the underlying architecture. Last but not least, the
change made to the notation of the Assignment relationship allows us to better visualize the directionality of
the relationship between resources and capabilities, namely that a Resource is Assigned to a Capability.
It is worth noting that the Capability increment is a version/variant of the Capability concept, thus it can be
modeled as a specialization of a Capability. Furthermore, a Capability increment is a version of the
Capability with a certain performance level, at a certain point in time. Table 1 provides a summary of the
concepts we have used in this White Paper, their definition, notation, and possible relationships to other
concepts.

Table 1: Summary of the ArchiMate 3.0 Standard Concepts used in this White Paper1
Concept Definition Notation Relationship
Capability A capability represents an ability Realizes/Services a Course of

that an active structure element, action
such as an organization, person, Realized by Behavior
or system, possesses. elements
Resource A resource represents an asset Assigned to Capability

owned or controlled by an Realized by Structure
individual or organization. elements
Course of A course of action is an approach Realizes/Influences an

action or plan for configuring some Outcome
capabilities and resources of the Realized/Serviced by
enterprise, undertaken to achieve Capability
a goal.
Outcome An outcome represents an end Realized by Outcome

result that has been achieved. Realizes a Goal
Metric A metric is the extent, quantity, Specialization of the Driver

amount, or degree of something, element
as determined by measurement
or calculation.
Capability A specialization of a capability No specific notation, Specialization of the

increment realized by a specific plateau or a uses the notation of Capability element
state in the architecture that Capability
represents a stage in the
evolution of that capability.
Besides the ArchiMate 3.0 concepts presented in Figure 4, the TOGAF standard introduces the concept of
Capability Dimension. A Capability Dimension is an aspect of the capability that has to be analyzed,
assessed, and actioned in order for the capability to be realized. These aspects, in the TOGAF standard, are
grouped into People, Processes, and Material, but each industry has its own sets of dimensions to be
considered. In ArchiMate terms, these aspects can be considered as Business Actors, Business Processes,
Application Components, etc., as well as other entities from the Business, Application, Technology, and
Material Layers. People, process, and technology could be seen as resources assigned to a capability and also
as core concepts (e.g., actors, processes, and technology/application elements) that can also realize the
capability.
1
Metric is not a standard element defined by the ArchiMate 3.0 standard. It is shown in the standard as an example specialization of Driver.

Additionally, another concept that is related to CBP and capabilities is the Capability Instance. A Capability
Instance is defined in the BIZBOK® Guide (2016) as: “a specific realization of a capability, as it exists or is
envisioned to exist, in the context of a given business unit, value stream stage, or other situational context”.
Figure 4 illustrates how the Strategy elements (Capability, Resource, Course of action) are related to Core
elements and Motivation elements (Outcome, Requirement). Internal and external Behavior elements may
realize a Capability, while an Active or Passive Structure element may realize a Resource. Capabilities,
Courses of action, and Resources may realize or influence requirements (and, indirectly, also principles or
goals). A Course of action may also realize or influence an outcome (and, indirectly, also a goal).
Table 1includes an overview of these aforementioned concepts.
Figure 4: Metamodel of the Relationships between the Strategy and Motivation Elements (ArchiMate 3.0, 2016)

Capability-Based Planning Example

To illustrate our method for CBP we use the case of ArchiPharma, representing a real, but anonymized,
pharmaceutical organization. ArchiPharma is a large international pharmaceutical that has many
geographically spread locations. The organization 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 organization is facing both external pressure and internal legacy:
• There are many growing pharmaceutical organizations that are highly competitive and want to become
market leaders.
• There are many (governmental) regulations that change frequently.
• There is a large legacy application landscape.
To comply with these regulations, the business 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
put together.
The consequences of these challenges are directly influencing interactions with customers when running
daily business. For example, processes are executed slightly differently by each business unit, and as a
consequence, especially with large and international customers interacting with more than one business unit,
get heterogeneous bills. One client might appear with slightly different data in different CRM databases
managed by different business units, causing differences in addresses, names, etc. The bill itself might look
slightly different and also timing of sending, payment due dates, etc. might differ per business unit. This is
conflicting with the goal of having a professional and coherent image towards customers.
To face all the challenges mentioned above 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 organization is modeled using the ArchiMate 3.0 language and
showcasing the newly added concepts of Capability, Resource, and Course of action, complementing the
existing concepts, as provided in the following section.
It is worth mentioning that not all the techniques presented in the following sections are modeled using the
ArchiMate language. In some cases, we include figures that are generated through other means, such as
Figure 9. We also include figures which are created based on an ArchiMate model, but use a custom analysis
visualization, such as the Spider chart presented in Figure 13. Additionally, we use the ArchiMate language
extension mechanism to model certain concepts, such as Metric.
Mapping Capabilities
Upon commencement of CBP within an organization it is necessary to develop a capability model which is
then used for various planning perspectives. All capability increments across all projects are then defined

against this capability model. The enterprise can be seen as possessing a single set of capabilities, which may
gradually evolve over time. Any given capability may be decomposed into sub-capabilities, which may in
turn be further decomposed if needed. The hierarchical structure of capabilities is illustrated with a capability
model in Figure 5.
Any ability held or desired by a business would constitute a valid capability. However, these capabilities
need to be defined in such a way as to best support the intent of CBP. As an example we take the “Customer
management” capability. By defining a capability in this way we focus on what an organization does or
desires to do and we abstract from how it is actually achieved (van Gils & van Dijk, 2014). We also choose to
define the capability by using nouns (Ulrich & Rosen, 2011). One of the most important rules to follow when
designing a capability model is to be consistent in defining the capabilities that compose it (the same criteria
for selecting and naming capabilities, the same level of granularity within the same capability level, etc.).
Figure 5: Example Capability Model
Figure 5 is an excerpt of the capability model of ArchiPharma, and it does not represent their complete
capability model. Furthermore, it only shows a level 2 decomposition of their capability model. It should be
noted that Figure 5 uses the Capability concept to model the capability model as provided in the ArchiMate
3.0 standard. This concept and its notation have been incorporated as part of the ArchiMate standard.
Linking Capabilities to Motivation and Implementation
As mentioned before, CBP focuses on the planning, engineering, and delivery of capabilities that are key to
business strategy and goals of the enterprise (TOGAF 9.1, 2011). There are two main aspects to this
statement:
1. Focus on capabilities that deliver on business strategy
2. Capability realization through EA and PPM
Not all capabilities are in the same business operation category. The level of investment and commitment can
vary depending upon whether the capability is strategic, an operational imperative, or operational support-
oriented. Figure 6 illustrates the three levels of capabilities and typical characteristics (CEB, 2013).

Another source of inspiration for stratifying capabilities can be the Value Chain of Porter.2 Even though this
technique refers to activities, the classification used in the Value Chain (Primary and Support) can also be
applied to the stratification of capabilities. Furthermore, the categories of activities included in the Value
Chain can be used as inspiration for defining the capabilities included in a capability map.
• Innovation
Set the vision and goals
Strategic • Competitive differentiation
of the organization. • New markets
The primary capabilities of the • Efficiency

Operational • Cost management
organization to generate revenue
Imperatives • Margin improvement
or deliver services to citizens. • Productivity
The capabilities required to • Efficiency

Operational • Cost management
facilitate execution of the • Margin improvement
Support primary business operations. • Productivity
Figure 6: Capability Stratification
Focus on capabilities that need to be addressed in order to deliver on the business strategy. This can be done
by identifying which capabilities of an organization contribute to realizing a specific strategy. This means
that the activities of CBP can start in the later phases of strategy planning, after the strategic objectives, KPIs,
and initiatives have been determined. Business Architects, planners, and analysts may use various techniques
such as strategy maps, SWOT analysis, and value stream analysis for strategy planning. This strategic
guidance is needed to begin CBP (Taylor, 2005). Figure 7 illustrates an example strategic input for CBP. We
use the standard ArchiMate notation for Goal to represent the motivational aspects, and for Capabilities we
have chosen a custom notation.
2
See https://en.wikipedia.org/wiki/Value_chain.

Figure 7: Example Strategic Input Needed for CBP

Capabilities serve a dual role in CBP. On the one hand, they provide a high-level view of the current and
desired abilities of an organization, in relation to its strategy and environment, as can be seen in Figure 7. On
the other hand, they are realized by various behavior elements (processes, functions, services, etc.) that can
be descibed, designed, and implemented using EA approaches (ArchiMate 3.0, 2016), as can be seen in
Figure 8. PPM can help manage those projects that implement enterprise transformation in steps and
therefore the realization of the respective capability increments (Aldea et al., 2015). Figure 8 illustrates an
example of how Capabilities can be modeled and linked to elements of an EA. Similarly, the Resources of an
organization can be realized by structure elements (people, applications, etc.) that can be described, designed,
and implemented using EA approaches.
Figure 8: Example Link between Capabilities, Resources, and EA
Assessing Capabilities
As mentioned previously, one of the key goals of CBP is to formulate plans in the form of value-adding
business improvements, rather than in the form of work packages and deliverables (outcomes of a work
package). A work package represents a series of actions identified and designed to achieve specific results
within specified time and resource constraints (ArchiMate 3.0, 2016). It is therefore necessary to empirically
define value in a measurable way, so that capability increments can be defined objectively. Besides having an
objective look at the outcomes of improving a capability, defining measurements can help with assessing the

current and desired performance levels, with monitoring progress, and with evaluating the realized outcomes
of improvement (Taylor, 2005).
There may be many capabilities that are within scope. It may be useful to conduct a prioritization exercise to
determine the relative importance of the various capabilities within scope. Initial assessment can be
accomplished with qualitative approaches. Figure 9 identifies a few examples, such as Investment Priority
and Business Impact. These initial metrics will help to prioritize the capabilities for more detailed metric
quantification. In our example, we can use this type of reasoning to make the initial selection of capabilities
which can help achieve the goal of “Increase customer satisfaction” and their strategy of “Operational
excellence”. For ArchiPharma, the “Customer management” and “Financial management” capabilities are
considered to have the highest business impact.
Figure 9: Investment and Business Impact Capability Assessment Metrics
Not all capabilities need to be addressed simultaneously. Some existing capabilities may need to be improved
or completely overhauled, while some capabilities may not exist within the business and are gaps for
achieving the business strategy. Furthermore, the updated capabilities or the new capabilities may need focus
on business process or business system support to achieve success. It is also quite possible that too much
effort is being spent on particular capabilities. The ArchiMate 3.0 Specification provides several
Implementation and Migration elements which can be used to model the changes that take place during
stages or plateaus of development. Additionally, Figure 10 illustrates an example worksheet for prioritizing
and initial identification of hindrances to success.

Figure 10: Example Capability Assessment
This model evaluates how well the business executes the capability, how important the capability is to
achieving the business value proposition, and how appropriately business systems support the capability.
Each of these are scored from 0 to 5 and an indicator visually highlights the value. Additional indications of
impediments to success are identified as people, process, or assets to help with this early triage of
capabilities. An additional attribute of stakeholder (organization, individual, and role) could be added to
further identify who currently has or needs this capability.
Identifying Metrics
We recommend measuring the performance of each capability with one or more metrics. We define metric as
the extent, quantity, amount, or degree of something, as determined by measurement or calculation. In the
context of the ArchiMate standard, Metric can be seen as a specialization of Driver. Driver is defined as
something that creates, motivates, and fuels change in an organization (ArchiMate 2.1, 2013). For example,
the “Process performance” and “Information consistency” metrics could be used to measure the level of the
“Customer management” capability. An assessment of the “Customer management” capability based on the
“Process performance” metric reveals that the capability needs improvement because there are multiple and
inconsistent CRM databases. This is caused by each business unit having their own CRM database which is
inconsistent with the other business units. To address this assessment, the strategic objective to “Facilitate
resource sharing” can be formulated. The realization of this objective can positively contribute to the
“Centralize IS” strategic objective. Figure 11 illustrates this example.

Figure 11: Example Metrics for Capabilities
It is worth mentioning that the example presented in this figure is just one possible cause for the poor
performance of the “Customer management” capability. In other organizations, the performance level of the
capability could also be related to non-IT reasons, such as People, Process, and Materials.
Identified metrics should align more towards tangible benefits for more direct quantification. Intangible
benefit metrics should also be included, but should not be the majority factors. Table 2 delineates these two
major categories of metrics.
Table 2: Tangible versus Intangible Benefits
Tangible (Hard) Benefits Soft Benefits
Increased Sales Improved Customer Loyalty

Reduced Administration Costs Improved Market Penetration
Reduced Scrap Improved Decision Support
Quantifiable improvements in revenue or margin: Cost avoidance has an impact on the future budgets:
 Relate directly to financial performance  Reduced anticipated purchase
 Can track performance  Reduction in hiring
 Changes organization’s budgets Intangibles are difficult to attribute to a specific financial
metric. May not relate directly to financial performance.
Do not directly affect budgets.
Metrics can also be decomposed into multiple levels, similar to the decomposition of capabilities. The
highest-level metric is usually named the parent metric, while the lower-level metrics are named child
metrics. The parent metric usually aggregates the child metrics. The performance of a capability can be
determined with both the child metrics and the parent metrics. The performance of a capability measured by a
parent metric can also be determined by knowing only how the capability scores with the child metrics. In
these cases, the performance of a capability measured by a parent metric can be determined by using an
average of the child metrics, a sum, a minimum, or a maxim value. Figure 12 illustrates how a parent metric
can be decomposed into several child metrics.

Figure 12: Example Parent Metric Decomposition into Child Metrics
Analyzing Capability Gaps
The purpose of this step is to determine the current performance levels of each capability and compare them
to the desired levels that will help realize the strategic goals. The difference between the current and desired
levels is called a capability maturity gap. Capabilities with a lower capability level than desired or required
need to be matured over an identified time period to meet the needs of the enterprise. The capability gaps
must be established with people, process, and assets to achieve the desired outcome.
We consider that “Customer management capability increment 1” is the current version (or the needed new
capability) of the “Customer management” capability, and the “Customer management capability increment
2” is the next version of the capability, which will help realize the objectives and strategy. With this in mind,
we assess increment 1 and 2 according to the three metrics. In our example, the “Customer management
capability increment 1” scores low for the “Process performance” and “Process variance” metrics, and
medium for the “Information consistency” metric. To be in line with the organizational goals, the next
version of the capability (increment 2), should score high for the “Information consistency” and “Process
performance”, and medium for the “Process variance”. The end goal is for the capability to reach the
performance level that has been prescribed by the target state for the capability. Since there are at least three
metrics defined for this capability, and therefore for its increments, a spider chart can be made. This spider
chart (Figure 13) shows us in a more graphical way the performance levels of each capability increment.

Figure 13: Example Spider/Radar Chart with Performance Levels of Capability Increments
Organizations can use a capability heat map as a high-level method for representing capability gaps (Taylor,
2005). After assessing the relevant capabilities in the capability map and determining the desired and future
performance levels, a specific color can be assigned to their performance levels (Aldea et al., 2015). For
example, if a capability needs a lot of improvement to achieve the desired performance level, it can be
colored red. If it needs a moderate amount of improvement, it can be colored yellow. If it doesn’t need any
improvement because it already has the desired performance level, it can be colored green. In the case of
capabilities that are decomposed into sub-capabilities, the parent capability can inherit the color of the lowest
scoring sub-capability, of the highest scoring sub-capability, of the predominant color of its sub-capabilities,
or it can be determined based on a mixture of the colors of its sub-capabilities (e.g., average). Figure 14
illustrates an example capability heat map.
Figure 14: Example Capability Heat Map
Capabilities are enabled by stakeholders (in the form of organizations, business units, individuals) and
identifying the cross-reference of capabilities to stakeholder assists with planning areas such as impact
analysis, risk, and change management. Modeling the relationship between stakeholders, such as illustrated in

Figure 15, will help visually identify which stakeholders currently have or need particular capabilities.
Because individual stakeholder initiatives can be traced to a common set of capabilities, it is much easier to
identify duplicative investments and develop common solutions. In Figure 15 we use Stakeholder as a
generic term which can include organizations, business units, and individuals; thus, any actor that has some
sort of stake related to a capability.
Figure 15: Example Capability Stakeholder Map
In Figure 15, Capability 4 is associated with four stakeholders which is a higher degree of cardinality
compared to the other capabilities. This may indicate that this particular capability is core to this particular
study area and should be decomposed to lower level of capability to determine the distinct stakeholder needs.
ArchiMate modeling can also be used for stakeholder-capability analysis. Figure 16 illustrates use of the
ArchiMate 3.0 standard Motivation and Strategy elements for modeling stakeholders to capabilities.
However, the ArchiMate 3.0 specification does not allow for an influence relationship between Stakeholder
and Capability. The only relationship that can be modeled between the two concepts is association.
Nevertheless, we can still draw some conclusions from the ArchiMate model. For example, we can see that
“Customer reporting” has three association relationships with three distinct stakeholders, unlike the other
capabilities which have either one or two association relationships to distinct stakeholders. This can suggest
that “Customer reporting” might have a higher importance level than the others.
The purpose of this section is to plan the improvements of a capability. Typically, these improvements cannot
all be realized at once (i.e., in a “big bang”), 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 (TOGAF 9.1, 2011).

Figure 16: ArchiMate Example Stakeholder Capability Map
A capability roadmap can be used to sequence and plan these capability increments over time (Aldea et al.,
2015). 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 realize each
increment and avoid not having resources available because they are being used for other purposes. An
example capability roadmap can be seen in Figure 17. In this example, the “Customer management increment
2” should be completed by the end of Quarter 2 of Year 1. This version of the capability will exist until the
end of Quarter 1 of Year 2, when it will be replaced by “Customer management increment 3”.
Figure 17: Example Capability Roadmap
Figure 18 illustrates a series of capabilities and the level of maturity over a three-year period. Additionally,
this roadmap associates systems support of that capability and the composite (business and technical) risk
assigned. This inter-relationship of capabilities to EA and business outcomes illustrates the power of CBP for
tying EA, business strategy, and project portfolio together. The categories on this diagram could show the
level of business need, level of financial investment, status, or any other aspect to help with planning. The
achievement of capability increments corresponds to expected goal realization illustrated with the pie
graphic.

Figure 18: Capability Roadmap by Maturity, System Support, and Risk
Capability roadmaps are a key output of CBP work. They clearly indicate the chosen migration strategy for
realizing the target state (i.e., “big bang”, evolutionary, or incremental). In terms of EA, capability roadmaps
can be a very useful starting point for planning the architectural change. They illustrate where (i.e., in which
capabilities and at what plateaus) and what architectural changes will be required. A plateau represents a
relatively stable state of the architecture that exists during a limited period of time (ArchiMate 3.0, 2016).
Furthermore, they help link business value to work packages and architectural change. Therefore,
investments in IT can be more easily justified as necessary for achieving strategic goals. Figure 19 illustrates
and example of work packages that can realize the two capabilities “Customer management” and “Financial
management”.
Based on these relationships between capabilities, plateaus, and work packages it is possible to create a
roadmap where all these elements are present. In our example in Figure 20 , we can see that there is one work
package which helps realize the “Customer management capability increment 2”. This work package should
be completed before increment 2 of the “Customer management” capability can exist. Figure 19 illustrates
how Implementation and Migration elements, such as Work packages and Plateaus, can be related to
Capabilities. These elements can also be added to the Capability roadmap illustrated in Figure 17, in order to
express which Plateaus correspond to which Capability increment, and also which Work packages help to
realize which Capability increment.

Figure 19: Capabilities Related to Work Packages
The timeline shows in which period of time this work package is supposed to be realized, and in which
period of time a specific capability increment will exist. The example presented in Figure 20 is a simplified
version of what such a roadmap can contain (most of the relationships presented here are one-to-one
mappings). In this figure we can also see the work packages that are supposed to realize increment 3 of the
“Customer management” capability.
Figure 20: Roadmap with Work Packages Linked to the Capability they Improve
An EA will typically cover more than one business unit. Figure 21 shows a multi-business unit capability
roadmap. This example illustrates the horizontal nature of capability planning and the connective power of
this approach. The boxes within the timeline show capability by business unit along with value metrics,

financial metrics, and financial breakeven point (blue triangles). The far right identifies technical capabilities
achieved through the initiatives.
Figure 21: Goal-Based Roadmap with Capability Realization and Identified Expected Value
Based on the determined projects, several improvements to the architecture of the organization are
implemented. These improvements can be seen not only in the EA of the organization, but can also be linked
back to the capabilities that they help realize. Figure 22 illustrates how the capabilities that result after the
implementation of the projects can be modeled together with the EA that is realizing them.

Figure 22: Example EA as a Result of Capability Transformations with CBP

Conclusions
In this White Paper we have set out to achieve several goals:
1. Develop an approach for CBP: We recommend a method for CBP, which includes four main steps:
mapping capabilities, analyzing capabilities, planning capabilities, and improving capabilities. This
method can be used independently, or in combination with strategic management and EA.
2. Position this CBP method in relation to strategy and EA: Within the CBP method we present how
capabilities can be related to both strategic and EA concepts.
3. Use new concepts and viewpoints introduced in the ArchiMate 3.0 standard to support CBP
modeling: In this White Paper we have demonstrated the use of several new concepts introduced in the
ArchiMate 3.0 standard for the purpose of CBP, such as Capability, Resource, Course of Action,
Outcome, as well as Metric (as a specialization of Driver), and Capability increment (as a specialization
of Capability). We have illustrated the possible viewpoints (Capability map, Capability roadmap, etc.)
with the help of the ArchiPharma case.
4. Highlight the positioning and use of CBP within the TOGAF standard: CBP will augment
modeling and provide a more business-oriented communication for EA. Measured and planned
capabilities illustrate how the vision defined in Phase A is incrementally realized in the roadmap of
Phase E.
The recommended CBP method in this White Paper helps Enterprise Architects model what the organization
is able to do at a higher abstraction level. By using CBP, Enterprise Architects can have a common ground to
initiate discussions with business leaders in terms of business outcomes (increased output, better quality,
lower costs, revenue growth, or improved market share) instead of projects, processes, and applications
(Scott, 2009). The problem is that processes are too detailed, applications are too technical, and projects
focus on short-term results, usually without direct connection to strategic value (Aldea et al., 2015).
Using CBP as a link between strategy and EA has the following benefits.
First of all, it provides a common language all stakeholders understand. It is common that the strategy of an
organization is expressed in terms of results or expected outcomes, such as “increase revenue for product x”
or “improve the market share for product y”, whereas an EA shows the processes, products, services, and
supporting applications and technologies. There is a big language and knowledge gap between these two
domains, not to mention that usually business strategy is the playing field of a completely different group of
people to those concerned with running the operating model. Capabilities can help close this gap since they
represent familiar territory for both managers and Enterprise Architects (van Gils & van Dijk, 2014).
Second, it presents a good start for EA. Capabilities are an expression of what an organization can do. With
EA, the focus lies on how an organization can do certain things. Each capability has a specific set of
organizational resources, competences, and information that help realize it (TOGAF 9.1, 2011). In terms of
EA, these organizational resources, competences, and information can be expressed by applications,
processes, functions, and business objects. Thus, with the help of capabilities, we can link what an
organization can do with how it does it. If we consider these resources, competences, and information as part
of the architecture of an organization, we can use them to express how a specific capability is being realized,
in great detail.

Third, it helps determine the impact of strategic plans on the Enterprise. Capabilities can be linked to both
strategic plans and the implementation of these plans via EA (TOGAF 9.1, 2011) or other methods. Any
change in strategic plans might yield a change in capabilities. In turn, this means there might be changes to
the architecture of an organization. Thus, by having this connection between strategic plans and EA via
capabilities, we can determine how a change in strategy can influence the architecture of an organization.
This can help to have a clearer idea of how your organization might change in different scenarios.
Last but not least, it helps create a more flexible organization that more easily adapts to change. Planning
organizational transformation can be made easier by using capabilities. They provide a more abstract
approach to planning change by focusing on what the organization can do, rather than how. Typically, in
organizations, the processes, people, technologies, etc. are frequently subject to change, which makes it
rather difficult to make decisions based on this. By planning changes based on what the organization can do,
it can be easier to determine what needs to change, plan how to change it, and also track changes, since
capabilities are relatively stable over time (Ulrich & Rosen, 2011).

References
(Please note that the links below are good at the time of writing but cannot be guaranteed for the future.)
The following documents are referenced in or provide useful background information for this White Paper:
• A. Aldea, M.E. Iacob, J. van Hillegersberg, D. Quartel, H. Franken: Capability-Based Planning with
ArchiMate®: Linking Motivation to Implementation, paper presented at the 17th International
Conference on Enterprise Systems (ICEIS), 2015.
• ArchiMate® 2.1 Specification, an Open Group Standard (C13L), published by The Open Group,
December 2013; refer to: www.opengroup.org/bookstore/catalog/c13l.htm.
• ArchiMate® 3.0 Specification, an Open Group Standard (C162), published by The Open Group, June
2016; refer to: www.opengroup.org/bookstore/catalog/c162.htm.
• Business Architecture Guild: A Guide to the Business Architecture Body of Knowledge® (BIZBOK®
Guide), 2016; refer to: www.businessarchitectureguild.org/?page=002.
• Business Capabilities, an Open Group Guide (G161), published by The Open Group, March 2016;
refer to: www.opengroup.org/bookstore/catalog/g161.htm.
• CEB Enterprise Architecture Leadership Council: The Architect’s Business Capabilities Handbook,
2013; refer to: www.cebglobal.com.
• M.E. Iacob, D. Quartel, H. Jonkers: Capturing Business Strategy and Value in Enterprise Architecture
to Support Portfolio Valuation, paper presented at the Enterprise Distributed Object Computing
Conference (EDOC), IEEE 16th International, 2012.
• J. Scott: Business Capability Maps: The Missing Link Between Business Strategy and IT Action,
Architecture & Governance magazine, 2009.
• B. Taylor: Guide to Capability-Based Planning, paper presented at the Meeting Proceedings of RTO-
MP-SAS-055 – Analytical Support to Defence Transformation: The RTO Studies, Analysis and
Simulation Panel (SAS) Symposium, 26-28 April, 2005.
• TOGAF® Version 9.1, an Open Group Standard (G116), published by The Open Group, December
2011; refer to: www.opengroup.org/bookstore/catalog/g116.htm.
• W. Ulrich, M. Rosen: The Business Capability Map: The “Rosetta Stone” of Business/IT Alignment,
Cutter Consortium, Enterprise Architecture, 24(4), 2011.
• B. van Gils, S. van Dijk: The Practice of Enterprise Architecture/Part 1: Experiences, Techniques, and
Best Practices, BiZZdesign Academy BV, 2014.

About the Authors

Adina Aldea MSc is a Research Consultant at BiZZdesign, assigned to the R&D department. Here she works
on developing a method for improving the gap between Business and IT, with the help of strategy models,
Capability-Based Planning, Enterprise Architecture, and Project Portfolio Management. She is working on
this topic also in collaboration with the University of Twente, where she is assigned as a PhD student. Adina
has studied Business Administration at the University of Twente, where she obtained her Master’s degree.
Maria Iacob MSc PhD is currently professor at the department of Information Systems and Change
Management, at the University of Twente. She holds a PhD in Mathematics from the University Babes-
Bolyai of Cluj-Napoca, Romania. She has done research and actively published in the areas of Enterprise
Architecture design and analysis, service-oriented architectures, model-driven development, model
transformations, e-government, business process (re)engineering and management, data and process
interoperability of distributed enterprise applications, inter-organizational integration, and business modeling.
She also co-authored the ArchiMate® Specification, an Open Group standard, which is the modeling
language and international standard for Enterprise Architecture.
Marc Lankhorst MSc PhD is Managing Consultant and Service Line Manager Enterprise Architecture at
BiZZdesign. As an internationally recognized thought leader on Enterprise Architecture, he guides the
development of BiZZdesign’s portfolio of services, methods, techniques, and tools in this field. In the past,
Marc has managed the development of the ArchiMate® modeling language for Enterprise Architecture, now
an Open Group standard. Marc is a Certified TOGAF® 9 Enterprise Architect, and holds an MSc in Computer
Science from the University of Twente and a PhD from the University of Groningen in the Netherlands.
Dick Quartel MSc PhD is senior research consultant and team leader of the R&D department at BiZZdesign.
In this capacity he supports and contributes to the development of new and existing solutions, such as
Enterprise Architecture, Enterprise Portfolio Management, Capability-Based Planning, strategy modeling,
business process management, and decision management. The integrated application of these solutions is key
in “building strong organizations”, the motto of BiZZdesign. Dick holds an MSc and PhD in Computer
Science from the University of Twente in the Netherlands.
Bill Wimsatt is an Oracle Business Architect with expertise in Enterprise Architecture, strategic planning,
and business value analysis and information architecture. He helps lead development of Business
Architecture methodology and practice within Oracle’s EA framework. He has used FEA, FSAM, the
TOGAF® Framework, and SEBIS methodologies to produce Enterprise Architectures for large companies
and government organizations. His broad industry experience includes insurance, telecommunications, cable,
embedded systems, US Government, and consulting.
Acknowledgements
The authors would like to thank Henry Franken from BiZZdesign for his invaluable contribution to this
White Paper. The project that resulted in this White Paper has been initiated and envisioned by Henry, as part
of his role as a Chair of the ArchiMate Forum. His support and feedback on this topic are greatly appreciated
and have highly improved the quality of this document.

About The Open Group

The Open Group is a global consortium that enables the achievement of business objectives through IT
standards. With more than 500 member organizations, The Open Group has a diverse membership that spans
all sectors of the IT community – customers, systems and solutions suppliers, tool vendors, integrators, and
consultants, as well as academics and researchers – to:
• Capture, understand, and address current and emerging requirements, and establish policies and share
best practices
• Facilitate interoperability, develop consensus, and evolve and integrate specifications and open source
technologies
• Offer a comprehensive set of services to enhance the operational efficiency of consortia
• Operate the industry’s premier certification service
Further information on The Open Group is available at www.opengroup.org.

Capability-Based Planning

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Capability-Based Planning

Uploaded by

Copyright:

Available Formats

Capability-Based Planning

The Link between Strategy and

A White Paper by:

Copyright © 2016, The Open Group

Capability-Based Planning: The Link between Strategy and Enterprise Architecture

Published by The Open Group, November 2016.

www.opengroup.org A White P aper P ublished by The Open Group 2

Capability-Based Planning Overview ......................................... 9

Capability-Based Planning and Enterprise Architecture ........... 11

Capability-Based Planning Example ........................................ 15

About the Authors ................................................................... 34

About The Open Group ........................................................... 35

www.opengroup.org A White P aper P ublished by The Open Group 3

Boundaryless Information Flow

In this White Paper we describe how a Capability-Based Planning (CBP) method is a

www.opengroup.org A White P aper P ublished by The Open Group 4

Why is Capability-Based Planning Relevant?

The field of EA is focused on designing, planning, and implementing organizational change. An EA is a

www.opengroup.org A White P aper P ublished by The Open Group 5

• Grow Earnings Per Share (EPS)

• Increase return on IT assets

Figure 1: Capabilities are a Common Language for Business and IT Leaders

www.opengroup.org A White P aper P ublished by The Open Group 6

What is Capability-Based Planning?

A CBP approach drives questions such as:

www.opengroup.org A White P aper P ublished by The Open Group 7

• Do we want to invest more or less in this capability?

• Do we have overlapping projects?

• Do we have redundant applications, or an inadequate organizational structure?

• When do we need to incorporate industry standards?

• Are we driving towards industry standards?

The benefits of organizational-wide CBP include:

www.opengroup.org A White P aper P ublished by The Open Group 8

Capability-Based Planning Overview

Capability map Capability metrics

Capability realization Planning scenarios

Figure 2: CBP Generic Activities

www.opengroup.org A White P aper P ublished by The Open Group 9

• Identify under/over-performing capabilities and missing capabilities (gap analysis) based on

www.opengroup.org A White P aper P ublished by The Open Group 10

Capability-Based Planning and Enterprise Architecture

Capability-Based Planning and the TOGAF Standard

CBP comes into play at several points during an ADM cycle:

www.opengroup.org A White P aper P ublished by The Open Group 11

Capability-Based Planning and the ArchiMate Standard

www.opengroup.org A White P aper P ublished by The Open Group 12

Concept Definition Notation Relationship

Capability A capability represents an ability Realizes/Services a Course of

Resource A resource represents an asset Assigned to Capability

Course of A course of action is an approach Realizes/Influences an

Outcome An outcome represents an end Realized by Outcome

Metric A metric is the extent, quantity, Specialization of the Driver

Capability A specialization of a capability No specific notation, Specialization of the

www.opengroup.org A White P aper P ublished by The Open Group 13

Table 1includes an overview of these aforementioned concepts.

www.opengroup.org A White P aper P ublished by The Open Group 14

Capability-Based Planning Example

The organization is facing both external pressure and internal legacy:

• There are many (governmental) regulations that change frequently.

• There is a large legacy application landscape.

www.opengroup.org A White P aper P ublished by The Open Group 15

Figure 5: Example Capability Model

Linking Capabilities to Motivation and Implementation

1. Focus on capabilities that deliver on business strategy