MINISTRY OF DEFENCE. MOD Architectural Framework Concepts & Doctrine Community of Interest Deskbook

Transcription

1 MODAF- M10-013a MINISTRY OF DEFENCE MOD Architectural Framework Concepts & Doctrine Community of Interest Deskbook Version August 2005 Prepared by:- Approved by:- MODAF Project Review Board CROWN COPYRIGHT THIS DOCUMENT IS THE PROPERTY OF HER BRITANNIC MAJESTY S GOVERNMENT. This material (other than the Royal Arms and departmental or agency logos) may be reproduced free of charge in any format or medium provided it is reproduced accurately and not used in a misleading context. Where this material is being republished or copied to others, the source of the material must be identified and the copyright status acknowledged. For further information on Crown Copyright policy and licensing arrangements, see the guidance featured on the HMSO website

2 RECORD OF CHANGES This page will be updated and re-issued with each amendment. It provides an authorisation for the amendment and a checklist to the current amendment number. Issue No. Date Revision Details Version August 2005 First MODAF baseline release Disclaimer Following review it has been decided that, to better reflect its intended audience and to avoid confusion with the Acquisition Process, the Acquisition Community of Interest (COI) Deskbook is to be renamed the Integrated Project Team (IPT) COI Deskbook. This change is immediate; all references in the MODAF documentation to the Acquisition COI Deskbook should be interpreted as the Integrated Project Team COI Deskbook. This change will be reflected in the MODAF documentation at the next update. MODAF-M10-013a Version 1.0 2

3 MODAF Concepts & Doctrine Deskbook Table of Contents Foreword Introduction Enterprise Architectures and Frameworks This Deskbook Background What is MODAF? Guide to Deskbook Purpose Approach Context Deskbook Structure MODAF Relationship to Concepts & Doctrine Processes and Activities Architecture Development Process Six-Stage Architecture Development Process Architectural Data Sources Application to Concepts & Doctrine Process Overview of MODAF View use Ensuring Views are MODAF compliant Concepts & Doctrine Processes Policy Capability Identification Future Capability Reconciliation Analytical Concepts Concept Generation Capability Development and Assessment Applied Concepts Capability Selection and Endorsement CADMID Validation and Oversight / LOD Oversight In-Service Development of Doctrine Worked Example Document Maintenance Bibliography MODAF-M10-013a Version 1.0 3

4 Table of Figures Figure 1-1: Enterprise Architecture Views...7 Figure 2-1: MODAF Viewpoints...9 Figure 2-2: MODAF 1.0 Baseline Products...11 Figure 2-3: Community of Interest Deskbook Scope...12 Figure 3-1: General Process for Building MODAF-Compliant Architectures...14 Figure 3-2: 7-Step Concept to Capability Process Mapping to the Concepts & Doctrine Lifecycle...16 Figure 3-3: Key Elements and Interfaces of Concepts & Doctrine COI Processes...19 Figure 3-4: Example StV-1 Capability Vision...21 Figure 3-5: Capability View...22 Figure 3-6: Example AcV-2 SoS Acquisition Programme...23 Figure 3-7: Key MODAF Relationships to Policy Development...24 Figure 3-8: OV-1a High Level Operational Concept Graphic...27 Figure 3-9: Extract from OV-1b High Level Operational Concept Description...28 Figure 3-10: OV-1c Operational Performance Attributes...28 Figure 3-11: StV-4 identifying capability dependencies...29 Figure 3-12: Key MODAF Relationships to Analytical Concepts Development...30 Figure 3-13: ISTAR StV-2 Capability Parameters and Metrics...32 Figure 3-14: OV-2 Operational Node Connectivity Description...33 Figure 3-15: OV-4 - Organisational Relationships Chart - Global C2 hierarchy...34 Figure 3-16: Key MODAF Relationships to Applied Concepts Development...35 Figure 3-17: OV-3 articulating a Warfighting Scenario...37 Figure 3-18: OV-5 articulating a Warfighting Scenario...38 Figure 3-19: OV-6a Operational Rules Model Action Assertion Derivation...39 Figure 3-20: Key MODAF Relationships to In-Service Development of Doctrine...39 MODAF-M10-013a Version 1.0 4

5 Foreword 1. An effects based approach to military operations demands that we combine military capabilities in time and space, to an ever increasing tempo, in order to achieve the desired outcome. To achieve this, we must master the complex interaction of weapons, platforms, sensors and people, in order to maximise their combined strengths and to minimise any potential weaknesses. We seek to do this through our adoption of Network Enabled Capability, integrating existing capabilities into an increasingly coherent system of systems. 2. At the same time, perpetual pressure on Defence spending means that we must seek maximum return on our investments and drive inefficiency out of our operations. 3. Our greatest enemy in this regard is complexity and we must find effective ways to overcome it. One key to achieving the simplicity we seek is to focus on the decision-making process and the information flows that must support effective decision-making and subsequent action. 4. The MOD Architectural Framework (MODAF) offers invaluable assistance in our struggle for simplicity, as it provides a common language and common formats for the capture and shared use of trusted data. It is therefore my intent that we adopt an architectural approach, grounded in MODAF, to our day-to-day business. This Deskbook explains how you can begin to use MODAF to articulate your business in a manner that will aid collective understanding, increase efficiency and enhance effectiveness; I commend it to you. MODAF-M10-013a Version 1.0 5

6 1. Introduction 1.1 Enterprise Architectures and Frameworks 5. MOD s adoption of Network Enabled Capability (NEC) 1 as its means of integrating existing capabilities into a coherent system of systems is an ambitious exercise in managing both complexity and change throughout the enterprise. Modern warfare is fast changing and the systems that technology is now making available are in themselves faster, more complex and more adaptable than ever before. The combination and orchestration of these systems in concert with operational planning introduces a level of complexity never before experienced in the Ministry of Defence. 6. To assist decision-makers, MOD has decided to adopt the MOD Architecture Framework (MODAF) as a means of abstracting essential information from the underlying complexity and presenting it in a way that maintains coherence and consistency. One of the principle objectives is to present this information in a way that is understandable to the many stakeholder communities involved in developing, delivering and sustaining capability through life. 7. MODAF is an Architectural Framework, which has been designed to meet the specific business and operational needs of the MOD. It defines a way of representing an Enterprise Architecture, which enables stakeholders to focus in on specific areas of interests in the enterprise, whilst retaining sight of the big picture. In essence it enables decision-makers to manage complexity by splitting the problem space into manageable pieces defined in the framework as Views. The views are categorised under Viewpoints by their perspective (e.g. operational, technical, etc.). Each View has a particular purpose, and usually presents: a. Broad summary information about the whole enterprise (e.g. high level operational concepts); b. Narrowly focussed information for a specialist purpose (e.g. system interface definitions); c. Or, information about how aspects of the enterprise are connected (e.g. how business processes or operational activities are supported by a system, or how programme management brings together the different aspects of network enabled capability). 8. The fundamental tenet of an Enterprise Architecture approach is that there is one source of truth. This reflects the fact that while there can only be one enterprise, there can be many valid stakeholder views providing they are based on a common data set. The diagram in Figure 1-1 attempts to illustrate this concept of a single enterprise that can be presented in different ways that has meaning for particular stakeholders or communities of interest. 1 Network Enabled Capability JSP 777 Edition 1 dated April MODAF-M10-013a Version 1.0 6

7 Operational Node - Marketing Dept. Operational Node - Sales Dept. Operational Node - Distribution Centre Operational Node - Product Design Centre Operational Node - Call Centre Operational Node - Manufacturing Plant Location - London, UK 1 Location - Cambridge, UK 4 Location - Shanghai, China Acme inc. 2 3 Location - Leeds, UK Sales & Marketing Engineering HR IS/IT 5 6 Sales Marketing R&D Design Test Location - Northampton, UK Needlines: 1 market requirements 2 sales summary information 3 target market information 4 manufacturing specifications 5 distribution orders 6 product requests Customer Services MRP etc. Sales Dept. CRM Marketing Dept. Reqs Mgmt Functional Modeller Product Design Centre Product Data Mgmt CAD Recon Report <<OperationalActivity>> Analyse Target Data <<OperationalActivityAction>> Enhance Images Order Mgmt CRM Reqs Mgmt ERP Finite Element Processe d Images Order Mgmt CRM ERP Strike Recommendati <<OperationalActivityAction>> <<OperationalActivityAction>> on Make Strike Analyse Images Decision Stock Mgmt CCMS QC Robot Planning CNC Strike Decision Distribution Centre Call Centre Manufacturing Plant Figure 1-1: Enterprise Architecture Views 9. As with any potentially large-scale endeavour such as MODAF, it is crucial to have an agreed and common language or terminology. To this end MODAF provides a Dictionary of Terms and a Glossary of Abbreviations. To understand what MODAF is (and equally important what it is not) it is particularly important for the reader to understand the following terms from the outset: a. Enterprise Architecture: The formal description of the structure and function of the components of an enterprise, their interrelationships, and the principles and guidelines governing their design and evolution over time. (Note: Components of the enterprise can be any element that goes to make up the enterprise and can include people, processes and physical structures as well as engineering and information systems). b. Enterprise: The term enterprise can be defined in one of two ways. The first is when the entity being considered is tightly bounded and directed by a single executive function. The second is when organisational boundaries are less well defined and where there may be multiple owners in terms of direction of the resources being employed. The common factor is that both entities exist to achieve specified outcomes. i. Enterprise (1) : An organisation (or cross organisational entity) supporting a defined business scope and mission that includes interdependent resources (people, organisations and technologies) that must coordinate their functions and share information in support of a common mission (or set of related missions). (US Federal CIO Council) ii. Enterprise (2) : A systematic, purposeful set of activities whose primary purpose is focussed on achieving a set of clearly defined objectives that may transcend organisational boundaries and consequently require integrated team working under the direction of a governing body of resource providers. c. Enterprise Architecture Framework: A logical structure for classifying, organising and presenting complex information relating to Enterprise Architectures in a uniform manner. MODAF-M10-013a Version 1.0 7

8 1.2 This Deskbook 10. This Deskbook is part of a suite of MOD Architectural Framework (MODAF) documentation that is being released at Version 1.0. The Deskbook is not intended to be an authoritative technical document with respect to MODAF and only provides limited information regarding the background to MODAF, the benefits that will result from its implementation and the technical detail needed to produce MODAFcompliant architectures. Should more information be required, then it is suggested that the reader consult the MODAF Overview document (MODAF-M09-002) in the first instance, and then the MODAF Technical Handbook Volume 2 (M07-022) for detailed technical information. 11. The Deskbook intends to provide pertinent MODAF-specific information and guidance to this community s specific business processes and activities, placing particular emphasis on understanding how current processes/activities relate to the future needs of the community. The insight to this was provided through communityrelated documentation and engagement with the specific community of interest through a series of workshops and participation in the document review board. 12. Naturally, as these processes and activities evolve, it may be necessary to release updated versions of this Deskbook for the benefit of the community. Should any changes, errors or omissions be noticed while reading this document then these should be brought to the attention of the MODAF Project Management team, whose contact details are published in Section 5 of this Deskbook. MODAF-M10-013a Version 1.0 8

9 2. Background 2.1 What is MODAF? 13. MODAF is a framework for conducting Enterprise Architecture and provides a means to model, understand, analyse and specify Capabilities, Systems, Systems of Systems (SoS) and Business Processes. MODAF consists of the six Viewpoints that are shown in Figure 2-1. Strategic Viewpoint Documents the strategic picture of how military capability is evolving in order to support capability management and equipment planning Operational Viewpoint Documents the operational processes, relationships and context to support operational analyses and requirements development Systems Viewpoint Documents system functionality and interconnectivity to support system analysis and through-life management Acquisition Viewpoint Documents acquisition programme dependencies, timelines and DLOD status to inform programme management Technical Viewpoint Documents policy, standards, guidance and constraints to specify and assure quality expectations All Views Provides summary information for the architecture that enables it to be indexed, searched and queried Figure 2-1: MODAF Viewpoints 14. MODAF consists of 38 Views, each of which can be used to represent a particular aspect of the enterprise. These Views are categorised into the six Viewpoints, as shown in Figure 2-1. The purpose of each of the 38 Views is different some provide high-level summary information about the enterprise (e.g. organisational structure, programme management, etc.), others describe some specific aspect (e.g. system interfaces), whilst others serve to describe the relationships between different aspects of the enterprise (e.g. process mapping). 15. Not every View is appropriate or necessary for a given architecture. It is intended that users select appropriate MODAF Views to most effectively represent their needs. This Deskbook provides advice for the specific Community of Interest (COI). 16. MODAF may be applied across a wide variety of MOD processes, including Capability Management, Acquisition, Operational Analysis, Planning and Through-life Management. Applied appropriately MODAF is an enabler to the successful delivery of Network Enabled Capability (NEC). Amongst the benefits of MODAF within the Concepts & Doctrine processes are: d. Improved articulation of concepts to identified defence capabilities e. Improved identification and management of cross-capability dependencies MODAF-M10-013a Version 1.0 9

10 f. Better support for concept generation and capability development and assessment g. Ensure better capability selection, endorsement and integration across all Defence Lines of Development 2 (DLOD). 2.2 Guide to Deskbook Purpose 17. The purpose of this document is to illustrate to the general Concepts & Doctrine community how the MODAF Views within these architectures can support the various elements of their processes and activities Approach 18. The main part of this Deskbook is the mapping of MODAF views onto the Concepts & Doctrine processes (see Section 3). For each process, the required, and useful MODAF Views are specified illustrating whether the process requires input from Products 3 conforming to a given view, or whether the process itself creates those Products. A worked example (see Section 4) provides context to the process mappings by showing how the architectural development process can be applied to a given scenario Context 19. The Concepts & Doctrine Deskbook forms part of the overall suite of MODAF 1.0 baseline documentation as shown in Figure Training, Equipment, Personnel, Infrastructure, Doctrine & Concepts, Organisation, Information and Logistics. 3 An Architectural Product is a connected and coherent set of architectural elements (e.g. processes, systems, platforms, organisations, etc.) that conforms to a view. MODAF-M10-013a Version

11 MODAF Products MODAF Executive Summary MODAF Overview MODAF Technical Handbook Concepts & Doctrine COI Deskboo MODAF COI k Deskboo COI Deskbook k Viewpoint Overview Meta Model Taxonomy MODAF Acronyms List MODAF Glossary of Terms Figure 2-2: MODAF 1.0 Baseline Products 20. The main elements of the MODAF baseline documentation are: a. Executive Summary provides a brief summary of the entire MODAF baseline b. MODAF Overview describes what MODAF is, why it should be used and details the process for developing architectures c. MODAF Technical Handbook provides details of the construction of MODAF Views and their relationship to the MODAF Meta Model (M 3 ). This is supported by: i. View Overview a short summary of each View intended for quick reference by MOD users ii. Meta Model 4 used to define the architectural objects that are permitted in MODAF Views and their relationships with each other. The M3 is derived from a conceptual model of the elements within the MOD architecture - the Enterprise Reference Model 5 (ERM). 4 MODAF Meta Model, IA/02/16-ERMcm04 Version 1.0. Please refer to the IA for more information. 5 Enterprise Reference Model, IA/02/16-ERMcm06 Model Version 2.1, 15 August 2005 and Document version 1.1, 15 August MODAF-M10-013a Version

12 iii. Taxonomy 6 provides the approved names and definitions for architectural objects to be used within the MOD s architectures d. MODAF Deskbooks describe how users within particular communities in the MOD are expected to utilise MODAF architectures to support their processes. e. MODAF Acronym List and Glossary of Terms these documents define the commonly used terminology in the MODAF Document Suite. 21. The Deskbooks are aimed at specific Communities of Interest (COIs). The boundaries between these communities are not always distinct, but it has been necessary to draw boundaries for the purposes of the Deskbooks. Each COI is defined in terms of its relationship to the main MOD processes (see Figure 2-3). Whilst these do not describe the whole of the MOD s processes as described in the Business Management System (BMS), they do cover the core processes around acquisition and military operations. 22. It should be noted that the COI names referred to in Figure 2-3 are merely convenient labels to apply to communities / groups that are engaged in similar activities, representing the primacy of each role as the CADMID/CADMIT cycle unfolds. For instance, the scope of the Acquisition COI aligns broadly with that of the DPA IPTs (i.e. largely equipment focussed from Concept stage through to delivery into service). Obviously this scope is somewhat more limited than the full Smart Acquisition definition of Acquisition which encompasses all DLODs and the entire lifecycle. However, collectively the MODAF COIs do encompass all of the DLODs and cover the entire MOD acquisition lifecycle. Concepts & Doctrine Concepts & Doctrine Future Op Needs Doctrine Capability Gaps Customer 2 Operations Customer 1 Acquisition Capability Management C A D M I D Funded C A D M I T Options Sustainment Constraints Figure 2-3: Community of Interest Deskbook Scope 23. The high level scope of these COIs is: a. Concepts and Doctrine - the development of analytical concepts (e.g. Joint High Level Operational Concept), applied concepts (e.g. Joint Fires) and In- Service doctrine (e.g. SOPs and TTPs) 6 MODAF Taxonomy Requirements, IA/02/16-ERMcm05 Version 1.0. Please refer to the IA for more information. MODAF-M10-013a Version

13 b. Customer 1 the monitoring of capability gaps against future needs, building the Equipment Programme (EP) and ownership of User Requirements Documents (URDs) for new capabilities c. Acquisition the development and fielding of new military capabilities, the primary focus is up to the acceptance into service of a fully operational capability d. Sustainment the processes to maintain military capability in line with the relevant Through Life Management Plan while recognising the in-theatre Sustainment roles of the relevant Second Customer s Pivotal Managers 7 e. Customer 2 the Core Leadership and Pivotal Management roles as defined in Smart Acquisition 8 and described further in the Joint and Single Service 2 nd Customer Handbooks Deskbook Structure 24. The remainder of the MODAF Concepts & Doctrine Deskbook comprises two key sections: a. Section 3 - MODAF s Relationship to the Concepts & Doctrine Processes and Activities this section explains the process of architecting as applied by those engaged in the Concepts & Doctrine process. Specifically, it identifies the key processes and activities during development of Policy, Analytical and Applied Concepts and Doctrine and outlines how these align with the MODAF Viewpoints. b. Section 4 - Worked Example of MODAF in Concepts & Doctrine this section is not available in this version of the Concepts and Doctrine Deskbook. Readers can access the full document (MODAF-M10-013) from the MODAF Team or IA (See Section 5). The worked example demonstrates how MODAF can be used practically within the Concepts & Doctrine community by means of a real-life architecture example. 7 Covered in the Customer 2 Deskbook as the Maintain Military Capability process 8 For further detail, see Smart Acquisition Handbook, available at 9 Customer 2 (Core Leadership) is undertaken by single-service Chiefs to provide overall strategic management of individual Services and their professional direction. Core Leadership provides advice to Customer 1 on the full range of factors contributing to military capability across the DLODs. Customer 2 (Pivotal Management) is undertaken by those who use the equipment in-service (primarily the front line and training commands) in order to provide the user perspective and manage allocated resources to achieve the required output. MODAF-M10-013a Version

14 3. MODAF Relationship to Concepts & Doctrine Processes and Activities 3.1 Architecture Development Process 25. The Deskbooks provide guidance about the appropriate MODAF views that can be used to support the COI s processes. It is also worthwhile considering the process of developing the architecture itself. The following sections outline a generic approach based on architectural best practice. The approach can be used (with some tailoring where necessary) by any COI wishing to develop an architecture Six-Stage Architecture Development Process 26. The stage-by-stage approach to developing a MODAF-compliant architecture is shown in Figure 3-1. The initial stages establish purpose and scope for the architecture and define the data needed to populate the architecture. Then there is the key stage of developing the architecture itself, and the use of the architecture to conduct analysis and document the results of that analysis. A more detailed description of the six-stage architecture development process is provided in the MOD Architectural Framework Overview (MODAF-M09-002, Version 1.0), which should be consulted by all MODAF users before embarking on their first architecture development. Prerequisites 1. Establish Intended Use 2. Define Architecture Scope 3. Develop Data Requirements 4. Capture Architecture 5. Conduct Analyses 6. Document Results MODAF Governance MODAF Users User training -MODAF principles Workshop - Determine Architecture Usage Inform Central Reg. Workshop - Bound Architecture Scope Query of Avail. Data Sources Workshop - Establish Data Needs Provide Extant Arch. Data Tool-sp ecific Training Publish Baseline to MODAR Analysis Review Publish Final Arch. to MODA R Finalised Arch. Re view Workshop - Determine Use Cases Plan of Time & Resources Data Gatheri ng Plan Baseline Arch. Re vie w Initial Analysis Architectural Use Doc. Architectural Scope Doc. To ol Selection Baseline Architecture Final Analysis Finalised Architecture MODAF Resources MODAF Baseline MODAF Tiger Teams MODAF Tiger Teams MODAF Tiger Teams MODAF Tiger Teams MODAF Tiger Teams MODAF Tiger Teams MODAF Training Material MODAF Help Desk MODAF Help Desk Hybrid View Development MODAF Help Desk Certified Tool List MODAF Help Desk MODAF Taxonomy MODAF Help Desk MODAF Help Desk To ol A dvi ce ERM / M3 Figure 3-1: General Process for Building MODAF-Compliant Architectures MODAF-M10-013a Version

15 27. In addition to showing the steps that a MODAF user should follow, Figure 3-1 also highlights the MODAF resources that are available to help them and the key interactions that are required with the MODAF governance processes. 28. One of the crucial MODAF governance mechanisms is the MOD Architectural Repository (MODAR) that is run by the Integration Authority (IA). This can be used to run queries and extract existing architectural data such as information on the systems that a new capability has to interface with. It is also important that all new architectures are lodged with MODAR to inform others and allow the re-use of new architectural data. Furthermore, for the Acquisition community the IA provides additional integration services that assist in modelling end-to-end performance and interoperability assurance. 29. Another important resource will be the list of certified tools. The MODAF tool certification scheme is still being developed at the time of this MODAF baseline issue, definitive guidance as to tool availability and fit with different COIs is not currently available. Therefore, interim guidance exists on the availability of MODAF convergent tools In order to facilitate the searching and query of architectures it is essential that the All Views (AV-1 with meta-data regarding the architecture and AV-2 with the architecture s object dictionary) are completed thoroughly for all architectures before they are published. Further information on the All Views can be found in the MODAF Viewpoint Overview (MODAF-M07-016, Version 1.0). It is worth noting that most architecting tools provide functionality to automatically generate the object dictionary from the description fields as the taxonomy is defined Architectural Data Sources 31. Over time, as increasing numbers of projects develop their MODAF architectures, a cohesive library of architectural elements will emerge, and any MODAF user would expect to commence analysis or planning by re-using relevant elements from the library. These may include MODAF architectures supporting the capability definition (Strategic Products), URD and CONEMP (Operational Products), interfacing systems (System Products), applicable standards (Technical Products) and programmatic information (Acquisition Products). For early adopters of MODAF, it is likely that some or all of these will be missing when architectural activities are started and the user will have to either backfill the key elements themselves, validating them with the stakeholders who should have provided them, or request that they be produced. 32. Architectures should be living representations of the enterprise and must be kept up to date. It is important to apply the six-stage architectural process for each new piece of work as the required outcomes, assumptions, scope, data sources etc may have changed in the meantime. 33. Any team conducting architectural activities within the MOD should contact the IA as custodians of the MODAR in order to establish what architectural data may exist or to understand who else may be developing related information all of which will minimise nugatory work. See Section 5 for contact details. 10 Interim NEC, CBM and BMS MODAF Modelling Policy, DEC (CCII) File ses , 1/3/05. MODAF-M10-013a Version

16 3.1.3 Application to Concepts & Doctrine Process 34. The relationships between policy, concepts and doctrine, force development, science and technology and the DLOD are key to successfully developing future capability. MODAF architectures will play several important roles in this process by: a. Developing a clearer understanding of future concepts and contextual information from which systematic analysis and experimentation will transform these ideas into coherent and credible guidance to capability developers or an accepted future tactic or practice. b. Providing a mechanism to document the process being provided by all organisations involved in concepts and doctrine development so that a complementary approach is achieved. 35. The intent is that the architecture development approach should be applied by all Concepts & Doctrine development staff in support of their business processes. In this version of the Deskbook, the MODAF architecture process has been mapped to 4 key areas for Concepts & Doctrine development: Policy, Analytical Concepts, Applied Concepts and In-Service Development of Doctrine. 36. These in turn are related to the Defence Management Board (DMB) endorsed 7- Step Concept to Capability Process 11 to illustrate the progress of Concepts & Doctrine development through the CADMID / CADMIT lifecycle 12 to deliver the required new or enhanced military capability (Figure 3-2). Concepts & Doctrine Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Policy Analytical Concepts Applied Concepts In Service Development of Doctrine Figure 3-2: 7-Step Concept to Capability Process Mapping to the Concepts & Doctrine Lifecycle 37. The application of specific MODAF Views to the different Concepts & Doctrine activities is described in more detail later in this section. 11 The 7-Step Process was developed as part of Medium Term Workstrand 1a (MTWS 1a) in order to better define the process of developing capability from conceptual work. 12 Further information on the CADMID / CADMIT lifecycle can be found on the Acquisition Management System (AMS) MODAF-M10-013a Version

17 3.1.4 Overview of MODAF View use 38. MODAF Views provide support to MOD business processes in four key ways: in support of analysis; to articulate issues or requirements; to specify or design a capability, or to validate or assure a capability. Particular attention needs to be paid to analysis support, which is generally a reference to some form of Operational Analysis (OA). 39. OA is initiated by any MOD community that has a requirement to answer questions about current, or proposed, military capability, operational processes, organisations, systems etc. As such, MODAF Views used for the analysis may be different, depending on the purpose of that analysis. Specific instances of OA applicable to the normal COI processes have been included within this Deskbook in the relevant sections. OA undertaken on subjects not covered within this Deskbook should follow the 6-stage architecture process described in Section This can be used to determine the relevance and scope of architectural support for specific OA; smaller pieces of analysis work are anticipated to continue using any relevant tools (for example, spreadsheets may be the most appropriate tool for financial analysis) where the analysis piece is not large enough to warrant use of a MODAF architecture. 40. In addition to the way MODAF Views support business processes, they are applicable at a variety of different levels - from being the core basis for a business activity, to providing some supplementary guidance to that activity. AcV-2 for example, as the SoS Acquisition Programme View, is designed to support the acquisition and fielding processes to achieve integrated military capabilities. However, it could also inform the Concepts & Doctrine community of the current and proposed status of projects/programmes during the development of concepts. MODAF Views may also provide a means of communication between different stakeholders in a process. 41. Two levels of use have been defined for MODAF Views identified in this Deskbook, reflecting the level of support provided by a View to a particular activity: a. Essential Views that are essential for use during a particular Concepts & Doctrine activity b. Highly Desirable Views that are recommended to inform a particular activity, given that they contain a significant amount of data of value to that activity in the majority of scenarios or circumstances. 42. The Essential Views are the starting point for any new MODAF user. Highly Desirable Views are more appropriate to users who have more experience of MODAF and are looking for further ways of using architectural information to inform an activity. An example of the classification of MODAF Views is at Appendix 1, illustrating the mapping of essential and highly desirable Views. 43. Any other MODAF View may be used in addition to the Essential and Highly Desirable Views at any stage if it helps in the execution of the analysis / task. If a non-modaf View is used, the user must justify use of a non-standard View and be aware that such Views may not be shared. MODAF-M10-013a Version

18 3.1.5 Ensuring Views are MODAF compliant 44. In order to maximise the ability to exploit architectures produced in MODAF format it is important that they fully comply with the MODAF standards, which includes not only the use of MODAF views but also the MODAF Meta-Model and Taxonomy. The use of MODAF-certified tools by architecture development teams will ensure that most of these requirements are satisfied and hence provide assurance of interoperability between tools and with the MODAR repository. 45. It is possible for users to create Views that look similar to those specified in MODAF, but which do not conform to the full standard. In such cases it is likely that the resulting architecture will not be capable of full information exchange between tools / with the MODAR repository and therefore might not be accessible to others running architectural queries. The resulting architecture would become, to a greater or lesser degree, isolated from the main MODAR body of architectural knowledge. 46. However, there may be good reasons for wishing to modify MODAF views such as adding further overlays to enhance understanding. Where this is the case, the user wishing to develop modified Views should first contact the MODAF team and/or IA (see Section 5 for points of contact) for advice on how to implement the required enhancements in a manner that maximises tool interoperability and hence the future exploitation of the resulting architecture. 3.2 Concepts & Doctrine Processes 47. The Concepts & Doctrine community will be generating and using MODAF architectures during concepts-to-capability development and for articulating how best to use these capabilities within the Services. 48. This Deskbook describes the architectural processes based on MODAF as they relate to the Concepts & Doctrine community by reference to the Concepts & Doctrine process model shown in Figure 3-3. This diagram also shows the key interfaces with the other communities considered within the MODAF Deskbooks. MODAF-M10-013a Version

19 Policy Concepts & Doctrine Analytical Concepts Applied Concepts In Service Development of Doctrine HLOC CONOP, CONEMP, CONUSE Feedback, AARs, LFE Doctrine, SOPs, TTPs Operations Customer 1 Customer 2 Capability Management C A D M I D C A D M I T Sustain Acquisition Figure 3-3: Key Elements and Interfaces of Concepts & Doctrine COI Processes 49. The Concepts & Doctrine COI processes interface with all of the other COIs, some of the key inputs and outputs being: a. Capability Management provides Customer 1 with changes to conceptual thinking and collaborates with them to determine feasibility and resourcing of applied concepts. Key outputs to Customer 1 will be the Draft and endorsed Concept of Operations. b. Acquisition provides the Acquisition processes with applied concepts that document the operational context and usage of the new capability. c. Customer 2 provides key elements in the concepts and doctrine development, both as core leaders and pivotal managers. Core Leaders provide the Joint and Single Service focus for Joint and Environmental high level concepts and doctrine delivery, and during the delivery stages of the capability will also develop operational and tactical doctrine to support the Pivotal Manager. d. Sustainment supporting documentation in terms of the Concept of Operations (CONOPS), Concept of Employment (CONEMP) and Concept of Use (CONUSE) of capabilities and equipment will be provided to the Sustainment COI. In addition when mid-life equipment upgrades are proposed, the acquisition lifecycle will be reiterated and updated CONUSE developed. 50. The role of MODAF architectures in supporting the Concepts & Doctrine COI processes and its key interfaces with the other COIs is described in the sections that follow, structured according to the main sub-processes shown in Figure A one-page diagram of how the MODAF Views map to the Concepts & Doctrine processes is at Appendix 1. Each of the following sections refers to appropriate segments of that process to maintain clarity. MODAF-M10-013a Version

20 3.3 Policy 52. This section provides detail of the Policy forming stage of the Concepts & Doctrine development. The key activities at this stage that may be supported by use of MODAF Views are: a. Capability Identification b. Future Capability Reconciliation 53. Fighting Power defines an Armed Forces ability to fight and achieve success on operations. It is made up of an essential mix of three inter-related components: conceptual, moral and physical 13. The conceptual component develops the framework of thinking within which the means to fight (the physical component) are combined with the motivation and leadership of people (moral component), and applied on operations and training. However, the military is but one instrument of national power 14 and exists only to serve the interests of the people. These interests are expressed in terms of national policy Defence policy reflects the prevailing and emerging strategic environment and while enduring and fluid, it provides the framework for the setting of subordinate policy within the MOD and will be subject to continuous review as circumstances changes. Policy must state what is to be done and as importantly, what is not to be done. This is described by the Defence Policy Goals within Defence Strategic Guidance and is the basis for future Concepts & Doctrine development work. The focus of policy should generally be beyond the 15-year point or more, but for political reasons the focus may be much nearer (less than 10 years). It is also likely that feedback from the analytical concepts development activities may influence Policy more than the 7-Step process acknowledges Capability Identification 55. This stage is Step 1 of the 7-Step process, and is initiated in order to give substance to Defence Policy. This is considered integral to the Directorate Policy Planning s (D Pol Planning) primary outputs, and may be in the form of Defence Implications of Strategic Trends (DIST), Defence Planning Assumptions (DPA) and Defence White Papers. The Joint Doctrine and Concepts Centre (JDCC) will support this process through provision of Strategic Trends Futures analysis, for which D Pol Planning is a customer. 56. MODAF can support this process by providing StV-1 (Capability Vision) Views representing the current Joint High Level Operational Concept (HLOC) and Joint Vision as contextual inputs. Capabilities described in these Views may cover a number of epochs, which may be further detailed in corresponding StV-3 (Capability Phasing) Views supplied by the Customer 1 community. However, at this stage of conceptual development, it is likely that this level of detail may not be sufficiently mature to capture within an StV British Defence Doctrine (BDD) 2 nd Edition Chapter Other instruments of power are diplomatic and economic. 15 BDD describes policy as the nations response to the prevailing strategic environment, reflecting the Government s judgement on what is necessary and possible in the pursuit of the national interest. MODAF-M10-013a Version

21 57. StV-1 Capability Vision: The high-level concepts are presented as an StV-1. This outlines the future capability requirements as a textual description. Figure 3-4 is an example of an StV-1. This will normally be provided to the Customer 1 Community as an input from the Doctrine and Concepts Community (i.e. JDCC and Environmental Staffs), although at this stage of concept development its use will be primarily to capture the current concepts vision based on previous policy direction. UNCLASSIFIED THE UK JOINT HIGH LEVEL OPERATIONAL CONCEPT CAPPING PAPER 101. Fighting power comprises conceptual, moral and physical components. The conceptual component of joint fighting power was articulated in UK Joint Vision, where the importance of the enduring nature of the Principles of War was endorsed. The Vision provided broad guidance for future capabilities in the form of a joint High Level Operational Concept (HLOC), an effects based framework for operations and a description of capability as seven discrete but closely interlocking components. However, UK Joint Vision did not develop the conceptual components in detail. Using the Defence Capability Framework, this Analytical Concept describes the components of capability in sufficient detail to inform Joint Operational Concept Committee stakeholders, particularly the single Services, who are developing their own high level operational concepts in parallel. The three components of capability, Command, Inform and Operate, form the capability backbone of the HLOC around which considerations for the remaining four components Prepare, Project, Protect and Sustain have been woven to form the complete concept. The concept addresses the 2020 timeframe, assessed as the best compromise between the need to break free from the dominance of current systems4 without venturing into the purely speculative. It has also been harmonised with US joint concepts, noting the clear guidance from COS that we must be able to operate with but not necessarily as our close allies. OPERATE CORE CONCEPT An agile task-oriented joint force with freedom of action to synchronise effects throughout the Battlespace and with maximum potential to exploit fleeting opportunities. Figure 3-4: Example StV-1 Capability Vision 58. StV-3 Capability Phasing: This View may be created by the Customer 1 community as an input to the Capability Audit process, which considers capability planning, programmatic data and previous updates to concepts, doctrine and strategic guidance. This View provides the current capability delivery schedule and will support the identification of capability shortfalls and surpluses by epoch. Figure 3-5 below shows a modified View from DEC CCII collated prior to a Capability Audit. It only utilises a sub-set of the potential data elements available to an StV-3 and does not identify the systems that provide for a particular capability function (See the MODAF Volume 2 Handbook for more details regarding use and data elements authorised for use in this View). Instead, it shows a representative level of available capability in a particular epoch using a measure of capability, and a Red, Amber, Green colour scheme. It should not be used as the basis for developing StV-3 Views as it is not fully MODAF compliant, but serves as a close approximation. MODAF-M10-013a Version

22 Figure 3-5: Capability View Future Capability Reconciliation 59. Future Capability Reconciliation is Step 2 of the 7-Step process, and seeks to reconcile the identified Defence capabilities against current, developing and future threats, policy and wider planning assumptions to generate a prioritised View of required capabilities. This is encapsulated in the Future Capability Development Paper (FCD). 60. The FCD is the focus of this Step and should provide the path for concepts development as well as informing the generation of a Capability Experimentation Strategy to enable greater coherence within the UK s experimentation, analysis and research efforts. This work will, in the future, be led by the JDCC and endorsed by the Joint Doctrine and Concepts Board (JDCB). 61. Part of the FCD should consider capability gap analysis. The use of the MODAF AcV-2 SoS Acquisition Programme View as part of this analysis process will assist in the identification of the main dependencies and timescales, providing information on how the DLODs are expected to develop and mature within the duration of the proposed concept to capability delivery cycle. 62. AcV-2 SoS Acquisition Programme: Acquisition Viewpoint AcV-2 is collated by the Customer 1 community, with updates from Integrated Project Teams (IPTs), to support decision making during the Capability Audit and Equipment Planning activities. These Views illustrate when acquisition programmes are expected to deliver scheduled capability, illustrating programme dependencies and status across all DLOD at each stage boundary (see Figure 3-6). Consequently, they are also useful in identifying when capability gaps will emerge. MODAF-M10-013a Version

23 AcV-2 EXAMPLE VIEW MG 01/10/04 IOC 01/04/05 FOC 01/08/05 System A IG 01/05/04 MG 01/11/04 IOC 01/06/04 System B IG 01/06/04 MG 01/01/05 IOC 01/10/06 System C MG 01/10/04 IOC 01/05/05 FOC 01/01/06 System D DISPOSAL 01/05/05 OUT OF SERVICE 01/01/05 System E Key to View Trai ni ng Personnel Equipment Logistics LoD 'Segment' No outstanding issues Manageable issues Project Phase Pre-IG IG to MG Information Infrastructure Do ctrine / Organisation Co ncepts Critical issues Not Known MG to IOC IOC to FOC In Service Not Required Disposal Figure 3-6: Example AcV-2 SoS Acquisition Programme 63. While no MODAF outputs are expected at this stage, the outputs of the Policy stage should be clear guidance and direction from the JDCB on conceptual development and associated links to Science and Technology (S&T) resources, which will feed into the Defence Science & Technology Board. 64. Figure 3-7 shows the key architectural inputs for the Policy stage, StV-1 Capability Vision and AcV-2 SoS Acquisition Programme, with respect to the overall process. MODAF-M10-013a Version

24 System A System B System C System D System E Personnel Information Training Equipment Doctrine/ Concepts MG 01/10/ Logistics Organisation Infrastructure IOC 01/04/05 IG 01/05/04 MG 01/11/04 IOC 01/06/04 IG 01/06/04 MG 01/01/05 MG 01/10/04 LoD 'Segment' No outstanding issues Manageable issues Critical issues IOC 01/05/05 FOC 01/08/05 IOC 01/10/06 Project Phase Pre-IG IG to MG MG to IOC IOC to FOC In Service Disposal FOC 01/01/06 DISPOSAL 01/05/05 OUT OF SERVICE 01/01/ Policy Concepts & Doctrine Analytical Concepts Applied Concepts In Service Development of Doctrine FCD JHLOC JHLOC AcV-2 AcV-2 EXAMPLE VIEW StV-1 Key to View Capability Management Figure 3-7: Key MODAF Relationships to Policy Development 3.4 Analytical Concepts 65. JWP defines a concept as a notion or statement of an idea, expressing how something might be done or accomplished in the future. In Defence, concepts exist at different levels; for example the JHLOC describes the ways in which the Services will operate in the future in broad and abstract terms, while a detailed Concepts on Employment (CONEMP) will inform an ongoing equipment acquisition process. 66. A concept must have certain attributes to be useful, and MODAF readily enables the development of these attributes. It must have suitable provenance, which demonstrates coherence with other conceptual work and provides authority for subsequent implementation. Conceptual work is not conducted in a vacuum; policy, science and technology, other conceptual activity, academic work, doctrine, lessons and resource constraints all inform the development process. The timescale for implementation is important and concepts must have a clear purpose and associated target audience. Post Policy and Planning Steering Group (PPSG) endorsement, the concept must be able to influence policy, procedure and/or capability. In sum, the attributes of an effective concept are 16 : 16 Chapter 3 AD Draft JDCC Concept Handbook dated July MODAF-M10-013a Version

25 a. Provenance. The concept is generated in response to a change in policy, strategic context (including threats), or technological opportunities, and is coherent with other concepts. The concept should have wide support, produced by rigorous debate on its effect across all of the DLODs. The quality of a concept, its potential positive impact upon capability and how well that is articulated will provide a high degree of provenance in its own right. Detailed analysis and experimentation should lead to its endorsement as a driver for change. b. Authority. Once endorsed the concept provides a focus for force and capability development and guides and informs subordinate concepts be they analytical or applied. In a few cases, a particular concept might provoke changes in the higher levels of the hierarchy, which should be regarded as a flexible framework rather than a rigid structure stifling innovative thinking. The overall concept process is, therefore, strongly iterative and developmental and MODAF Views used in conceptual development will similarly be subject to constant review and increasing resolution as development work is carried out. c. Timescale. Although not always the case, higher-level concepts are normally set in the long term and have broad windows of applicability; for example, Joint Vision currently addresses 2015 and beyond. Such concepts tend to be of an enduring nature. Subordinate concepts are more often set in the medium to near term and must have more tightly defined requirements, e.g. a specified inservice date for equipment. d. Realism. The concept should deliver an improvement upon what the MOD can do today, not just a new way of doing things. Affordability and technology should not necessarily constrain emerging analytical conceptual thinking, although concepts must be cast within the bounds of the possible in order to achieve the wide support that provenance and authority demand. Early consideration of those DLODs considered critical for a particular concept will assist defining the boundaries of realism and should help determine the major implications of a new concept. Experience shows that early consideration of the Personnel DLOD is invariably necessary but concepts developers should consider all DLODs at an early stage and determine which might be critical on a case-by-case basis. Analysis and experimentation will help build confidence that concepts are achievable and affordable. 67. MODAF architecture Viewpoints will support the establishing and articulation of much of the conceptual development work. The MODAF Strategic Views used or developed during conceptual development will confirm the provenance, authority and timescale of a concept while the use of Operational, Acquisition and Technical Views will determine the realism and ultimately enable endorsement of a new concept. 68. This section describes the use of MODAF at the Analytical Concepts stage of Concept & Doctrine development. The key activities at this stage that may be helped by the use of MODAF are: a. Concept Generation b. Capability Development and Assessment MODAF-M10-013a Version

26 3.5 Concept Generation 69. Analytical concepts are generated in response to either changes in policy, the future security environment or focussed on emerging technology. They seek to present a solution to a perceived future problem or capability gap and break it down into its constituent parts for further analysis and examination. The focus of an analytical concept is generally beyond the 15-year point and they are generated by Concepts staff based at the JDCC. 70. Concept Generation is Step 3 of the 7-Step process and concerns the generation of analytical concepts, describing the approaches to which required future capabilities could be met or how future problems could be solved. The output will be Joint and environmental concepts that have been agreed by the Joint Operational Concepts Committee (JOCC), and where appropriate single-service committees, as being sufficiently mature for subsequent refinement and evaluation. These outputs will be captured as a series of MODAF StV-1 Capability Vision Views (Figure 3-4), which will be used to inform the Applied Concepts community and form the basis of the development of the Capability Requirements Document (CRD) by the Customer 1 community (See the MODAF Customer 1 Deskbook MODAF M10-001, Version 1.0 for details of MODAF use for CRD). The JDCC will lead the concept generation stage ensuring the active involvement of DLOD staffs and Customer 2 Core Leadership StV-1 Capability Vision: At this stage the StV-1 Capability Vision will define the strategic context for the proposed group of capabilities, and will usually be a highlevel textual description using terminology easily understood by non-technical readers. It may make extensive use of military terminology and acronyms. There is no prescribed specification for an StV-1 although it should contain a description of the high-level concept, augmented by descriptions of the high-level operational goals and strategy in military capability terms. It is not intended to be prescriptive in terms of system or user requirements, but should set the scope for the architecture in terms of future or current capability vision. It is essential that the StV-1 s associated with new conceptual work are captured at this stage Capability Development and Assessment 72. Capability Development and Assessment is Step 4 of the 7-Step Process, which seeks to develop the initial analytical thought conducted in concept generation, through focused experimentation, research and operational analysis, to ensure the realism and affordability of concepts in context with Defence Planning. Qualitative, quantitative and programme analysis will be conducted to inform the completion of a risk register across all DLOD. This process will convert initial conceptual thinking into draft CONOPS that are mature enough for submission to the PPSG. The process will be controlled by the JOCC and utilise established Customer 1 and DFD operational analysis and D CBM/J6 Joint experimentation procedures. Generated in conjunction with Customer 2 Core Leadership and DLOD staff, these draft CONOPS should contain the context within which a particular concept and capability package fits, the cross-capability linkages and a completed risk register. The initial population of specific MODAF Views is recommended at this stage to confirm the initial scope of the draft CONOPS. The concept development will have been captured in an StV-1 17 To translate the equipment capability provided by Customer 1 into an operational Military Capability through the Capability Integration process; to manage the availability of the in-service equipment; to provide the relevant advice and expertise; and to support Customer 1 s remit to deliver the required equipment capability and to be the user. MODAF-M10-013a Version

27 Capability Vision View, while the collaborative development of draft CONOPS should be captured as follows: a. Essential - High Level Operational Concept Graphics OV-1a, OV-1b and OV-1c will articulate the initial work on the draft CONOPS b. Highly Desirable - An StV-4 Capability Clusters View can capture the crosscapability dependencies 73. Operational Viewpoints are particularly useful in the initial engagement with the other COIs in identifying the operational context and use cases for the draft CONOPS. Customer 1 should also be engaged during the initial work on these Views during the Concept Stage. 74. Depending on the nature of the concept being developed, several Operational Viewpoint suites may be initiated at this stage. This is to reflect sub-concepts that may require articulation as draft CONOPS before being moved to the Applied Concepts community for further development. 75. OV-1a High Level Operational Concept Graphic: This Essential View (Figure 3-8) provides a high level graphical summary of the operational concept: framing what happens, who does what, in what order and for what goal; as well as highlighting interactions to the environment and other external systems. Figure 3-8: OV-1a High Level Operational Concept Graphic MODAF-M10-013a Version

28 76. OV-1b Operational Concept Description: The high level context to the OV-1a will be provided by the OV-1b Operational Concept Description View. This Essential View must always accompany an OV-1a and the content must be textual. Any changes made, as the draft CONOPS are matured for endorsement by the PPSG, must be cascaded through all associated architectural Views. The extract from the OV-1b View below (Figure 3-9) articulates the high-level system context to support the OV-1a at Figure In the warfighting scenario, ISTAR information is provided by the SPECS 2 system, the KESTREL UAV system and by the NEMESIS system. SPECS 2 is an Operational level asset, and communicates via a data link to a common base station. KESTREL is a tactical UAV system that can transmit real-time video footage directly to the Fighting Patrols, and via relay to the common base station. NEMESIS is a strategic asset that has considerable on-board processing capability, enabling the data to be exploited during flight. The resultant information can be communicated either directly to a receiver based on board a Naval vessel of directly to the common base station. Figure 3-9: Extract from OV-1b High Level Operational Concept Description 77. OV-1c Operational Performance Attributes: The OV-1c Operational Performance Attributes View (Figure 3-10) is unlikely to be fully populated at this stage of the concept development process, but a high level abstraction of the concept performance attributes could be captured at this stage for further development in the cycle and is highly desirable. Attribute Measure As-Is Value Period of Period of Time 1 Time 2 Target Availability Number of hours planned downtime 30 hrs/year 20 hrs/year 10 hrs/year 5 hrs/year Maintainability Support personnel required to sustain the system Reliability Number of hours unplanned downtime 10 hrs/year 5 hrs/year 3 hrs/year 1 hr/year Figure 3-10: OV-1c Operational Performance Attributes 78. StV-4 Capability Clusters: The purpose of the MODAF StV-4 Capability Clusters View is to describe the relationships between capability elements as well as provide logical capability groupings. It is intended to analyse dependencies between capability elements and so, at this stage, can be partially developed to generate the MODAF-M10-013a Version

29 high level cross-capability dependencies to provide context to the draft CONOPS. Therefore it is not an essential View, but rather a highly desirable View that is dependent on information about current or future capabilities. 79. This should be conducted in collaboration with the appropriate DECs, as the DECs may ultimately create this architecture View as part of the information gathering for their Capability Audit and Operational Analysis activities. At this stage the information will be an abstraction of the detail normally expected in the StV-4, but it will enable the cross-capability interaction to be identified at an early stage of the conceptual development if available. 80. Figure 3-11 provides an example of an ISTAR related StV-4. It highlights (red ellipses and arrows) that a reduced capability in Operational Information Acquisition might impact on the current capability in Effects, namely targeting and engagement planning, and also on information fusion. It similarly highlights that a reduced capability in Tactical Information Acquisition might impact on the engagement capability itself. Analysis Quality Assurance Targeting Battle Damage Assessment Information Management Effects Fusion Dissemination Plan Engagement Conduct Engagement Strategic Operational Information Acquisition Tactical Figure 3-11: StV-4 identifying capability dependencies 81. Figure 3-12 shows the key architectural outputs for the Analytical Concepts stage, StV-1 Capability Vision, and how these fit within the overall process. MODAF-M10-013a Version

30 Analysis Fusion Quality Assurance Dissemination Strategic Tactical Targeting Plan Engagement Operational Battle Damage Assessment Conduct Engagement Policy Concepts & Doctrine Analytical Concepts Applied Concepts In Service Development of Doctrine HLOC StV-1 UNCLASSIFIED THE JOINT HIGH LEVEL OPERATIONAL CONCEPT CAPPING PAPER 8. The likelihood of increased involvement in low to medium intensity scenarios when the use of conventional reconnaissance forces is not possible, highlights the requirement to enhance our ability to acquire Beyond Line of Sight ISTAR information, without the need to deploy significant levels of Ground Forces. 11. Data fusion is a key enabler to the effective use of information. Collection, fusion and dissemination of data must be carried out in as near to real-time as possible in order to maximise the value of the information gained, and to minimise inaccuracy. StV-4 Draft CONOP, Draft OV-1a, 1b & 1c Information Management Effects Capability Management Information Acquisition Figure 3-12: Key MODAF Relationships to Analytical Concepts Development 82. In summary, the Concepts & Doctrine COI will already start engaging with the other COIs during the Analytical Concept stage of the process to initiate the development of supporting MODAF Views. The level of detail captured will be representative of the architecture and capability maturity at this stage, however the information within the Views will provide an unambiguous perspective of the intent of the concept as it passes into the applied concept development stage. 3.6 Applied Concepts 83. This section describes the use of MODAF for the Applied Concepts stage of Concept & Doctrine development. The key activities at this stage that may be helped by use of MODAF are: a. Capability Selection and Endorsement b. CADMID Validation and Oversight c. LOD Oversight 84. Applied Concepts are those that are put to practical use by capability developers. Their focus is the 5-15 year timeframe and they fall into three broad categories 18 : a. Concept of Operation (CONOPS). CONOPS describe how a range of (future and where necessary extant) capabilities is to be used in a future operational context to solve a particular problem or capability gap. CONOPS are refined and validated by concept development work and, at the time of their 18 Draft JDCC Concept Handbook - Chapter 3. MODAF-M10-013a Version

31 endorsement by PPSG, will have demonstrated sufficient maturity to stand as guidance to the Defence Planning and EC communities. JDCC Joint and environmental staff are responsible for the generation of the majority of CONOPS. b. Concept of Employment (CONEMP). A CONEMP is the Applied Concept of employment for a specific capability within a range of operations or scenarios; its focus is Epochs 1-3 and it will be produced by Joint and Single-Service Customer 2. c. Concept of Use (CONUSE). A CONUSE describes the way in which specific equipment is to be used in a range of operations or scenarios Capability Selection and Endorsement. 85. This is the 5 th Step in the 7-Step process, taking the draft CONOPS for selection and endorsement by the PPSG on the basis of operational effectiveness, affordability, delivery and time. The endorsed CONOPS output from this step is a genuinely Applied Concept that will stand as guidance to programmers and capability development staffs by assessing Defence Programming implications, and will feed directly into the conceptual phase of the CADMID/CADMIT cycle. However PPSG endorsement at this stage does not imply a commitment of EP or STP resources (which are subject to separate planning processes). One concept could potentially contain multiple capabilities and projects, and particular projects could derive provenance from a number of concepts. This complexity will be reflected in the associated CONEMP and CONUSE that are developed subsequently for the Assessment and Development phases of CADMID/CADMIT. 86. During this activity, MODAF Views will be passed between Concept development staff and the appropriate DECs in Customer 1, adding greater levels of detail to the initial draft CONOPS until it is sufficiently mature for presentation to the PPSG. At this stage, the original StV-1 generated in the Analytical Concepts stage may have been broken down by the Concepts development community into a series of new StV-1s, representing sub-concepts articulated in the parent strategic View. Consequently, a number of CONOPS may require development to reflect additional sub-concepts, and new information should be fed back to the concept originators to enable coherent revision of the initial conceptual work. The involvement of the Customer 2 Core Leaders will be essential in the further development of the endorsed CONOPS, and they will retain oversight as the CONEMP development takes place. They will be assisted in this process by the Front Line Commands, who will provide advice pertaining to training and basing issues. 87. During this stage, the Customer 1 community will be deconstructing the StV-1 Capability Vision into an StV-2 Capability Taxonomy (Figure 3-13), for the process of identifying current and future capability requirements by epoch. The decomposition will add clarity and the necessary level of granularity to qualify the concept. Subsequent analysis and experimentation of the operational scenario or vignette by the Customer 1 community will add detail to the draft Operational Viewpoint suite. This is essential for the progressive development of the capability concept into information for subsequent use by the Acquisition Community and will result in a URD. Details of the URD process are covered in the MODAF Customer 1 Deskbook (MODAF-M07-021, Version 1.0). MODAF-M10-013a Version

32 Information Acquisition Information Management Effects 1. Strategic Range: 120km km Duration: 24hrs 1. Analysis 1. Targeting Accuracy: 10m 2. Operational Range: 20km - 120km Duration: 20hrs 2. Fusion 2. Plan Engagement 3. Tactical Range: 0km - 20km Duration: 16hrs 3. Quality Assurance 3. Conduct Engagement 4. Dissemination 4. Battle Damage Assessment Figure 3-13: ISTAR StV-2 Capability Parameters and Metrics 88. Collaboration between the two communities at this stage will be enabled through the exchange of MODAF Views with the implementation of MODAR under the IA. Revisions to the original data captured in the draft OV-1a, OV-1b and OV-1c Views will be further enhanced by the addition of two new Essential Operational Views the OV-2 Operational Node Connectivity Description and the OV-4 Organisational Relationships Chart. These additional Views will make up the complement of the CONOPS Operational Viewpoint suite that will be further developed in subsequent stages to produce the associated CONEMP and CONUSE. 89. OV-2 Operational Node Connectivity Description: The OV-2 View defines the connectivity between operational nodes through the use of two separate Views that specify the required set of operational nodes, connectivity and need line information flows for the scenario or vignette. The OV-2 Operational Node Connectivity Description (Figure 3-14) provides a graphical depiction of the operational nodes (or organisations) depicting needlines between those nodes that have a requirement to exchange information. This View ensures that all parties are aware of the operational communications and interdependencies that will underpin the success of the solution. Sufficient technical information may not be available to support the development this View and is more likely to be developed further into the Assessment phase of the CADMID/CADMIT cycle. MODAF-M10-013a Version

33 Figure 3-14: OV-2 Operational Node Connectivity Description 90. OV-4 Organisational Relationships Chart: The nodes identified in the OV- 2a will be further clarified in the OV-4 Organisational Relationships Chart (Figure 3-15), which is used to illustrate the command structure and relationships between the human roles, organisations and organisation types that are key players for a concept. The make up of these nodes can substantially alter the capability performance and specification depending on the roles of the formation elements employing the capability. 91. The relationships can include supervisory reporting, command and control relationships and command-subordinate relationships, as well as coordination relationships between equal organisations or individuals. MODAF-M10-013a Version

34 PJHQ JTFHQ JTFHQ - TCE JFACHQ JFLCHQ JFAC HQ (ISTAR Cell) JFAC HQ (Current Ops Cell) JFLCHQ (G2 / G3 Ops) 16 AAB (G3 Ops) Figure 3-15: OV-4 - Organisational Relationships Chart - Global C2 hierarchy CADMID Validation and Oversight / LOD Oversight. 92. These are the 6 th and 7 th steps in the Concept to Capability process and ensure that, during the delivery phase, capability development remains coherent with the extant concepts, as well as being delivered across all DLOD. The oversight and subsequent development of capabilities must be maintained through to acceptance into Service and throughout their in-service life. 93. Such oversight will be maintained by Customer 2 Core Leaders and the Senior Responsible Officers (SRO), prior to the Front Line Commands assuming responsibility as Customer 2 (Pivotal Management). Integral to these activities is the development and provision of high-level Joint and single-service doctrine, ensuring interoperability and coherence across International, Joint and Single-Service domains. The specifics of this will be covered in the following section: In-Service Development of Doctrine. 94. Figure 3-16 shows the key architectural outputs for the Applied Concepts stage and how these fit within the overall process. MODAF-M10-013a Version

35 JFAC HQ (ISTAR Cell) JFACHQ PJHQ JTFHQ JTFHQ - TCE JFAC HQ (Current Ops Cell) JFLCHQ JFLCHQ (G2 / G3 Ops) 16 AAB (G3 Ops) Policy Concepts & Doctrine Analytical Concepts Applied Concepts In Service Development of Doctrine StV-1 UNCLASSIFIED THE JOINT HIGH LEVEL OPERATIONAL CONCEPT CAPPING PAPER HLOC Operational Viewpoint Suite 8. The likelihood of increased involvement in low to medium intensity scenarios when the use of conventional reconnaissance forces is not possible, highlights the requirement to enhance our ability to acquire Beyond Line of Sight ISTAR information, without the need to deploy significant levels of Ground Forces. CONOP, CONEMP, CONUSE OV-1a, 1b & 1c OV-2a 11. Data fusion is a key enabler to the effective use of information. Collection, fusion and dissemination of data must be carried out in as near to real-time as possible in order to maximise the value of the information gained, and to minimise inaccuracy. OV-4 Capability Management Operations C A D M I D C A D M I T Figure 3-16: Key MODAF Relationships to Applied Concepts Development 3.7 In-Service Development of Doctrine 95. This section describes the use of MODAF for the In-Service Development of Doctrine. The four key development areas during this stage that may be helped by use of MODAF are 19 : a. NATO Doctrine: NATO is the most important security arrangement for the UK and is the principle organisation through which the UK conducts military activities. A substantial amount of operational and tactical doctrine is produced by NATO, with all three Services using it for guidance as appropriate. The export of appropriate NATO Architecture Framework (NAF) Views into MODAR as MODAF-compliant Technical Views is one way that this doctrinal information can be mandated as standards for capability architectures. b. Joint Doctrine: This is articulated in the hierarchy of Joint Warfare Publications, with the British Defence Doctrine (BDD) being the highest level of joint doctrine. It is focussed on the military strategic level of war. The principal operational level publication is the UK Operational Doctrine (UKOPSDOC). All Joint Doctrine publications can be captured for the purposes of MODAF as references within the content of the MODAF TV-1 Technical Standards Profile, while emerging Joint Doctrine can be announced within the TV-2 Technical Standards Forecast. c. Higher Level Single Service Doctrine: Both the Royal Navy and Royal Air Force produce higher-level doctrine publications (BR1806 British Maritime Doctrine and AP3000 British Air Power Doctrine). Although they are oriented to their service, they deal principally with military strategic and operational level 19 Chapter 4 - JWP 0-01 British Defence Doctrine (Edition 2). MODAF-M10-013a Version

36 and are best described as single service perspectives on joint doctrine at those levels 20. As with Joint Doctrine, these publications should be referenced within the appropriate TV-1 Technical Standards Profile for the architecture being developed. d. Single Service Tactical Doctrine: Some elements of tactical doctrine will, by their nature, be exclusively Single Service. They are the responsibility of the Single Service, but will be consistent with Joint Doctrine. 96. The development of doctrine during the in-service phase of the CADMID/CADMIT cycle will involve most of the MODAF COIs. High-level Strategic and Joint doctrine will be overseen by the JDCC and Single Service Concepts and Doctrine branches, while the development of operational and tactical doctrine will be led by the Customer 2 Core Leaders with input from Pivotal Managers, Customer 1 and the Acquisition communities. 97. Key outputs from the operational and tactical level of doctrinal development will be the Tactics, Techniques and Procedures (TTPs) and Standard Operating Procedures (SOPs). While these textual outputs will, by their nature, be referenced using MODAF TV-1 Views, supporting MODAF Views can assist in providing capability operational detail. Specific MODAF Views that can be used for this include the underpinning OV-1, OV-2 and OV-4 Views developed to articulate the CONOP, CONEMP and CONUSE, and the supplementary operational Views: OV-3 Operational Information Exchange Matrix, OV-5 Operational Activity Model and OV- 6a Operational Rules Model. These supplementary Views will not be developed specifically by the Concepts and Doctrine COI, but rather as the result of collaborative efforts between this community and all other parties to the capability delivery. However, in terms of specific doctrinal content, the OV-6a enables the extraction of detail from doctrine to constrain how a mission or operation will be conducted. 98. OV-3 Operational Information Exchange Matrix: This View (Figure 3-17) is used to detail the information exchanges, identifying who exchanges what information, with whom and why the information is needed and how the information exchange must occur. Certain attributes of the information exchange can be crucial to an operational activity and should be detailed as attributes of the View. 20 BDD serves the Army s needs for higher-level doctrine. MODAF-M10-013a Version

37 Needline ID Fr om To Content Med iu m 1 PJHQ BDE HQ BDE TASKING ORDER SAT COMM 2 BDE HQ MAIN OPERATING BASE BG TASKING ORDER BOWMAN 3 MAIN OPERATING BASE FIGHTING PATROL PATROL TASKING ORDER BOWMAN 4 FIGHTING PATROL KESTREL KESTREL TASK ORDER UHF RX/TX 5 KESTREL FIGHTING PATROL TACTICAL ISTAR INFO UHF RX/TX 6 BDE HQ GROUND STATION OPERATIONAL ISTAR TASK ORDER BOWMAN 7 GROUND STATION SPECS 2 SPECS 2 TASK ORDER LINK 16 8 PJHQ AIRCRAFT CARRIER STRATEGIC ISTAR TASK ORDER SAT COMM 9 AIRCRAFT CARRIER NEMESIS NEMESIS TASK ORDER LINK NE MESI S AIRCRAFT CARRIER STRATEGIC ISTAR INFO LINK NE MESI S GROUND STATION STRATEGIC ISTAR INFO LINK SPECS 2 GROUND STATION OPERATIONAL ISTAR INFO LINK BDE HQ PJHQ BDE AFTER ACTION REPORT SAT COMM 14 MAIN OPERATING BASE BDE HQ BG AFTER ACTION REPORT BOWMAN 15 FIGHTING PATROL MAIN OPERATING BASE PATROL AFTER ACTION REPORT BOWMAN 16 GROUND STATION BDE HQ OPERATIONAL ISTAR INFO BOWMAN 17 AIRCRAFT CARRIER PJHQ STRATEGIC ISTAR INFO SAT COMM Figure 3-17: OV-3 articulating a Warfighting Scenario 99. OV-5 Operational Activity Model: The OV-5 View ( Figure 3-18) is a useful MODAF product for describing capabilities and relating them to mission accomplishment. It describes the operations that would be normally conducted during a mission and can be used to: a. delineate lines of responsibility for various activities when coupled with an OV- 2; b. uncover redundant operational activities; c. flag issues or operational activities that need further scrutiny, and d. provide the foundation for depicting the sequence of activities and timing for the associated OV-6a. MODAF-M10-013a Version

38 Figure 3-18: OV-5 articulating a Warfighting Scenario 100. OV-6a Operational Rules Model: The OV-6a View specifies operational rules that are constraints on an operation or mission. It is an important View inasmuch as it describes what cannot be done and what must be done. At a mission level, the OV-6a may consist of doctrine, guidance, rules of engagement and so forth. At an operational level, the View may include engagement rules such as those found in an OPLAN The detailing of the rules can be quite complex and the structure of the rules can be challenging. For the purposes of the Concepts & Doctrine community the View is most usefully articulated as text with the rules language likely to be English, and extracted source material needing restructuring to meet the View requirements. The rules are most likely to be constructed as Action Assertions, where the rule will either be a condition, an authorisation or a derivation Conditions use a statement (e.g. If Then ), where if the condition is met then this may signal further action assertions that may need enforcing or testing further. Authorisations confer certain actions to certain human roles, while derivations use a series of statements to compute a derivable fact (Figure 3-19). MODAF-M10-013a Version