Article Category: Original Study
Publicado en línea: 19 abr 2021
Páginas: 90 - 104
Recibido: 22 jun 2020
Aceptado: 05 mar 2021
DOI: https://doi.org/10.2478/jms-2021-0001
Palabras clave
© 2021 Jo Erskine Hannay et al., published by Sciendo
This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
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)
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)
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
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.
The concept of
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)
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).
A usual format for specifying epics is as follows:
Single actor epic: 〈Actor
Activities
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 epic: 〈Actors
The collaborative activities
Our method, then, is illustrated in Figure 1 and contains four steps.
Fig. 1
Steps from strategy to capabilities.
To support the transition to a capabilities-based portfolio, NATO Allied Command Transformation is developing the Consultation, Command and Control (C3) Taxonomy of capabilities
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
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.
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.
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).
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:
Specifically, we focus on the following goal:
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.
Sub-goal 2.1 is expressed summarily as:
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.
increase portion of collaborative fast planning by a factor increase collaborative use of resources by a factor
The measures
A An
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 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 coordinate the movements of units A and B, and lead A’s and B’s execution of tasks.
increase information sharing by a factor increase interoperability at user levels by a factor of
Again, the measures
A An
Integrated Planning Epic: Tactical leaders LA and LB of units A and B in separate domains integrate plans for individual disciplines by using 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
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 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 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.
obtain information in real-time, and obtain information at Mbit/s capacity.
A An
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
to get text, images, video, map overlays, messages, voice and virtual telecommunications.
From the 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
to get text, images, video, map overlays, messages, voice and virtual telecommunications.
The other back-end epic derived from the 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 task-specific services,
by using
to get text, images, video, map overlays, messages, voice and virtual telecommunications.
The services in the above epics rely on
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.
Increase training with systems for actual operations by a factor Increase local collaborative training by a factor
for placeholder measures
An A
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 Distributed Training Epic: Operational leaders and tactical leaders LA and LB in separate domains train to achieve (multi-national) collaboration by using
Increase distributed simulation-based training by a factor Decrease time to set up simulation-based training by a factor
for placeholder measures
A A
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
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
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
Decrease simulation build time by a factor Increase location-independent availability of simulations by a factor Increase time-independent availability of simulations by a factor
for placeholder measures
A A
MSaaS Discovery Epic: Service consumers discover appropriate
MSaaS Composition Epic: Service consumers compose
MSaaS Execution Epic: Service consumers run
MSaaS relies on
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 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.
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).
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