1 Introduction

Linguistically, capability means the ability or qualities necessary to do something [1]. The notion of capability has been discussed throughout the past decades in application areas such as competence-based management, enterprise architecture management, developing firm’s competitive advantage [2, 3], and, lately, Business-IT alignment [4]. Following the principles for specifying the organization’s capacity and abilities to perform a business function, an approach called Capability Driven Development (CDD) has been developed [5].

CDD addresses the need for today’s information system (IS) development frameworks and methodologies to support organizations acting in highly competitive and volatile environments, e.g. dealing with unexpected events, such as unpredicted increase of customer demands, legislation changes, new customer types, new alliances and competitors. The current business trends require companies to be able to operate continuously in dynamically changing business conditions [6, 7].

The CDD methodology is based on Enterprise Modeling (EM), context modeling, variability modeling, adjustment algorithms, and patterns for capturing best practices. It is also supported by the CDD environment that allows capability design and runtime monitoring and adjustment.

Capability is used in a wide variety of approaches and frameworks and while there are clearly identifiable similarities, there are also substantial differences in its use. If CDD is to succeed in being adopted by a broader community it needs to address standardization in the respective area of development. There are four basic options to consider, namely,

  1. (1)

    to propose a new standard,

  2. (2)

    to influence an existing standard, i.e. to make it change or to incorporate a new proposal,

  3. (3)

    to align with an existing standard or standards, or

  4. (4)

    do nothing related to standards, in the hope that the industry take-up will be fast and widespread enough to establish a de-facto standard in a “grass-roots” way.

Options 1 and 2 are unrealistic to carry out without significant and probably world-wide backing of key industrial players, especially in areas where existing standards are already developed. We consider the areas of IS development and Enterprise Architecture (EA) which are the primary targets of the CDD methodology being such. Hence, applying Option 3 of analyzing the existing landscape of standards and proposing alignments of CDD with the more prominent contributions in the field is the most appropriate path to choose. For a product such as the CDD methodology and environment, Option 4 is too risky because there are a significant number of standards existing in this area.

To this end, the objective of the paper is to analyze how capability is addressed by one prominent EA framework, namely, The NATO Architecture Framework (NAF). The aim of this analysis is to show how CDD modeling components correspond to those of NAF in order to support application scenarios such as analyzing enterprise architectures documented according to NAF and then operationalizing them with CDD in order to monitor and adjust the runtime execution.

The remainder of the paper is organized as follows. Section 2 briefly presents the approaches and frameworks that use the concept of capability, including more details of CDD and NAF. The analysis of CDD and NAF concepts is provided in Sect. 3. Concluding remarks are presented in Sect. 4.

2 Background to Approaches Using Capability

The notion of capability has a growing presence in the current business and IT alignment and development frameworks. It is used by business-oriented frameworks, such as Business Architecture and Business Modeling as well as in the alignment-oriented frameworks for Enterprise Architecture (EA) and Enterprise Modeling (EM). The inclusion of the capability notion in the current development frameworks seems to have the following intensions: (a) for business planning, it is becoming recognized as a key component for describing strategies of what a core business does in order to deliver value; (b) for IS development, it makes IS designs more understandable to business stakeholders by enabling them to use the capability notion to describe their requirements; and (c) for IS run-time and maintenance, it supports configurability of operations on a higher level of abstraction than services, process, and components.

The following areas of development approaches using the concept of capability can be identified:

  • OMG Business Architecture (BA) [8]. It is an enterprise blueprint aiming to provide a common understanding of an organization, as well as to align strategic objectives with tactical demands.

  • OMG Value Delivery Modeling Language (VDML) [9]. It defines a modeling language for analysis and design of the operations of an enterprise with a focus on the creation and exchange of value.

  • The Open Group Architecture Framework (TOGAF) [10] describes architecture domains, concepts and methods for designing, using, and maintaining an enterprise architecture.

  • ArchiMate is an EA modeling language [11]. It provides an architectural approach to describe and visualize different concepts of the types: active structure, behavior, and objects, as well as it defines their relations.

  • The Department of Defense Architecture Framework (DODAF) [12] is an architecture framework for the US Department of Defense that provides visualization infrastructure for specific stakeholders concerns organized by various viewpoints.

  • The UKMinistry of Defence Architecture Framework (MODAF) [13] is an architecture framework that defines a standardized way of conducting EA originally developed by the UK Ministry of Defence.

  • The NATO Architecture Framework (NAF) [14] is an EA framework developed by NATO. It will be described in more detail in Sect. 2.2. It has many commonalities with DODAF and MODAF. A key difference is that MODAF is a description framework, i.e. it does not have its own methodology, while the latest version of NAF has a methodology based on TOGAF. Considering at least the nominal intention of NAF being used by the large number of the NATO countries we have chosen NAF for the purpose of this analysis.

  • OASIS SOA provides an abstract, foundation reference architecture addressing the ecosystem viewpoint for building and interacting within the SOA paradigm [15].

  • The Open Group SOA Reference Architecture defines a consumer and provider perspective with cross-cutting concerns describing architecture building blocks and principles that support the realizations of SOA [16].

  • SOA Modeling Language (SoaML) by OMG defining a small set of extensions to UML to support SOA modeling [17]; it can be seen as an instantiation of a subset of The Open Group’s architecture for representing SOA artifacts in UML.

A more detailed analysis of how the above frameworks address capability in terms of modeling perspective, definition, purpose, and methodology is available in [18].

2.1 Capability Driven Development Methodology

The CDD methodology consists of method components [5]. To structure the methodology, the components have been divided into upper-level method components and method extensions. Each upper-level component describes a certain application area and may also contain sub-components. The upper-level method components are currently the following:

  • Capability Design Process guiding how to design, evaluate, and develop capabilities by using process models, goal models, and other types of models.

  • Enterprise Modeling guiding the creation of enterprise models that are used as input for capability design.

  • Context Modeling analyzing the capability context and its variations needed to deal with business process variations.

  • Reuse of capability design guiding the elicitation and documentation of patterns for capability design.

  • Run-time Delivery Adjustment adjusting capability at runtime.

The overall CDD process includes three cycles (1) capability design; (2) capability delivery; and (3) capability refinement/updating. The capability design cycle often starts with Enterprise Modeling, i.e. by a business request for a new capability - the request might be initiated by strategic business planning, changes in context, or discovery of new business opportunities requiring reconfiguration of existing or the creation of new goals, business processes or services, and other EM elements. This is followed with a formalized definition of requested capabilities and definition of the relevant contexts according, linking with relevant capability delivery patterns, as well as supporting IT applications all of which as can be seen as part of capability design.

In addition, several method extensions addressing specific business challenges to which the CDD methodology have been developed.

CDD defines capability as “the ability and capacity that enable an enterprise to achieve a business goal in a certain context.” The theoretical and methodological foundations for CDD is provided by the core capability meta-model (CMM) in Fig. 1, and in details presented in [5]. The CMM is developed on the basis of requirements from the industrial project partners, and related research on capabilities. In brief, the meta-model has three main sections:

Fig. 1.
figure 1

A core meta-model for supporting Capability Driven Development [19].

Full size image
  1. (a)

    Enterprise model, representing organizational designs with Goals, KPIs, Processes (with concretizations as Process Variants), and Resources. Key aspects are capability and goal dependency as well as capability and business process dependency showing intentional and operational aspects of each capability.

  2. (b)

    Context, represented with Context Set for which a Capability is designed and Context Situation at runtime that is monitored and according to which the deployed solutions should be adjusted. Context Indicators are used for measuring the context properties (Measuring Property); and

  3. (c)

    Patterns, for delivering Capability by reusable solutions for reaching Goals under different Context Situations. Each pattern describes how a certain Capability is to be delivered within a certain Context Situation and what Processes Variants and Resources are needed to support a Context Set.

Figure 1 is a simplified version of the CMM showing only the key components of CDD and omitting, for instance, constructs for representing goal decomposition relationships and process variants. The complete version including definitions of the components is available in [5, 19].

2.2 The NATO Architecture Framework

NAF is organized into a number of views such, All Views, Capability View, Operational View, System View, Service View, Technical View, and Programme View. Capability view, further specified in models addressing detailed aspects of capability development, namely: Capability taxonomy (C1), Enterprise Vision (C2), Capability dependencies (C3), Standard Processes (C4), Effects (C5), Performance Parameters (C7), Planning Assumptions (C8), and Capability Roadmap (Cr).

NAF defines capability as “the ability of one or more resources to deliver a specified type of effect or a specified course of action” [14]. Examples of capabilities according to NAF are “Tank production, 20 tanks per year”, “Tank production, 20–40 tanks per year”, “Light Armor Vehicle Recovery”, and “Heavy Armor Vehicle Recovery”. Details of the capability definition and associations is given in the NAF meta-model [14], see Figs. 2 and 3. The key associations of capability are as follows:

Fig. 2.
figure 2

adapted from [14].

A simplified overview of the NAF meta-model,

Full size image
Fig. 3.
figure 3

adapted from [14].

NAF meta-model for view C2 Enterprise Vision,

Full size image

  • Capabilities may be specialized into more specific capabilities, composed of several capabilities, as well as dependent on other capabilities.

  • Capability when applied is associated with measurable categories

  • Capability elaborated into Capability configuration package, which is used to configure resources for capability implementation.

  • Enterprise phase exhibits a capability. The connection between capabilities and goals is realized through enduring phase of the enterprise.

  • Capability supports an enduring task by defining capability for the task.

A more detailed meta-model of the Enterprise Vision view (C2) is shown in Fig. 3 on the basis of which the analysis of CDD and NAF was performed. The purpose of a C2 view is to provide a strategic context for the capabilities described in the architecture and to specify the scope for the architecture in terms of vision, goals, enduring tasks and capabilities.

NAF is interoperable with MODAF because it is based on earlier versions of MODAF. The interactive website of the NAF meta-model also has the ability to present NAF according to MODAF views. Hence this analysis is relevant even to those countries that are not part of NATO and use, as in the case of Swedish Armed Forces, MODAF instead.

3 Analysis of CDD and NAF Concepts

NAF addresses capability in the Capability Viewpoints (C1-C8). This section will analyze the key concepts of these viewpoints as defined in the NAF meta-model (see Figs. 2 and 3) with respect to the CDD meta-model (Fig. 1).

We will analyze the concepts of the NAF meta-model that are relevant to the five key areas addressed by CDD method components, namely, Capability Design (including Enterprise Modeling), Context Modeling, Business Process and Variability Modeling, Reuse and Patterns, as well as Adjustment Algorithms. These are mostly documented in NAF viewpoints C1 to C8 and Cr. Components form these viewpoints have been analyzed only if they have direct influence on the concept of capability, i.e. NAF viewpoints addressing, for instance, services and other aspects of the architecture have been excluded from this paper.

Figure 3 shows a part of the meta-model of view C2 Enterprise Vision that have relations with capability and addresses similar components to the CMM. It uses the UML Class diagram notation; classes in color denote objectified relationships.

Table 1 shows the proposal for alignment of NAF concepts and CDD concepts. Considering the high complexity of the NAF meta-model we also indicate in which view of the meta-model the concept is chiefly used. The CDD meta-model is not structured in views although each of its method components focuses on a specific part of modeling and hence can be considered as dynamic views.

Table 1. A proposal for alignment of NAF and CDD concepts
Full size table

Table 1 shows constructs of both approaches that have similar purposes and are in principle interchangeable in the sense that they serve similar purposes. In several cases of mapping the NAF concepts to CDD the mapping would depend on the intensions of the modeling. E.g. in the case of Enduring task, since it is defined as “a specification of what the enterprise does”, it would be our primary choice of modeling it with a CDD business process on a high level of decomposition. This would support clear visibility of how the process and process variants are used to deliver a capability. Another option, however, would be to model it with an operational goal, which would make the CDD model more understandable from a strategic perspective.

The constructs of NAF cover three of the key aspects of CDD, namely, Capability Design (including Enterprise Modeling), Context Modeling, and Business Process and Variability Modeling. The forth aspect of Reuse and Patterns is not explicitly addressed by NAF, but it can be covered by developing service specifications (NAF viewpoints S1 to S8). The fifth aspect of CDD, namely, Adjustment Algorithms, is not explicitly addressed by NAF and hence additional workarounds might need to be used for instance in the Logical viewpoints.

Concerning the way of working, CDD offers well elaborated method guidance and extensive supporting material. In contrast, currently the method guidance for NAF is based on the Architecture Development Method (ADM) of TOGAF, but it is still a work in progress.

In terms of tool support CDD offers an integrated environment for capability design and runtime monitoring and adjustment while the tools that support NAF primarily focus on architecture design and documentation. The current status of the CDD environment allows adjustment and configuration of existing systems, such as ERP systems. To support cases when a new IS needs to be developed to realize capability delivery, an ongoing work on supporting capability designs with Model Driven Development is reported in [20].

4 Concluding Remarks

In this paper we have summarized how the concept of capability is used in CDD and NAF for the purpose of aligning CDD with an established EA framework. While there are differences in capability definitions, meta-models, and the way it should be modeled, both use capability to bind the intentional part of the organizational design with the operational part that also encompasses variability/alternatives.

We can conclude that NAF has a more generic scope; hence it includes more constructs for strategic planning and specification of IT architecture. CDD mostly focuses on operational capability design and execution of the adjustments. Hence CDD is more streamlined when it comes to modeling enterprise designs in terms of goals, processes, resources, and best practices (patterns). CDD also supports monitoring capability performance in terms of context elements and KPI as well as specification of adjustment algorithms that are automatically deployed in the Capability Navigation Application. While NAF defines measures of effectiveness, development of monitoring and adjustment applications can be seen as aspects of Model Driven Development, which beyond the main purpose of NAF and hence it does not explicitly support them.

The overall approach taken in the project that developed the CDD methodology has been to focus on the elaboration of proposals for CDD alignment with significant standards that are used in practice which in turn support broader adoption of CDD. The analysis performed in this paper supports the application scenario of elaborating capability designs with CDD from existing organizational designs expressed according to NAF. Such a way of working would contribute to implementing the aspects of runtime monitoring and adjustment of information systems according to context changes for which NAF currently does not offer explicit support.