1. bookVolume 10 (2021): Issue 1 (December 2021)
Journal Details
License
Format
Journal
eISSN
1799-3350
First Published
15 Dec 2016
Publication timeframe
1 time per year
Languages
English
Open Access

Leveraging network-centric strategic goals in capabilities

Published Online: 19 Apr 2021
Volume & Issue: Volume 10 (2021) - Issue 1 (December 2021)
Page range: 90 - 104
Received: 22 Jun 2020
Accepted: 05 Mar 2021
Journal Details
License
Format
Journal
eISSN
1799-3350
First Published
15 Dec 2016
Publication timeframe
1 time per year
Languages
English
Introduction

Military strategic visions are often written in an informal style structured across many documents. For example, one nation’s army declares its vision for network-centric operations (Alberts et al. 1999) in two main documents with 70 annexes and attachments. The vision is formulated in terms of high-level characteristics that give a comprehensive overview of the vision and suggest high-level initiatives toward implementing the vision. It is, however, not at all obvious how one should operationalise such a vision into workable solutions. The consequence of an absence in progress may well be that the vision loses attention, is abandoned and is perhaps replaced by a new, more fashionable formulation of essentially the same vision. An example in point is the concept ‘NATO Network-Enabled Capability’ (NNEC)

http://www.nato.int/cps/en/natolive/topics_54644.htm

going off fashion, and where the presently in-vogue concept ‘Federated Mission Networking’ (FMN)

https://www.act.nato.int/activities/fmn

encompasses the ideas in NNEC via the more fashionably named ‘Connected Forces Initiative’

https://www.nato.int/cps/en/natohq/topics_98527.htm

(NATO Allied Command Transformation 2013). While reformulating visions may, in some instances, be beneficial, the reason for doing so should not be because no-one was able to use the vision for producing value. Moreover, if it is no easier to operationalise the new vision, one has come no further.

We argue that the lack of methodological support for transitioning from strategy to working system is the main disabler for operationalising strategic visions. Various frameworks, such as the NATO Architecture Framework (NAF)

https://www.nato.int/cps/en/natohq/topics_157575.htm?

, The Open Group Architecture Framework (TOGAF)

https://pubs.opengroup.org/architecture/togaf9-doc/arch/

and Capability Driven Design (CDD) (Sandkuhl 2015), do address the transition from strategy to a working system. These frameworks are valuable in that they structure the workflow through all the relevant layers of abstraction. In particular, they suggest the kinds of diagrams that are suitable at various levels for describing enterprise architectures, business processes, system architectures, system processes etc. Further, and more specifically for network-centric operations, the NATO NEC Command and Control (C2) Maturity Model (N2C2M2) (Alberts et al. 2010) is a framework for determining the means of implementing C2 within the concepts of the NNEC model. The N2C2M2 is designed to be used in conjunction with the NATO Code of Best Practice for C2 Assessment (COBP-C2A) and the C2 Conceptual Reference Model (C2CRM). All of these frameworks give steps and checklists for what to do and what to think about when operationalising strategic content. However, they give meagre support for eliciting and structuring the information, that is, the actual content needed at each level. For example, the N2C2M2 speaks of interaction patterns, but does not give guidelines on how to write such patterns.

As one step to address this, (Hannay et al. 2017c) suggested a requirements engineering approach, where so-called user stories are used to create cohesive story lines through levels of abstraction and detail. This effectively enables step-wise refinement and detailing of high-level descriptions into operational (human) processes and (technical) systems. This story-line approach starts at the level of so-called capabilities and works its way down to specific (human) processes and (technical) systems.

In this article, we supplement that approach with prior steps that initiate the story-line approach. In other words, we describe steps to arrive at capabilities written as user stories from strategic visions. Further, we adapt a technique for assigning benefit estimates to the resulting user stories to prioritize which capabilities to implement first. We present these steps as a method for operationalising strategic visions into capabilities. We apply the method in two cases. The first case concerns the derivation of core IT capabilities from strategic visions of network-enabled operations. The second case concerns the derivation of simulation capabilities for training from the same visions.

Method for operationalising strategic visions into capabilities

The method we present uses techniques from requirements engineering, a discipline in systems and software engineering aimed at eliciting, capturing and expressing systems requirements from people’s incomplete, but evolving, understanding of what is needed from a system under development. In this article, the systems under development are human procedural systems and information technological systems.

The basic idea of the method is to make strategic visions concrete by formulating them in terms of capabilities; here, a capability is defined as a description of the aim that one endeavours to achieve while abstracting away the concrete means to achieve it.

Capabilities

The concept of capability is central to this discussion. A capability defines an ability to perform certain actions to achieve certain outcomes (The Open Group 2011a, 2011b) and is expressed in general and abstract terms. To implement a capability, a combination of organization, people, processes and technology must be coordinated into a so-called capability configuration. However, it is important to recognise the fact that capabilities are persistent and independent of their various implementations. Therefore, a capability can be seen as an abstract requirement that has a life time in terms of strategic periods, rather than in terms of, for instance, a development project.

Capability specification

Also central to the method is the explicit formulation of capabilities in a standard format. Several notations can be used to specify capabilities, for example, modelling formats such as the Unified Modelling Language (UML)

https://www.omg.org/spec/UML/

and the Business Process Model and Notation (BPMN)

http://www.bpmn.org/

. To remain close to what operational personnel are familiar with, we choose to base our capability specifications on the textual requirements format of user stories from agile development. In particular, we use epics, which are high-level low-detailed user stories. In systems and software engineering, epics are commonly used to elicit and specify requirements from stakeholder perspectives in an intuitive manner. The format is designed to express stakeholder use cases, regarding what stakeholders want to achieve by using a process or a system. In our method, epics will be used to specify how one intends a single or multiple actors to use the capabilities. When implementing capabilities, high-level epics can be detailed and refined into more concrete user story specifications (Hannay et al. 2017c), but in our discussion, we remain at the epics level of abstraction.

Epic format

A methodological key to clarify strategic visions is to phrase capabilities in a structured manner in our framework. To this end, we use similar formats for specifying epics to those in (Hannay et al. 2017a, 2017b, 2017c).

Single actor epics

A usual format for specifying epics is as follows:

Single actor epic: 〈Actor A〉 〈performs activities a in his/her domain D〉 by using 〈capability C〉 to 〈perform tasks t

Activities a are what actor A does in his/her/its work in domain D, regardless of any systems support. A can be a group of actors. The capability C gives a systematic approach to perform work in the form of procedures, processes, information technological systems etc. The actor uses C for certain tasks t to support the activities a.

Collaboration epics

Higher network-centric maturity levels are characterised by the ability of different organisations to work together towards common goals. To capture the coordination, collaboration and coherence characterising network-centric operations, we have extended the standard single actor format into a new type of user story format that expresses a collaboration coupling to describe and reason about the collaboration between several actors explicitly. A collaboration coupling is defined as ‘two or more actors collaborating in order to reach a common goal’. The actors in a collaboration coupling may belong to different organisations and thus represent different interests and priorities. We extend the epics format to support collaboration stories as follows:

Collaboration epic: 〈Actors A and B〉 〈perform collaborative activities ca in their common domain cD〉 by using 〈capability C〉 to 〈perform tasks t

The collaborative activities ca are what actors A and B work together on, regardless of system support. A and B usually work in two different domains aD and bD, which merge into cD. The common domain, cD, may be an ad hoc domain that spontaneously constructs around the need for collaboration faced by A and B. A collaboration story specifies the roles of the participating actors in their activity.

Steps from strategy to capabilities

Our method, then, is illustrated in Figure 1 and contains four steps.

Step 1: Identify objectives. Review strategic documents to identify goal statements. Formulate measurable objectives from these goal statements. Objectives give the reason for developing capabilities and should be used to determine the expected benefit of capabilities.

Step 2: Identify capability fragments. Review strategic documents to identify text passages that appear to constitute capability fragments for the identified objectives.

Step 3: Declare capabilities. Identify existing or new capabilities from identified fragments. Identified capability fragments are either found to be subsumed in an existing capability already specified or found to give rise to a new capability.

Step 4: Specify Capabilities. Phrase the identified and categorised capabilities as single-actor or collaboration epics. Specifying capabilities in terms of epics may lead to identification of the need for further capabilities. Thus, one may conduct another increment of the method as illustrated by the dashed arrow in the figure.

Fig. 1

Steps from strategy to capabilities.

Specializing the method to the C3 taxonomy

To support the transition to a capabilities-based portfolio, NATO Allied Command Transformation is developing the Consultation, Command and Control (C3) Taxonomy of capabilities

https://www.nato.int/cps/en/natohq/topics_157573.htm?

; Figure 2 provides a high-level view.

Fig. 2

The NATO Consultation, Command and Control (C3) Taxonomy of capabilities.

The taxonomy explicitly includes, in the same picture, the operational context (Operational Context frame) and the computing context (Communication and Information Systems (CIS) Capabilities frame).

Referring to Figure 2, the operational capabilities layer declares capabilities independent of technology. The user-facing capabilities layer declares capabilities that enable users of operational capabilities to interface with CIS capabilities. The back-end capabilities declare CIS capabilities that are hidden from operational users, but that are accessed through user-facing capabilities. The service concept at the CIS layer embodies notions of integral and loosely coupled components that deliver clearly delineated functionality to a range of service consumers, including CIS user-facing applications or other CIS services. Services are essential in so-called service-oriented architecture (Erl 2007), and more recently, cloud-based architecture, where CIS services can be accessed at all times by a wide range of consumers, independently of their geographic locations.

The layers of the C3 Taxonomy are populated by capabilities in a tree structure. Through the taxonomy’s web page, one can view successively more specific capabilities by clicking on a given capability. For example, clicking on ‘Business Processes’ will eventually reveal, among others, ‘Domain-specific Operations’, in which one will find ‘Land Operations’ that contains ‘Land C2 Processes’, ‘Land Operations Planning Processes’, ‘Land Operations Assessment Processes’ etc.

Although the C3 Taxonomy is being developed for NATO capabilities, individual nations also use the structure of the taxonomy for structuring their national capabilities. This is useful not only for the sake of structuring but also to integrate national capabilities into the NATO context. However, it may also be the case that smaller-scale national capabilities might not find their counterpart, or their place in a capability group, in the C3 Taxonomy. When identifying capabilities in our method’s Step 3, one would look for relevant taxonomy capabilities in the taxonomy that might fit. If not found, one would try to find the appropriate neighbourhood in the taxonomy in which to place the new capability. Indeed, simply being explicit on the layer (operational, user-facing and back-end) to which the capability under investigation belongs is valuable, since this helps delineate a capability more clearly and ensures that it remains decoupled from concerns that should rather be dealt with in other types of capability. All this should help to avoid monolithic systems that ‘stove-pipe’ through the layers, rather than share common capabilities.

The incremental aspect of the method has special significance for the C3 Taxonomy. Following Hannay et al. (2017c), increments consist of capabilities and epics at successive layers of the C3 Taxonomy; starting perhaps at the operational level and moving down in the user-facing CIS capabilities and back-end CIS capabilities. Figure 3 illustrates the idea that declaring and specifying capabilities at the operational level triggers a need to identify, declare and specify capabilities at the user-facing CIS level, which in turn triggers a need to identify, declare and specify capabilities at the back-end CIS level. (In this discussion, we relate only to the Community of Interest (COI) backend capabilities.) Following the structure of the C3 Taxonomy should ensure the development of technical functionality as capabilities in their own right, rather than developing technical functionality solely based on a given operational capability specification. Thus, each epic, whether operational or technical, gives rise to a path of implementation into concrete processes and technical functionality that are loosely coupled to each other; see Hannay et al. (2017c) for details. The purpose of having integral technical capabilities is to counter stove-piped technical solutions that are tailored specifically to a given operational capability.

Fig. 3

Increments of the method when using the C3 Taxonomy. Operational level (pink), user-facing level (grey) and back-end COI level (orange).

Since each level has capabilities in their own right, one must consult the respective strategic visions for each level at each increment. For the same reason, each level has its own objectives. It may be the case that a nation’s strategic vision is only stated at what amounts to the operational level of the C3 Taxonomy. In that case, other relevant documents that contain strategic visions for CIS capabilities should be consulted; examples of such documents are the strategic documents in the NATO portfolio, general standards from bodies such as the Object Management Group, the Open Group etc.

The C3 Taxonomy is under constant development and re-evaluation, and many of the high-level capability groups are sparsely populated or empty. Individual analyses that come out of using our method can be provided as input to further the taxonomy development. When we identify capabilities in the two cases below, some will be similar to existing ones in the taxonomy, while others will not exist. The essential point in our analysis is to distinguish between the operational, user-facing and back-end layers.

Network-centric operations

The strategic vision with which we will illustrate our method is that of Network-Centric Operations (Alberts et al. 1999). To express this vision, NATO developed its Network Enabled Capability (NNEC) Maturity Levels.

NNEC maturity levels

The NNEC Maturity levels express process maturity. Alongside a variety of other maturity models, they are based on Humphrey’s Capability Maturity Model (CMM) (Humphrey 1988, 1989) for software development processes originally developed for the U.S. Department of Defense (Domingo 2010). The NNEC maturity level definitions are given in the upper part of Figure 4. The evolution from NNEC maturity level 1 to NNEC maturity level 5 is characterised by increasing capabilities to operate in a coordinated, collaborative and coherent manner, based on increasing organizational flexibility and dynamic sharing of resources. All this is based on sufficient communication, that is, on sufficient network ‘enabledness’.

Fig. 4

The NATO Network-Enabled Capability Maturity Levels and the NATO Networking and Information Infrastructure System Maturity Levels (abridged).

The NML levels relate to the operational capabilities level of the C3 Taxonomy. There is also a corresponding set of maturity levels for CIS capabilities. The lowermost part of Figure 4 summarises the NATO Networking and Information Infrastructure (NII) System Maturity Levels (SML) (NATO Consultation, Command and Control Agency 2007).

Cases

We now illustrate the use of single actor epics and collaboration epics together to convert high level NNEC visions into capabilities.

The two cases we present are based on actual analyses completed for a nation’s armed forces. Our recount is filtered to become unclassified and is intended for illustration only.

In both cases, we start with the following high-level vision from the nation’s plan for the development of network-enabled capabilities toward NML 4:

Increased operational capability through networked collaboration, where the purpose is to use all resources in a more flexible and coordinated way to achieve higher efficiency.

Specifically, we focus on the following goal:

Goal 2: Planning and execution: Increased ability to perform fast planning, flexible task execution and the use of integrated processes.

This goal has four sub-goals, of which we used text from two, namely, sub-goal 2.1 for Case 1 and sub-goal 2.2 for Case 2, to identify capability fragments. The sub-goals appear below in each of the two cases. Although stemming from the same overall goal, the two cases are sufficiently different to warrant inclusion in this discussion. The two cases were, in fact, initiated independently of each other, and it was through our analysis that the link to a common goal was uncovered.

The strategy documents state that the NML and SML statements (Figure 4) should be seen as part of the general basis for its visions.

Case 1 – Planning and execution of operations

Sub-goal 2.1 is expressed summarily as:

The ability to plan and execute joint operations on several levels has been established.

Figure 5 summarises the result of the analysis: Objectives, epics and capabilities (processes) are identified at the operational level (pink) in increment 1. Then, in increment 2, objectives, epics and capabilities (applications) are identified at the user-facing CIS level (grey). Increment 3 gives objectives, epics and capabilities (services) at the back-end CIS level (orange). Each level has its own objectives (but these have been omitted from the figure to avoid clutter).

Fig. 5

Case 1: Epics and the capabilities they use.

Notice how Figure 5 illustrates the fact that capabilities are used across more situations (epics) at deeper levels. This is in line with capabilities becoming increasingly generic at deeper levels of the C3 Taxonomy.

We now detail Case 1 in its three increments.

Increment 1 (operational level)

1-1: Identify objectives. From the above NML4 high-level vision, we formulated the following objectives:

increase portion of collaborative fast planning by a factor a, and

increase collaborative use of resources by a factor b.

The measures a and b and their metrics are placeholders for actual measures, which must be established when projects or development programs are initiated to implement the above visions into systems.

1-2: Identify capability fragments. Two capability fragments were identified based on sub-goal 2.1:

A planning capability fragment: The ability to plan joint operations on several levels.

An execution capability fragment: The ability to execute joint operations on several levels.

1-3: Declare capabilities. From the two capability fragments, we declared two capabilities belonging at the operational capabilities layer of the C3 Taxonomy: Joint Operations Planning Processes and Joint Operations Execution Processes.

1-4: Capability specification. The main instrument for identifying capabilities is in the formulation of epics. We formulated epics by studying established national tactical scenarios for more concrete perceptions of how the capabilities should be used.

The two operational capabilities were identified in the following collaboration epics:

Operations Planning Epic: Operational leaders and tactical leaders plan joint operations by using the Joint Operations Planning Processes to integrate plans for individual disciplines.

Operations Execution Epic: Tactical leaders LA and LB of units A and B in separate domains lead the coordinated execution of a plan that involves A and B by using Joint Operations Execution Processes to accomplish the following objectives, namely:

coordinate the movements of units A and B, and

lead A’s and B’s execution of tasks.

Increment 2 (user-facing CIS level)

2-1: Identify objectives. SML4 (Figure 4) implies that ‘interoperability’ and ‘information sharing’ are objectives to be reached through domain data and meta-data models and through improved data and meta-data sharing among independent applications. We therefore formulate the following objectives at the user-facing CIS level:

increase information sharing by a factor c, and

increase interoperability at user levels by a factor of d.

Again, the measures c and d and their metrics are placeholders for actual measures to be established at project-initiation time.

2-2: Identify capability fragments. Based on the identified capability fragments at the operational level, we derived the following capability fragments at the user-facing capability level:

A planning-support capability fragment: The ability to support users in planning joint operations on several levels.

An execution-support capability fragment: The ability to support users in executing joint operations on several levels.

2-3: Declare capabilities. We declared two user-facing CIS capabilities, namely Joint Operations Planning Applications and Joint Operations Execution Applications.

2-4: Capability specification. The user-facing capabilities were specified in the following user-facing epics:

Integrated Planning Epic: Tactical leaders LA and LB of units A and B in separate domains integrate plans for individual disciplines by using Joint Operations Planning Applications to perform the following tasks, namely:

problem and mission analysis,

courses of action development, validation and decision,

concept and plan development and

assessment and plan review.

Following (Hannay et al. 2017c), the 〈... tasks t in C〉 epics at one level become the 〈... activities a in their domain D〉 in related epics at lower levels in the taxonomy. Thus, for the Operations Planning Epic, the Joint Operations Planning Process capability is used to ‘integrate plans for individual disciplines’. The latter is then the domain activity in the Integrated Planning Epic.

Similarly, the Operations Execution Epic gave rise to one user-facing capability used in two user-facing epics, one for each of two sub-tasks required when executing an operation:

Coordination Epic: Tactical leaders LA and LB of units A and B in separate domains coordinate the movements of units A and B by using Joint Operations Execution Applications to:

create common situational awareness between A and B,

exchange information about the plan execution and the battlefield and

coordinate task execution between A and B.

Lead Task Epic: Tactical leaders LA and LB of units A and B in separate domains lead A’s and B’s execution of tasks by using Joint Operations Execution Applications to:

create and issue tasks that execute A’s and B’s part of the plan on time and

track the execution of the tasks in A and B.

Increment 3 (back-end CIS level)

3-1: Identify objectives. The SML4 description in 4 describes the use of advanced collaborative tools that support vertical and horizontal collaboration. Based on this system-level goal, we formulate the following objectives for the back-end CIS level:

obtain information in real-time, and

obtain information at Mbit/s capacity.

3-2: Identify capability fragments. Based on the identified capability fragments at the user-facing level, we derived the following capability fragments at the back-end capability level:

A planning-service capability fragment: The provision of services that provide back-end functionality for planning operations on several levels.

An execution-service capability fragment: The provision of services that provide back-end functionality for executing joint operations on several levels.

3-3: Declare capabilities. We declared six back-end CIS capabilities: Operations Planning Services (OPS), Tasking and Order Services (TOS), Battlefield Information Services (BIS), Situation Awareness Services (SAS), Communication and Collaboration Services (CS) and Task-specific services (TSS). The task-specific services are a placeholder for services that are intended to be uncovered at later stages of development and detailing.

3-4: Capability specification. Further elaborations on the tactical scenarios gave rise to three back-end epics. The Planning epic was derived from the Joint Operations Planning Applications. This epic contains the steps that constitute the planning process and the functional services that users rely on to ensure that such steps are effectively performed.

Planning Epic: A service consumer performs:

problem and mission analysis,

courses of action development, validation and decision,

concept and plan development and

assessment and plan review

by using

Operations Planning Services (OPS),

Battlefield Information Services (BIS) and

Situation Awareness Services (SAS)

to get text, images, video, map overlays, messages, voice and virtual telecommunications.

From the Joint Operations Execution Applications, two back-end epics were derived. The first is the Common Situational Awareness Epic, which addresses the problems faced by several operational leaders who need to establish common situational awareness between them and with other leaders.

Common Situational Awareness Epic: A service consumer—

creates common situational awareness between A and B, and

exchanges information about the plan execution and the battlefield

by using

Battlefield Information Services (BIS) and

Situation Awareness Services (SAS)

to get text, images, video, map overlays, messages, voice and virtual telecommunications.

The other back-end epic derived from the Joint Operations Execution Applications is the Tasking Epic, which describes the steps involved in creating and performing the tasks which execute plan and the supporting functional services:

Tasking Epic: A service consumer

creates and issues tasks that execute A’s and B’s part of the plan on time,

tracks the execution of the tasks in A and B and

coordinates task execution between A and B

by using

task-specific services,

Tasking and Order Services (TOS),

Battlefield Information Services (BIS) and

Situation Awareness Services (SAS)

to get text, images, video, map overlays, messages, voice and virtual telecommunications.

The services in the above epics rely on CS, which is indicated in Figure 5 as a C3 Taxonomy Core Service capability (violet), but which we do not elaborate here.

Case 2 training

Sub-goal 2.2 can be summarised as ‘Training and operations is integrated, and performed in collaboration networks’. Figure 6 summarises the result of the analysis with three increments (objectives omitted). Notice again how capabilities are used across more situations (epics) at deeper levels.

Fig. 6

Case 2: Epics and the capabilities they use MSaaS, modelling and simulation as a service.

Increment 1 (operational level)

1-1: Identify objectives: From the above vision statements, we more or less directly formulated the following objectives:

Increase training with systems for actual operations by a factor g

Increase local collaborative training by a factor h

for placeholder measures g and h.

1-2: Identify capability fragments: Two capability fragments were identified based on sub-goal 2.2:

An integrated training capability fragment: The ability to integrate training with operational systems.

A distributed training capability fragment: The ability to train collaboration from different locations.

1-3: Declare capabilities: Based on the two capability fragments, two corresponding operational capabilities were identified; these are the Integrated Training Processes and the Distributed Training Processes.

1-4: Capability specification: Similarly, as for the analysis for sub-goal 2.1, we formulated epics by studying established national tactical scenarios.

We formulated the following operational epics:

Integrated Training Epic: Operational leaders and tactical leaders LA and LB in different domains A and B train to achieve (multi-national) collaboration by using Integrated Training Processes to engage in training using the systems they use in real operations.

Distributed Training Epic: Operational leaders and tactical leaders LA and LB in separate domains train to achieve (multi-national) collaboration by using Distributed training processes to engage in collaboration training from their home base.

Increment 2 (user-facing CIS level)

2-1: Identify objectives: The nation’s strategy on network-enabled capabilities did not address simulation technology specifically, but SML4 and relevant documents such as the NATO Modelling & Simulation Master Plan (NATO Modelling and Simulation Group 2012) imply the following objectives:

Increase distributed simulation-based training by a factor i

Decrease time to set up simulation-based training by a factor j

for placeholder measures i and j.

2-2: Identify capability fragments: From the MSaaS reference architecture (Hannay and van den Berg 2017), in addition to the above strategic documents, we identified these capability fragments:

A simulation-based training capability fragment: The ability to support users to partake in simulation-based training

A simulations building capability fragment: The ability to support exercise managers to build simulation-based training.

2-3: Declare capabilities: We declared three user-facing CIS capabilities Distributed Simulation-Based Training Applications, Simulation Security Applications and MSaaS Portal Applications.

2-4: Capability specification: The user-facing capabilities were specified in the following user-facing epics:

Distributed Simulation-Based Training Epic: Operational leaders and tactical leaders LA and LB in different domains engage in distributed training using the systems they use in real operations by using Distributed Simulation-Based Training Applications to engage in training in those corporeal or virtual locations where operational systems interact with simulations.

The next two epics are for exercise managers, who are not personnel under training. Figure 6 has operational epics only for personnel under training, and the two epics, therefore, mark the start of the story-line for the exercise managers.

The first epic here pertains to the challenges of information flow between operational systems and (distributed) simulation systems that operate in different security domains (Möller et al. 2012). For example, when coupling a highly classified fighter jet flight simulator with an army tactical engagement simulator for training close air support to land forces, the high-fidelity simulation data necessary to train flight skills would be contained within the flight simulator, and only information at the lower classification level of the army simulation system would be shared.

Simulation Security Epic: Exercise managers E1 and E2 in separate domains manage security issues in (distributed) simulations by using Simulation Security Applications to set up cross-domain solutions and multilevel security.

The next epic engages the modelling & simulation as a service (MSaaS) paradigm (Hannay and van den Berg 2017; van den Berg et al. 2018), which envisions the rapid composition of simulations from a repository of common standardised simulation services. An MSaaS portal gives tool support for (technically skilled) exercise managers to build such simulations.

MSaaS Portal Epic: Exercise managers E1 and E2 in separate domains tailor distributed simulation-based training for the training objectives at hand by using MSaaS Portal Applications to discover appropriate Simulation Services, compose them to Composed Simulation Services and execute them.

Increment 3 (back-end CIS level)

3-1: Identify objectives: Documents such as the Allied Framework for Modelling and Simulation as a Service (MSaaS) Governance Policies (NATO Standardization Office 2018) imply the following objectives for our purposes:

Decrease simulation build time by a factor k

Increase location-independent availability of simulations by a factor l

Increase time-independent availability of simulations by a factor m

for placeholder measures k, l and m. Simulation build time is the duration it takes to put together a simulation from scratch or from components, perhaps using an off the-shelf general-purpose simulation framework. Today, this build time is often unacceptably long.

3-2: Identify capability fragments: Based on the MSaaS reference architecture (Hannay and van den Berg 2017), we derived the following capability fragments at the back-end capability level:

A simulations enabling service capability fragment: The provision of services that provide back-end support functionality for simulations.

A simulations services capability fragment: The provision of services that provide simulations.

3-3: Declare capabilities: We declared the capabilities MSaaS Infrastructure Services, Simulation Services, Composed Simulation Services and Cloud Infrastructure Services.

3-4: Capability specification: We formulated the following back-end epics. They rely on the MSaaS reference architecture (Hannay and van den Berg 2017), which declares simulation functionality as simulation services to be combined into composed simulation services, that when executed, produce (distributed) simulations. The discovery, composition and execution are facilitated by MSaaS Infrastructure Services (Hannay et al. 2020).

MSaaS Discovery Epic: Service consumers discover appropriate Simulation Services by using MSaaS Infrastructure Services to search for simulation functionality in cloud repositories using service descriptions and meta-data.

MSaaS Composition Epic: Service consumers compose Simulation Services to Composed Simulation Services by using MSaaS Infrastructure Services to put together simulation functionality using service descriptions and meta-data.

MSaaS Execution Epic: Service consumers run Composed Simulation Services with cross-domain solutions and multilevel security by using MSaaS Infrastructure Services to execute simulations in (distributed) cloud environments.

MSaaS relies on Cloud Infrastructure Services (Kratzke and Siegfried 2020; Kratzke 2018; Kratzke and Quint 2017), indicated in Figure 6 as a C3 Taxonomy Core Service capability (violet), but which we do not elaborate here.

Prioritising epics on objectives

Epics in the form above should represent minimum viable products (Lenarduzzi and Taibi 2016), that is, a unit of integral functionality that can be deployed own its own and give value to the organisation. To prioritise which epics to develop in what order, one can assess how much epics contribute to a given set of objectives (Hannay et al. 2017a, 2017b).

Here, we adapt that assessment method to work with our layered structure of epics. Although this has not yet been done by the nation’s strategic staff, Figure 7 illustrates, with fictitious numbers, how our epics can be assessed according to the extent to which they are expected to contribute to our objectives. (For now, the numbers on the white background can be ignored.) Using the Fibonacci numbers for relative assessment as is common from planning poker (Cohn 2005), one can assign benefit points.

Planning poker is a group estimation technique in which stake-holders present their cost estimates by displaying cards from a deck that feature the Fibonacci numbers. The highest and lowest bidders explain their rationale and another bidding round commences. The process continues until bids are consistent, signaling that group consensus has been reached. This technique has lately been adopted to benefit estimation as well.

For example, the Operations Planning Epic is estimated to contribute much more (34) to the objective ‘Increase collaborative fast planning’ than the other operational epics (8, 2, 2, respectively). Epics at a given level are assessed on the corresponding level’s objectives as indicated in the pink, grey and orange quadrants in the table.

Fig. 7

Benefit points: Epics’ contributions to objectives. Operational level (pink), user-facing level (grey) and back-end level (orange). Fictitious example.

Further, we can also account for the fact that objectives at lower levels will usually affect objectives at higher levels. Figure 8 illustrates how objectives at the user-facing level affect objectives at the operational level and how objectives at the back-end level affect objectives at the user-facing level. For example, any effect that an epic might have on the metric of ‘Increase information sharing’ is expected to also give a 0.5 per unit effect on the metric of ‘Increase collaborative fast planning’. This gives rise to the indirect contributions of epics on objectives, as illustrated by the numbers in the white off-diagonal quadrants in Figure 7. (For example, the user-facing CTS Integrated Planning Epic contributes indirectly 17.5 = 0.5 · 21 + 0.2 · 34 + 0.1 · 2 + 0 1 · 0 to the operational objective ‘Increase collaborative fast planning’).

Fig. 8

Lower-level objectives’ contributions to higher-level objectives. Fictitious example.

Taken together, the direct and indirect contributions give a benefit score for each epic in the sum column in Figure 7. In this fictitious example, if one wanted to produce as much value as soon as possible, one might start by implementing the MSaaS Portal Epic, followed by the Integrated Planning Epic and the MSaaS Composition Epic. When stakeholders state dependencies as in Figure 8, the effect can be that lower level capabilities should be developed first, as in this example. However, stake-holders might express lower dependencies and higher integral benefits of, for example, operational epics, which would reflect more technology-independent benefits associated with operational capabilities. This might lead to a conclusion that certain operational epics should be developed first, regardless of technology. Such elaborations are crucial in making conscious and deliberate choices regarding the order of development.

If one also has cost estimates for epics, perhaps in the form of story points (Cohn 2005), one can combine benefit points and story points into a benefit/cost index and realise those epics first that give the highest benefit-to-cost ratio (Hannay et al. 2017b). This enables stake-holders and sponsors to engage in benefits management (Ward and Daniel 2015).

The final aspect to be noted is the manner by which the two cases represent modest collections of epics that implement clearly delineated specific sub-goals at a time in a vision. This—we state quite distinctly—is the only way to proceed when developing large defence portfolios (Hannay et al. 2017c).

Final remarks

The main contribution of this work is to establish a link from unstructured strategic documents to formatted descriptions in an existing structure. In this article, we used the structure of the C3 taxonomy of capabilities.

A further contribution is to show how techniques from agile practices, requirements engineering and benefits management can help to delineate manageable-sized portfolios of functionality that can be realised to yield high benefit at an early stage. We view methodological efforts such as these as being vital for the success of implementing strategic visions. Experience shows that the lack of such methods may lead to a substantial waste of effort and failure to accomplish the vision and goals of defence on time.

The method described in this article is intended to aid in operationalising strategic visions. The key to this is the phrasing of a vision into capabilities, where a capability is a well-delineated piece of operational or technical functionality. To facilitate the identification of capabilities, tactical scenarios can be studied to phrase narratives (epics) that indicate how these capabilities are used.

We demonstrated how to use the method in two cases. The two cases also indicate the extent of usability of the method. Further experience is needed to establish and refine usability. However, at this point, we would claim that any method that helps to structure visions and strategic ideas into manageable parts for implementation, is better than the approach that is presently being followed in many projects and programs, namely to hold one’s breath and rely on some sort of good fortune in crossing the chasm between strategic vision and implementation.

Fig. 1

Steps from strategy to capabilities.
Steps from strategy to capabilities.

Fig. 2

The NATO Consultation, Command and Control (C3) Taxonomy of capabilities.
The NATO Consultation, Command and Control (C3) Taxonomy of capabilities.

Fig. 3

Increments of the method when using the C3 Taxonomy. Operational level (pink), user-facing level (grey) and back-end COI level (orange).
Increments of the method when using the C3 Taxonomy. Operational level (pink), user-facing level (grey) and back-end COI level (orange).

Fig. 4

The NATO Network-Enabled Capability Maturity Levels and the NATO Networking and Information Infrastructure System Maturity Levels (abridged).
The NATO Network-Enabled Capability Maturity Levels and the NATO Networking and Information Infrastructure System Maturity Levels (abridged).

Fig. 5

Case 1: Epics and the capabilities they use.
Case 1: Epics and the capabilities they use.

Fig. 6

Case 2: Epics and the capabilities they use MSaaS, modelling and simulation as a service.
Case 2: Epics and the capabilities they use MSaaS, modelling and simulation as a service.

Fig. 7

Benefit points: Epics’ contributions to objectives. Operational level (pink), user-facing level (grey) and back-end level (orange). Fictitious example.
Benefit points: Epics’ contributions to objectives. Operational level (pink), user-facing level (grey) and back-end level (orange). Fictitious example.

Fig. 8

Lower-level objectives’ contributions to higher-level objectives. Fictitious example.
Lower-level objectives’ contributions to higher-level objectives. Fictitious example.

Alberts, D. S., Garstka, J. J., & Stein, F. P. (1999). Network centric warfare: Developing and leveraging information superiority. CCRP Publication Series. DoD Command and Control Research Program. AlbertsD. S. GarstkaJ. J. SteinF. P. 1999 Network centric warfare: Developing and leveraging information superiority CCRP Publication Series. DoD Command and Control Research Program. Search in Google Scholar

Alberts, D. S., Huber, R. K., & Moffat, J. (2010). NATO NEC C2 maturity model. Technical Report, DoD Command and Control Research Program. AlbertsD. S. HuberR. K. MoffatJ. 2010 NATO NEC C2 maturity model Technical Report, DoD Command and Control Research Program. Search in Google Scholar

Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall, Upper Saddle River, NJ, USA. CohnM. 2005 Agile Estimating and Planning Prentice Hall Upper Saddle River, NJ, USA Search in Google Scholar

Domingo, A. (2010). On the Development of a Maturity Model and Maturity Levels for NATO Network Centric Capability, Allied Command Transformation. DomingoA. 2010 On the Development of a Maturity Model and Maturity Levels for NATO Network Centric Capability Allied Command Transformation Search in Google Scholar

Erl, T. (2007). SOA Principles of Service Design. Prentice Hall, Upper Saddle River, NJ, USA. ErlT. 2007 SOA Principles of Service Design Prentice Hall Upper Saddle River, NJ, USA Search in Google Scholar

Hannay, J. E., & van den Berg, T. W. (2017). The NATO MSG-136 reference architecture for M&S as a service. In: Proceedings of NATO Modelling and Simulation Group Symposium on M&S Technologies and Standards for Enabling Alliance Interoperability and Pervasive M&S Applications (STO-MPMSG-149), 19–20 October 2017, Lisbon, Portugal. NATO Science and Technology Organization, paper 13. HannayJ. E. van den BergT. W. 2017 The NATO MSG-136 reference architecture for M&S as a service In: Proceedings of NATO Modelling and Simulation Group Symposium on M&S Technologies and Standards for Enabling Alliance Interoperability and Pervasive M&S Applications (STO-MPMSG-149) 19–20 October 2017 Lisbon, Portugal NATO Science and Technology Organization, paper 13. Search in Google Scholar

Hannay, J. E., Benestad, H. C., & Strand, K. (2017a). Benefit points—the best part of the story. IEEE Software, 34(3), pp. 73–85. HannayJ. E. BenestadH. C. StrandK. 2017a Benefit points—the best part of the story IEEE Software 34 3 73 85 10.1109/MS.2017.66 Search in Google Scholar

Hannay, J. E., Benestad, H. C., & Strand, K. (2017b). Earned business value management—see that you deliver value to your customer. IEEE Software, 34(4), pp. 58–70. HannayJ. E. BenestadH. C. StrandK. 2017b Earned business value management—see that you deliver value to your customer IEEE Software 34 4 58 70 10.1109/MS.2017.105 Search in Google Scholar

Hannay, J. E., Brathen, K., & Mevassvik, O. M. (2017c). Agile requirements handling in a service-oriented taxonomy of capabilities. Requirements Engineering, 22(2), pp. 289–314. HannayJ. E. BrathenK. MevassvikO. M. 2017c Agile requirements handling in a service-oriented taxonomy of capabilities Requirements Engineering 22 2 289 314 10.1007/s00766-016-0244-8 Search in Google Scholar

Hannay, J. E., van den Berg, T. W., Gallant, S., & Gupton, K. (2020). Modeling and simulation as a service infrastructure capabilities for discovery, composition and execution of simulation services. The Journal of Defense Modeling and Simulation: Applications, Methodology, Technology, 2020. doi: 10.1177/1548512919896855. HannayJ. E. van den BergT. W. GallantS. GuptonK. 2020 Modeling and simulation as a service infrastructure capabilities for discovery, composition and execution of simulation services The Journal of Defense Modeling and Simulation: Applications, Methodology, Technology 2020 10.1177/1548512919896855 Open DOISearch in Google Scholar

Humphrey, W. S. (1988). Characterizing the software process: A maturity framework. IEEE Software, 5(2), 73–79. doi: 10.1109/52.2014. HumphreyW. S. 1988 Characterizing the software process: A maturity framework IEEE Software 5 2 73 79 10.1109/52.2014 Open DOISearch in Google Scholar

Humphrey, W. S. (1989). Managing the Software Process. SEI Series in Software Engineering. Addison-Wesley Professional, Reading, Massachusetts, USA. HumphreyW. S. 1989 Managing the Software Process SEI Series in Software Engineering. Addison-Wesley Professional Reading, Massachusetts, USA Search in Google Scholar

Kratzke, N. (2018). A brief history of cloud application architectures. Applied Sciences, 8(8), paper 1368. KratzkeN. 2018 A brief history of cloud application architectures Applied Sciences 8 8 paper 1368. 10.3390/app8081368 Search in Google Scholar

Kratzke, N., & Quint, P.-C. (2017). Understanding cloud-native applications after 10 years of cloud computing – A systematic mapping study. Journal of Systems and Software, 126, pp. 1–16. KratzkeN. QuintP.-C. 2017 Understanding cloud-native applications after 10 years of cloud computing – A systematic mapping study Journal of Systems and Software 126 1 16 10.1016/j.jss.2017.01.001 Search in Google Scholar

Kratzke, N., & Siegfried, R. (2020). Towards cloud-native simulations lessons learned from the front-line of cloud computing. The Journal of Defense Modeling and Simulation: Applications, Methodology, Technology. doi: 10.1177/1548512919895327. KratzkeN. SiegfriedR. 2020 Towards cloud-native simulations lessons learned from the front-line of cloud computing The Journal of Defense Modeling and Simulation: Applications, Methodology, Technology 10.1177/1548512919895327 Open DOISearch in Google Scholar

Lenarduzzi, V., & Taibi, D. (2016). MVP explained: A systematic mapping study on the definitions of minimal viable product. In: 2016 42th Euromicro Conference on Software Engineering and Advanced Applications (SEAA) Aug. 31 – Sept. 2 2016, Limassol, Cyprus, pp. 112–119. LenarduzziV. TaibiD. 2016 MVP explained: A systematic mapping study on the definitions of minimal viable product In: 2016 42th Euromicro Conference on Software Engineering and Advanced Applications (SEAA) Aug. 31 – Sept. 2 2016 Limassol, Cyprus 112 119 10.1109/SEAA.2016.56 Search in Google Scholar

Möller, B., Croom-Johnson, S., Hartog, T., Huiskamp, W., Verkoelen, C., Jones, G., et al. (2012). Security in NATO collective mission training—problem analysis and solutions. In: Proceedings of 2012 Spring Simulation Interoperability Workshop (SIW), March 26 – 30, 2012, Orlando, Florida, USA, number 12S-SIW-032. Simulation Interoperability Standards Organization. MöllerB. Croom-JohnsonS. HartogT. HuiskampW. VerkoelenC. JonesG. 2012 Security in NATO collective mission training—problem analysis and solutions In: Proceedings of 2012 Spring Simulation Interoperability Workshop (SIW) March 26 – 30, 2012 Orlando, Florida, USA number 12S-SIW-032. Simulation Interoperability Standards Organization. Search in Google Scholar

NATO Allied Command Transformation (2013). Report of the NATO Network Enabled Capability (NNEC) Conference 23 to 25 April 2013. Technical Report. NATO Allied Command Transformation 2013 Report of the NATO Network Enabled Capability (NNEC) Conference 23 to 25 April 2013 Technical Report. Search in Google Scholar

NATO Consultation, Command and Control Agency (2007). Report on the Development of the Initial NNEC Maturity Levels and its Applications. Technical Report NC3A-BE/CIS/IPT-1/07/001. NATO Consultation, Command and Control Agency 2007 Report on the Development of the Initial NNEC Maturity Levels and its Applications Technical Report NC3A-BE/CIS/IPT-1/07/001. Search in Google Scholar

NATO Modelling and Simulation Group (2012). NATO Modelling and Simulation Master Plan (version 2.0), 2012. Doc. no. AC/323/NMSG(2012)-015. NATO Modelling and Simulation Group 2012 NATO Modelling and Simulation Master Plan (version 2.0) 2012. Doc. no. AC/323/NMSG(2012)-015. Search in Google Scholar

NATO Standardization Office (2018). AMSP-02 Allied Framework for Modelling and Simulation as a Service (MSaaS) Governance Policies, edition (a), version 1.0. Technical Report STANREC 4794. NATO Standardization Office 2018 AMSP-02 Allied Framework for Modelling and Simulation as a Service (MSaaS) Governance Policies, edition (a), version 1.0 Technical Report STANREC 4794. Search in Google Scholar

Sandkuhl, K. (2015). Investigating the potential of capability-driven design and delivery in an SME case study. In: Persson, A., & Stirna, J. (eds.), Advanced Information Systems Engineering Workshops, Stockholm, Sweden, June 8–9, 2015, Volume 215 of Lecture Notes in Business Information Processing, Springer, pp. 3–14. SandkuhlK. 2015 Investigating the potential of capability-driven design and delivery in an SME case study In: PerssonA. StirnaJ. (eds.), Advanced Information Systems Engineering Workshops, Stockholm, Sweden, June 8–9, 2015, Volume 215 of Lecture Notes in Business Information Processing Springer 3 14 10.1007/978-3-319-19243-7_1 Search in Google Scholar

The Open Group (2011a). SOA Reference Architecture Technical Standard. Doc. No. C119. The Open Group 2011a SOA Reference Architecture Technical Standard Doc. No. C119. Search in Google Scholar

The Open Group (2011b). TOGAF Version 9.1 Enterprise Edition. Doc. No. G116. The Open Group 2011b TOGAF Version 9.1 Enterprise Edition Doc. No. G116. Search in Google Scholar

van den Berg, T. W., Huiskamp, W., Siegfried, R., Lloyd, J., Grom, A., & Phillips, R. (2018). Modelling and simulation as a service: Rapid deployment of interoperable and credible simulation environments – An overview of NATO MSG-136. In: Proceedings of 2018 Winter Simulation Innovation Workshop, Number 18W-SIW-018. Simulation Interoperability Standards Organization. van den BergT. W. HuiskampW. SiegfriedR. LloydJ. GromA. PhillipsR. 2018 Modelling and simulation as a service: Rapid deployment of interoperable and credible simulation environments – An overview of NATO MSG-136 In: Proceedings of 2018 Winter Simulation Innovation Workshop Number 18W-SIW-018. Simulation Interoperability Standards Organization. Search in Google Scholar

Ward, J., & Daniel, E., eds. (2015). Benefits Management: How to Increase the Business Value of Your IT Projects, 2nd edn. John Wiley Sons, Ltd, Hoboken, New Jersey, USA. WardJ. DanielE. eds. 2015 Benefits Management: How to Increase the Business Value of Your IT Projects 2nd edn John Wiley Sons, Ltd Hoboken, New Jersey, USA Search in Google Scholar

Recommended articles from Trend MD

Plan your remote conference with Sciendo