MINISTRY OF DEFENCE. MOD Architectural Framework Customer 1 Community of Interest Deskbook

Transcription

1 MODAF-M MINISTRY OF DEFENCE MOD Architectural Framework Customer 1 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-M Version 1.0 2

3 Customer 1 MODAF 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 Customer 1 Business Processes and Activities Architecture Development Process Six-Stage Architecture Development Process Architectural Data Sources Application to Customer 1 Process Overview of MODAF View use Ensuring views are MODAF compliant Customer 1 Processes Key to the Process / View Mapping Diagrams Develop Capability Taxonomy Decompose Vision into Capability Taxonomy Conduct Capability Audit Gather Information for Capability Audit Analyse Data & Identify Capability Issues Schedule Capability Delivery Develop Options Review Capability Submissions across DEC & Customer Develop Capability Options & BOI Studies Establish Equipment Programme Report Preferred Capability Option(s) To JCB Review Programmes & Expenditure Revise & Re-work Options Decision Conference (JCB) Articulating Capability Options Post EP Baseline Requirements Development Develop URD Beyond URD Baseline Worked Example ISTAR Worked Example Introduction Develop Capability Taxonomy Conduct Capability Audit Gather Information For Capability Audit Analyse Data & Identify Capability Issues Develop Options Establish Equipment Programme Requirements Development Summary MODAF-M Version 1.0 3

4 5. Document Maintenance Bibliography MODAF-M Version 1.0 4

5 Table of Figures Figure 1-1: Enterprise Architecture Views Figure 2-1: MODAF Viewpoints Figure 2-2: MODAF 1.0 Baseline Products Figure 2-3: Community of Interest Deskbook Scope Figure 3-1: General Process for Building MODAF-Compliant Architectures Figure 3-2: Key Elements and Interfaces of Customer 1 COI Processes Figure 3-3: Key MODAF Relationship to Develop Capability Taxonomy Activities Figure 3-4: Example StV-1 Capability Vision Figure 3-5: Decomposition of StV-1 into StV-2 Capability Taxonomy Figure 3-6: Key MODAF Relationship to Conduct Capability Audit Activities Figure 3-7: DEC CCII Hybrid StV-3 Capability Phasing Figure 3-8: Example of a fully compliant StV-3 Capability Phasing Figure 3-9: DEC CCII AcV-2 Equipment Programme View Figure 3-10: Example AcV-2 SoS Acquisition Programme Figure 3-11: StV-2 Depicting a Capability Gap Figure 3-12: DEC CCII Hybrid StV-3 depicting a capability shortfall Figure 3-13: Hybrid AcV-2 and Hybrid StV-3 capability delivery schedule Figure 3-14: Key MODAF Relationship to Develop Options Activities Figure 3-15: DEC CCII Hybrid AcV-2 highlighting milestone constraints Figure 3-16: DEC CCII Hybrid StV-3 informing a strategy decision Figure 3-17: Using DEC CCII Hybrid StV-3 to identify a Capability Option Figure 3-18: DEC Hybrid AcV-2 identifying milestones appropriate to a capability option Figure 3-19: Key MODAF Relationship to Establish Equipment Programme Activities Figure 3-20: MODAF facilitating capability option comparison through commonality of capability language used from StV-2 Capability Taxonomy Figure 3-21: StV-3 indicating a Capability Option Figure 3-22: Hybrid AcV-2 indicating a capability option MODAF-M Version 1.0 5

6 Figure 3-23: Key MODAF Relationship to Requirements Development Activities Figure 3-24: URD MODAF Views through CADMID Figure 3-25: StV-6 articulating a vignette, within a scenario Figure 4-1: ISTAR 'As-is' OV-1a View Figure 4-2: Extract from the ISTAR 'As-is' OV-1b View Figure 4-3: StV-1 Capability Vision Example HLOC Figure 4-4: Decomposing StV-1 ISTAR HLOC into Capability Functions Figure 4-5: ISTAR StV-2 Parameters and Metrics Figure 4-6: ISTAR AcV-2 SoS Acquisition Programme Figure 4-7: Creating & analysing ISTAR StV-3 Capability Phasing Figure 4-8: StV-4 identifying capability dependencies Figure 4-9: ISTAR StV-5 Capability to Systems Deployment Mapping Figure 4-10: ISTAR OV-1a Capability Option 1 SPECS Figure 4-11: ISTAR OV-1b Capability Option 1 SPECS Figure 4-12: ISTAR StV-3 Capability Option 1 SPECS Figure 4-13: ISTAR AcV-2 Capability Option 1 SPECS Figure 4-14: ISTAR OV-1a Capability Option 2 HASS Figure 4-15: ISTAR OV-1b Capability Option 2 HASS Figure 4-16: ISTAR StV-3 Capability Option 2 HASS Figure 4-17: ISTAR AcV-2 Capability Option 2 HASS Figure 4-18: SPECS 2 StV-6 URD scenario Figure 4-19: StV-6 articulating vignette 1 identify target Figure 4-20: StV-6 articulating vignette 2 - interoperability Figure 4-21: OV-1a articulating warfighting scenario Figure 4-22: Extract from the OV-1b describing warfighting scenario Figure 4-23: OV-1c articulating warfighting scenario performance metrics Figure 4-24: OV-2 articulating warfighting scenario Figure 4-25: OV-1a articulating vignette 1 identify target Figure 4-26: OV-1b describing vignette 1 identify target MODAF-M Version 1.0 6

7 Figure 4-27: OV-2 articulating vignette 1 identify target Figure 4-28: OV-1a articulating vignette 2 interoperability Figure 4-29: OV-1b describing vignette 2 interoperability Figure 4-30: OV-2 articulating vignette 2 - interoperability Figure 4-31: OV-3 articulating warfighting scenario Figure 4-32: OV-5 articulating warfighting scenario Figure 4-33: OV-3 articulating vignette 1 identify target Figure 4-34: OV-5 articulating vignette 1 identify target Figure 4-35: OV-3 articulating vignette 2 interoperability Figure 4-36: OV-5 articulating vignette 2 interoperability Figure 4-37: TV-1 specifying SPECS 2 standards and policies MODAF-M Version 1.0 7

8 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-M Version 1.0 8

9 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-M Version 1.0 9

10 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-M Version

11 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-M Version

12 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 Customer 1 processes are: a. Improved definition of both capability and user requirements; by providing an integrated set of views to support requirements development. b. More effective cross-dec working; by bringing commonality to the articulation of data across options, plans and analyses. MODAF-M Version

13 c. Reduced risk to the equipment programme through improved delivery assurance; by providing traceability of requirements into the activities of Acquisition, Sustainment and Customer Guide to Deskbook Purpose 17. The purpose of this document is to illustrate to the general Customer 1 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 Customer 1 community s processes (see Section 3). For each process, the required or useful MODAF Views are specified illustrating whether the process requires input from Products 2 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 Customer 1 Deskbook forms part of the overall suite of MODAF 1.0 baseline documentation as shown in Figure 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-M Version

14 MODAF Executive Summary MODAF Overview MODAF Technical Handbook Customer 1 Deskbook COI Deskbo MODAF COI ok Deskbo COI Deskbook ok 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 3 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 4 (ERM). iii. Taxonomy 5 provides the approved names and definitions for architectural objects to be used within the MOD s architectures 3 MODAF Meta Model, IA/02/16-ERMcm04 Version 1.0. Please refer to the IA for more information. 4 Enterprise Reference Model, IA/02/16-ERMcm06 Model Version 2.1, 15 August 2005 and Document version 1.1, 15 August MODAF Taxonomy Requirements, IA/02/16-ERMcm05 Version 1.0. Please refer to the IA for more information. MODAF-M Version

15 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 Figure 2-3: Community of Interest Deskbook Scope 23. The high level scope of these COIs is: Constraints 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) 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 MODAF-M Version

16 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 6 e. Customer 2 the Core Leadership and Pivotal Management roles as defined in Smart Acquisition 7 and described further in the Joint and Single Service 2nd Customer Handbooks Deskbook Structure 24. The remainder of the MODAF Customer 1 Deskbook comprises two key sections: a. Section 3 - MODAF s Relationship to the Customer 1 Processes and Activities this section explains the process of architecting as applied by those engaged in the Customer 1 processes. Specifically, it identifies the key activities in the capability management, equipment planning and URD development processes and outlines how these align with the MODAF Viewpoints. b. Section 4 - Worked Example of MODAF in Customer 1 this section demonstrates how MODAF can be used practically within Customer 1 by means of a real-life architecture example. 25. In addition, the following reference guides are available that summarise key elements of this Deskbook: a. Capability Management Guide b. User Requirements Document Guide 6 Covered in the Customer 2 Deskbook as the Maintain Military Capability process 7 For further detail, see Smart Acquisition Handbook, available at 8 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-M Version

17 3. MODAF Relationship to Customer 1 Business Processes and Activities 3.1 Architecture Development Process 26. 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 27. 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-specific 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 Select ion 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 Tax onomy MODAF Help Desk MODAF Help Desk To ol A dvi ce ERM / M3 Figure 3-1: General Process for Building MODAF-Compliant Architectures 28. 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. 29. 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 MODAF-M Version

18 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. 30. 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 32. 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. 33. 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. 34. 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 for the IA Application to Customer 1 Process 35. Customer 1 users will develop and use MODAF architectures to support the activities in the DEC two-year Capability Management Roadmap 10. Additionally, they will apply architectures to the development of user requirements during the early stages of the CADMID Acquisition process 11. The architectures created will contribute to a shared and integrated body of knowledge that will ultimately facilitate future iterations of these Customer 1 processes, but also provide direct support to the activities of other communities, Acquisition, Concepts & Doctrine and Customer 2. 9 Interim NEC, CBM and BMS MODAF Modelling Policy, DEC (CCII) File ses , 1/3/ DEC (CCII) Capability Management Roadmap - Version 2 - two year cycle Acquisition Management System (AMS) - MODAF-M Version

19 36. For Version 1.0 of MODAF, Views have been mapped to Customer 1 processes based on a series of engagements with the DEC community and an understanding of the Customer 1 processes. The application of specific MODAF Views to the different elements of Customer 1 activity is described in more detail later in this section Overview of MODAF View use 37. 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). 38. 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. 39. 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 Customer 1 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. 40. 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 Customer 1 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. 41. 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. 42. 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-M Version

20 3.1.5 Ensuring views are MODAF compliant 43. 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. 44. 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. 45. 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 Customer 1 Processes 46. This Deskbook describes the architectural processes as they relate to the Customer 1 community by reference to the Customer 1 process model shown in Figure 3-2. This diagram also shows the key interfaces with the other communities considered within the MODAF Deskbooks. Concepts & Doctrine Feedback & Issues Operations Customer 1 HLOC Capability Management C A D M I D C A D M I T EP URD Develop Capability Taxonomy Conduct Capability Audit Develop Options Capability Management Establish Equipment Programme Requirements Development Figure 3-2: Key Elements and Interfaces of Customer 1 COI Processes 47. The Customer 1 COI processes interface with all of the other COIs, except Sustainment. The key inputs and outputs are: MODAF-M Version

21 a. Concepts and Doctrine takes analytical concepts, including the High Level Operating Concept (HLOC), and translates them into capability requirements within the overall Capability Taxonomy, as the basis for driving the acquisition process. b. Acquisition provides the Equipment Plan (EP), and subsequent User Requirements Documents (URD) that form the basis for acquiring capability. c. Customer 2 receive feedback and issues from Customer 2 Core Leaders (CL) who provide input to Capability Management and Requirements Development processes through working groups, or as assigned Customer 2 leaders on aspects of the process. 48. The role of MODAF architectures in supporting the Customer 1 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 complete one-page diagram of how the MODAF views map to Customer 1 processes is held in Appendix 5. Each of the following sections refers to appropriate segments of that process to maintain clarity Key to the Process / View Mapping Diagrams 50. The key to the Process / View mapping diagrams in the following sections, and as shown in Appendix 1, is as follows: a. Activities are shown as unshaded rectangles with the name of the activity inside the rectangle b. MODAF Views are shown as inputs and outputs: i. Essential MODAF Views are shown as rectangular objects, colour-coded by Viewpoint as shown in Figure 2-1. ii. Highly desirable MODAF Views are shown as ellipse objects, similarly colourcoded by Viewpoint as shown in Figure 2-1. c. Inputs and outputs are shown as arrows from the process to / from the appropriate MODAF Views. If the arrowhead points to the View, it indicates that the process produces architectural products that conform to that View. If the arrowhead points to the process, it indicates that the process uses products that conform to that View. 3.3 Develop Capability Taxonomy 51. This section describes the use of MODAF in the Develop Capability Taxonomy process. The key activity that is helped by the use of MODAF is that of Decomposing the Capability Vision, namely the High Level Operating Concept (HLOC). 52. Figure 3-3 shows the key architectural products for Developing the Capability Taxonomy, and how this fits within the overall process, as previously shown in Figure 3-2. MODAF-M Version

22 Develop Capability Taxonomy Conduct Capability Audit Develop Options Capability Management Establish Equipment Programme Requirements Development StV-1 StV-2 Decompose Vision Into Capability Taxonomy CRD & Capability Taxonomy Figure 3-3: Key MODAF Relationship to Develop Capability Taxonomy Activities Decompose Vision into Capability Taxonomy 53. The high-level capability vision is presented as a StV-1. This outlines the future capability requirements as a textual description. Figure 3-4 is an example of a StV-1. This will normally be provided to the Customer 1 Community as an input from the Doctrine and Operational Concepts Community (i.e. JDCC and single service doctrine branches). See the MODAF Concepts & Doctrine Deskbook 12 for more information. 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 12 MODAF Concepts and Doctrine Deskbook, MODAF-M10-013, Version1.0. MODAF-M Version

23 54. In order to specify clearly the capabilities required, the StV-1 Capability Vision is deconstructed into a set capability functions. The capability function decomposition, known as a Capability Taxonomy, is represented by MODAF in a StV-2 View. 55. The StV-2 Capability Taxonomy is structured hierarchically, sub-dividing each capability function into sub-capabilities and/or functions where necessary, to provide clarity and the necessary level of granularity to support subsequent processes. The terms used in the StV-2 should be expressed only in non-platform specific effects based terms. 56. In addition to the capability nomenclature, appropriate quantitative attributes and metrics for that specific capability or function should be included; e.g. the required speed of processing, the rate of advance, the maximum detection range, etc. The quantitative values attached to each capability can be expressed as being linked to a specific epoch, or be 'as-is' values or 'to-be' targets. 57. The process of capability function decomposition and the resultant StV-2 is shown in Figure 3-5 below. Figure 4-5 in the worked example provides an example of a StV-2 that includes capability metrics. UNCLASSIFIED THE JOINT HIGH LEVEL OPERATIONAL CONCEPT CAPPING PAPER CCII Elements Capability Sub-capabilities 1 2 C4 Integrated Command and Strategic (HQ) CBM Battlespace Management Operational (HQ) CBM (CBM) CBM of Tactical Land Manoeuvre CBM of Tactical Maritime Component Operations CBM of Tactical Air Component Operations Global Information User Capabilities Infrastructure Basic Infrastructure Capabilities Infrastructure Enabling Capabilities Air Traffic Control Figure 3-5: Decomposition of StV-1 into StV-2 Capability Taxonomy 58. The StV-2 Capability Taxonomy can be used to show both the capability that currently exists, and that required in future epochs. This can be achieved by annotating a single StV-2 to identify which capability functions relate to either current or future requirements. Alternatively, two individual StV-2 architectures can be created, one to represent current capability, and one to represent future capability. New capability functions are integrated into the wider DEC Capability Taxonomy through a process of review and rationalisation of the capability required. 59. Note that the reference to capability in the MODAF views implies a full military capability ; that which includes all Defence Lines of Development (DLOD). This is in contrast to the definition of equipment capability, which refers solely to the capability of equipments, systems or system of systems, ignoring the contribution of persons, organisations, processes etc. These definitions are reflected in the MODAF Glossary of Terms MODAF Glossary of Terms is held as a separate document. Reference MODAF-M Version 1.0 MODAF-M Version

24 60. The completed StV-2 can form the basis of a Capability Requirements Document (CRD) 14. It is an expression of the capability functions agreed to be developed and deployed to fulfil, in part, the strategic capability vision. 61. The CRD, or the StV-2 Capability Taxonomy (in circumstances where a CRD is not produced), then provides the basis on which to carry out a Capability Audit. It also forms the basis for decomposing a set of user requirements later in the process, ensuring a close alignment between user need and the high-level capability vision. 3.4 Conduct Capability Audit 62. This section describes the use of MODAF in the Conduct Capability Audit process. The key activities that are helped by the use of MODAF are: a. Gather information for the capability audit b. Analyse data and identify capability issues c. Schedule capability delivery 63. Figure 3-6 shows the key architectural products for Conducting a Capability Audit, and how this fits within the overall process, as previously shown in Figure 3-2. Develop Capability Taxonomy Conduct Capability Audit Develop Options Capability Management Establish Equipment Programme Requirements Development Conduct Capability Audit StV-2 StV-3 AcV-2 StV-2 StV-3 StV-3 AcV-2 CRD & Capability Taxonomy Gather Information For Capability Audit Analyse Data & Identify Capability Issues Schedule Capability Delivery Draft CAP Figure 3-6: Key MODAF Relationship to Conduct Capability Audit Activities Gather Information for Capability Audit 64. Before the Capability Audit process can begin, the relevant capability information is collated. Information required includes: a. The consolidated Capability Area Plan (CAP) specific DEC CAPs submitted during the last cycle and any revised versions produced in the interim b. Programmatic data status of programmes and projects that are planned within the DEC, those that are dependant on the DEC, those that are in-progress, or have been delivered since the last submission c. Updates to doctrine and strategic guidance High Level Operating Concept (HLOC), Defence Planning Assumptions (DPAs), etc. 14 Draft Capability Requirements and User Requirements Paper - D/DEC(GM)/9/6/5 MODAF-M Version

25 65. Some of this information is collected in the form of MODAF Views. Firstly, the StV-2 Capability Taxonomy is required, as the framework against which capability gap analysis can be performed in the Capability Audit. As previously shown in Figure 3-5, it is a structured articulation of the capability requirement. 66. It is then highly desirable to call upon (but not essential) the StV-3 Capability Phasing View, which shows the current capability delivery schedule. It supports the identification of capability shortfalls and capability surpluses, by epoch. 67. Examples of StV-3 are shown in Figure 3-7 and Figure 3-8. Figure 3-7 shows the DEC CCII Hybrid StV-3 that is collated before the Capability Audit reference Section 37 on hybrid views. It utilises a sub-set of the potential data elements available to a StV-3, as it does not identify the systems that contribute to a particular capability. 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. 68. StV-3 is underpinned by programmatic data that specifies when capability is being delivered, upgraded and withdrawn. This data should in the longer term be available from the MODAF repository, MODAR, populated by the Acquisition community. In the near term, it is collated and maintained by DEC liaison with the IPTs. 69. The capability decomposition in StV-3 is expressed in alignment with StV-2. (Note: MODAF defines periods of time, not epochs, in its viewpoints. Epoch is mentioned in this text due to its applicability to Customer 1. A StV-3 does not have to be structured in epochs; an appropriate period of time can be used.) Figure 3-7: DEC CCII Hybrid StV-3 Capability Phasing Figure 3-8 shows a fully MODAF compliant StV-3. It utilises the full compliment of data elements, by additionally showing the systems that contribute to each capability in the capability taxonomy. It is created by mapping the systems to capability functions across relevant epochs; noting system delivery, upgrade and withdrawal. Each capability function is fulfilled by one or more systems, appropriate to specific epochs. The change in colour applied across the view reflects a change in capability level between two epochs - in a similar manner to that shown in the DEC Hybrid StV This modified CCII view is convergent and not fully compliant with the MODAF StV-3 specification. MODAF-M Version

26 CAPABILITY FUNCTIONS Epoch 1 (Now ) Epoch 2 ( ) Epoch 3 ( ) Epoch 4 ( NEC enablers ) COMMAND BATTLESPACE MANAGEMENT Decision Support Op Planning JOCS (IPM only)/gp3(hq ARRC JOCS (IPM only)/gp3(hq ARRC JOCS/ComBAT/GP3 (HQ ARRC JC2SS(F)/JTOC/ComBAT/ARRC C2IS only)/rafccis/rn CSS only)/rafccis/rn only)/rafccis/rncss/jc2ss(f) Operational Analysis JC2SS(F)/ComBAT?/ARRC C2IS? Mission Rehearsal JTOC IOC JTOC JTOC/ComBAT?/ARRCC2IS? Situational Awareness BMETS/JOCS/GP3(HQ ARRC BMETS/JOCS/BSAM/GP3(HQ ARRC ComBAT/GP3 (HQ ARRC ComBAT/CID?/JC2SS/HVMSIFF/ARRC only)/rncss only)/rncss/hvm/rafccis only)/jocs/rncss/hvm SIFF/GBAD RAP C2IS/GBAD RAP IOC-FOC/ASTRID/T23 SIFF/RAFCCIS/INRTIBS/JC2SS(C)/JP IOC/Gnd BTIDS/INRTIBS CEC/Gnd & Air BTIDS/INRTIBS C/NIRS Intelligence JOCS (IPM only)/gp3(hq ARRC only)/rncss/rafccis JOCS (IPM only)/gp3(hq ARRC only)/rncss/rafccis/amir? JOCS/G2 BISA/GP3 (HQ ARRC only)/amir?/j2-g2 ISTAR BISA J2-G2 ISTAR BISA/AMIR Decision Support Interoperability Joint Strategic Intelligence LOCE MIDB/LOCE Operational Intelligence INT-C/CTT INTELWEB?/MIDB/INRTIBS/CTT Joint Logisitcs JCS Log JCS Log NATO C2 & Int CRONOS (IPM only) NIDTS/NSWAN ACE ACCS Bi-SCAIS NATO Comms CWAN (IPM only?) Land US Coalition FBCB2?/MCS? FBCB2?/MCS?/ACBS?/MBCOTM?/FCS?/AMDWS?/ASAS?/CSSCS? Allied Interoperability US-GCCS (IPM only) MIP Messaging/US-GCCS MIP Database/US-GCCS Maritime RNCSS/LPD(R)/T22/T23/T42/CVS RNCSS/LPD(R)/T22/T23/T42/CVS/T45 Air C2/Coord Functional Planning Support Info Ops Planning JFAC-JPC/RAFCCIS/NICC/NIRS BSMS JFAC-JPC/RAFCCIS/NICC/NIRS/JC2SS DACCS/JFAC-JC2SS Logistic Planning AP3/QP24 AP3 Log C4 BISA/G1 BISA? Medical SGIS Medical BISA? Aviation Logistics Sp ACCESS ACCESS Air Support BISA? Personnel Planning AP3/JCSLog G1 BISA?/JCS Log G1 BISA?/JCS Log/JC2SS EW Planning SOOTHSAYER Air Defence Planning ADCIS AD BriC IGBAD IOC Artillery Fire Planning BATES FCA FCBISA/IFPA JETTS IOC? Air Planning Engineer/EOD Planning WAH-64 GSS ASH AM BISA MAKEFAST/EOD BISA CIS Planning GP3 GP3/BSAM GP3/ComBAT ComBAT NBC BRACIS/BATES/BRACIS NT NBC BISA/BATES NBC BISA Comms Management BCMS/CORMORANT CMS FALCON CMS/BCMS/CORMORANT CMS IS Management ATacCS/JOCS/RNCSS/RAFCCIS DBL II EOC DBL II IOC & FOC/DII(F)D Inc 2 Functional Planning Support Interoperability NATO AD Allied Fire Support AFATDS-ASCA ACCS LOC1 AFATDS II-ASCA Medical JPASS/In barracks Med Figure 3-8: Example of a fully compliant StV-3 Capability Phasing 71. Finally, the Acquisition View AcV-2 is collated to show when the acquisition programmes are expected to deliver scheduled capability, to support decision making during the Capability Audit and Equipment Planning activities. 72. Examples of AcV-2 are shown in Figure 3-9 and Figure Figure 3-9 shows the DEC CCII Hybrid AcV-2 collated before the Capability Audit, known as the Equipment Programme (EP) View. It utilises a sub set of the MODAF AcV-2 data elements, as it does not currently identify programme dependencies or programme status across DLODs. Figure 3-9: DEC CCII AcV-2 Equipment Programme View The DEC CCII AcV-2 is convergent but not a fully compliant MODAF AcV-2 View. MODAF-M Version

27 73. Figure 3-10 shows a fully MODAF compliant AcV-2 that utilises the full compliment of data elements, additionally showing programme dependencies and status across all DLODs at each stage boundary. 74. The dependency lines shown on an AcV-2 represent a known dependency between two acquisition programmes. They do not represent the nature of the dependency or any level of granularity beyond the link between acquisition programmes. i.e. they do not represent dependencies between specific DLOD as could be interpreted from Figure 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 Trai ning Equipment LoD 'Segment' Project Phase Key to View Pe rso nnel Inf ormation Logistics Infrastructure No outstanding issues Manageable issues Critical issues Pre-IG IG to MG MG to IOC IOC to FOC D octrine/ C oncepts Organisation DLOD Absent In Service DLOD Not Applicable Disposal Figure 3-10: Example AcV-2 SoS Acquisition Programme Analyse Data & Identify Capability Issues 75. When the relevant information has been collated, the Capability Audit process can begin. In this example, we will assume that a full Capability Audit is required, as similar processes can be applied to a partial Audit. The aim of the Audit is to determine capability surpluses and shortfalls within the DEC, against the composite requirements defined by the Defence Strategic Plan, DPAs, HLOC, etc. 76. The primary View used is the StV-2 Capability Taxonomy, which comprehensively lists the capability functions required to fulfil the vision. The first step is to review the list and check for missing or excess capability requirements in the logical decomposition. A logical gap in the Capability Taxonomy is depicted in Figure MODAF-M Version

28 Capability Sub-capabilities 1 2 C4 Integrated Command and Strategic (HQ) CBM Battlespace Management Operational (HQ) CBM (CBM) CBM of Tactical Land Manoeuvre CBM of Tactical Maritime Component Operations CBM of Tactical Air Component Operations Global Information User Capabilities Infrastructure????? Basic Infrastructure Capabilities Infrastructure Enabling Capabilities Air Traffic Control Figure 3-11: StV-2 Depicting a Capability Gap 77. The StV-2 should be updated to reflect required capability, and it can then be analysed to confirm which capability functions are already deployed, and which are scheduled for delivery. Any capability functions not accounted for are highlighted as capability gaps, and are noted in the Capability Shortfall Catalogue. StV-2 however, neglects to show capability delivery timing, and thereby omits to show further capability surpluses and shortfalls associated with particular epochs. 78. Here, the StV-3 Capability Phasing View can be used; it is highly desirable but not essential. It can be updated to reflect both the required capability functions in the Capability Taxonomy, and the representative level of capability associated with an epoch. Figure 3-12: DEC CCII Hybrid StV-3 depicting a capability shortfall 79. Capability surpluses and shortfalls are identified in a StV-3 as changes in the colour code. In the DEC Hybrid StV-3, the colours highlight when the level of capability drops below, or rises above, a pre-defined threshold. Figure 3-12 highlights two capability shortfalls in 2014 as a red colour code, against Tactical Land CBM and Tactical Air CBM Capabilities. 80. In a fully compliant MODAF StV-3, the View also identifies the systems that contribute to a capability as Figure 3-8. In this instance, capability surpluses and shortfalls can then be observed by the presence, or not, of systems in support of a capability function. The View clearly identifies system gaps and overlaps across epochs because systems are named within the View construct. All further capability gaps identified from StV-3 are entered into the Capability Shortfall Catalogue. MODAF-M Version

29 81. At this point, the identification of either a shortfall or surplus can be used as the start point for a more in-depth analysis to confirm the existence and nature of the capability surplus or shortfall. This is an instance of Operational Analysis (OA) and can be described as Capability Analysis because its objectives include: a. Confirming that the capability is truly an issue, by considering different operational scenarios and or use cases b. Expanding on the detail of the capability issue to develop a more robust case for the capability requirement c. Determining exactly when the capability issue truly becomes a shortfall or surplus d. Understanding the performance implications of ignoring the capability issue. 82. Capability Analysis is supported by a range of MODAF views dependent upon the specific intent of the analysis refer to the explanation of MODAF's support to OA in section Capability analysis would include both views from the MODAF Strategic Viewpoint suite and the Operational Viewpoint suite. Two key Strategic Views, StV-4 Capability Clusters and StV-5 Capability to Systems Deployment Mapping would likely be called upon. StV-4 highlights other capabilities impacted a surplus or shortfall, and StV-5 confirms deployment surpluses or shortfalls across organisational units Schedule Capability Delivery 83. Having identified capability surpluses and shortfalls and understood to a greater degree the implications across the organisation, the next step is to schedule capability delivery. 84. To achieve this, the planner firstly confirms the relative capability priorities (initially priorities are based on a local assessment to the DEC). In line with priorities, new capability delivery is scheduled into the overall DEC capability picture, and provides for the core body of the draft Capability Area Plan (CAP). 85. The process of scheduling capability delivery is informed by programme milestone, status and dependency information provided by the SoS Acquisition Programmes AcV-2 View. The information detailed in this View informs and constrains the various capability schedule options. 86. Scheduled capability is presented on both the AcV-2 SoS Acquisition Programme View and the Hybrid StV-3 Capability Phasing View, by updating them with the programme milestones and capability levels respectively. Annotation is used to identify the scheduled capability within the overall capability picture, as shown in Figure MODAF-M Version

30 Figure 3-13: Hybrid AcV-2 and Hybrid StV-3 capability delivery schedule 87. The completed Hybrid Views AcV-2 and StV-3, along with other Views used during the capability audit process become part of the Capability Area Plan (CAP). The CAP provides a record of the activities carried out and an audit trail of the Capability Audit. 3.5 Develop Options 88. This section describes the use of MODAF in the Develop Options process. The key activities that are helped by the use of MODAF are: a. Review (CAP) submissions across DEC & Customer 2 b. Develop capability options & Balance Of Investment (BOI) studies 89. Figure 3-14 shows the key architectural products for Developing an Option, and how this fits within the overall process, as previously shown in Figure 3-2. Develop Capability Taxonomy Conduct Capability Audit Develop Options Capability Management Establish Equipment Programme Requirements Development StV-3 AcV-2 StV-3 AcV-2 Draft CAP Review Submissions Across DEC & C2 CAP Develop Capability Options & BOI Studies Capability Option Figure 3-14: Key MODAF Relationship to Develop Options Activities Review Capability Submissions across DEC & Customer When the Capability Audits have been completed in each of the individual DECs, the draft CAPs are brought together in the Capability Audit Workshop. The aim of the Capability Audit Workshop is to understand, confirm and rationalise the capability plans across the DECs. 91. It is during this stage that the benefit of MODAF as a common language is more apparent. Firstly, the capability propositions are presented with common MODAF MODAF-M Version

31 Views, and as such, the draft CAPs can be more easily absorbed, compared and contrasted. Secondly, because consistency is provided by the MODAF data structure, revisions and/or combinations of the plans can be generated more quickly. 92. MODAF Views brought into this stage provide a source of constraints information, and a means to analyse and identify preferable delivery strategies. Constraints across the DEC-wide capability picture restrict the initial aspirations of the DEC draft CAPs. The types of constraint include: a. Feasibility the need to ensure that the capability can be delivered, deployed, integrated and supported in the given timescales, budget and environment (environment noted in the widest sense including external influences). b. Operational strategy the need for alignment and coherence with cross-dec strategies c. Business capacity the need for the business to absorb the capability within existing capability picture, and within the portfolio of acquisition programmes. 93. The DEC CCII Hybrid AcV-2 SoS Acquisition Programme is the primary View used to identify constraints. It presents feasibility constraints as the milestones of other acquisition programmes. The milestones of other programmes will inform the capability schedule and approach. This is shown in Figure Figure 3-15: DEC CCII Hybrid AcV-2 highlighting milestone constraints 94. The fully compliant MODAF AcV-2 also highlights the status of dependent programmes across all DLOD. It then provides a level of confidence as to the likelihood of delivering the proposed capability schedule on time. For example, consider that the status of an IT infrastructure programme is RED; the likelihood of timely delivery is low. With a set of four capability propositions, three dependent on the IT infrastructure programme, it may be advantageous to select the fourth option on the basis that timely delivery is more important than accepting a risk associated with late delivery. 95. Operational Strategy and Business Capacity Constraints can be identified by calling upon other MODAF views (refer to MODAF Viewpoint Overview 17 for details of 17 MODAF Viewpoint Overview, MODAF-M Version 1.0. MODAF-M Version

32 other Views). For Operational Strategy Constraints, OV-1a can be used to identify dependencies on other military objects in a scenario, and factors associated with the battlespace physical environment. For Business Capacity Constraints, StV-5 Capability to Systems Deployment Mapping can be used to indicate, at a high level, the capacity of an organisation to absorb additional capability delivery. 96. Capability delivery strategy can be informed by the Hybrid StV-3 Capability Phasing View. Figure 3-16 shows how it can support the questioning or challenge of different strategies; namely, whether addressing the Tactical Land CBM capability is of greater importance than that of Tactical Air CBM, or whether both capability shortfalls could be addressed, but to a lesser degree. OR Figure 3-16: DEC CCII Hybrid StV-3 informing a strategy decision 97. When using a fully compliant MODAF StV-3, the systems that provide for the capability enable greater strategy analysis. Discussions extend to whether system augmentation, or further fragmentation, across capability functions is the best strategy approach. For example, it may be worth decommissioning one system earlier than scheduled to align with the delivery of a new joint system that will provide for both this capability, and other capabilities. 98. The output of the capability workshop is a baseline CAP, presented as a refinement of the MODAF Views already created. StV-3 is produced to reflect a schedule of capability delivery that aligns with DEC-wide strategy, rather than as previously, the local DEC requirements Develop Capability Options & BOI Studies 99. The baseline CAPs feed into the first year of the two-year Equipment Programme (EP), and are reviewed against the spending commitments of the current equipment plan, and the forecast expenditure of the current acquisition programme portfolio At this stage, the Joint Capabilities Board (JCB) request that the individual DECs carry out Excursion and Balance of Investment (BOI) studies to specify a realistic and affordable equipment programme. The DECs develop Capability Options as variations to the EP that may deliver more capability in specific areas, or deliver capability more swiftly or over a wider scope at less depth. The Capability Options must deliver the EP within the overall budget, bounded by Resource Control Targets (RCTs) set by the JCB This process currently involves the development, analysis and sifting of numerous capability options, culminating in 100+ capability options that are finally?? MODAF-M Version

33 presented to the JCB, of which 6-12 may be selected to go forward. The options cover numerous capability domains and are compiled in very short timescales, based primarily on cost MODAF views cannot currently be used to articulate each capability option at this stage in the process because of the size, complexity and urgency of the task. They can only be used to support the identification of capability options. However, looking forward to the JCB decision conference, when a handful of capability options have been approved and baselined in the Equipment Plan (EP), it is possible to articulate options using MODAF views. This articulation adds value by informing Acquisition, Concepts & Doctrine and Customer 2 activity through the coming stages of CADMID, and by supporting the next EP cycle As such, the documented MODAF support to capability option development in the following sections comprises two parts, the high level use of MODAF views in the identification of capability options at this stage in the process (but similarly in section where options are re-worked), and the suggested use of MODAF views to articulate each capability option post JCB Decision Conference, as presented in section (Note: Where, in the future, the capability option development process at this stage is characterised by only a handful of co-ordinated options reaching the JCB for decision the mapping of MODAF views to this process should be reviewed. The suggested views for articulation of capability options described in section can be taken as a starting point for determining the best MODAF view suite.) 104. The DEC Hybrid StV-3 Capability Phasing View is the basis for identifying a particular capability option; the three dimensions that form a capability option are shown in Figure Figure 3-17: Using DEC CCII Hybrid StV-3 to identify a Capability Option 105. Firstly, it identifies the capability taxonomy from which a reduced set of capability functions are selected to inform the first dimension of a particular option. Secondly, it shows the capability levels that provide for each capability function (these would be shown as systems on a fully MODAF compliant StV-3). Finally, it highlights the epochs over which the capability is delivered, as a third dimension to a capability option Figure 3-18 shows DEC CCII Hybrid AcV-2, which in a similar fashion, provides a means of identifying programme and milestone information that can be inserted into a particular capability option. MODAF-M Version

34 Figure 3-18: DEC Hybrid AcV-2 identifying milestones appropriate to a capability option 3.6 Establish Equipment Programme 107. This section describes the use of MODAF in the Establish Equipment Programme process. The key activities that are helped by the use of MODAF are: a. Report preferred capability options to the JCB b. Review programmes & expenditure c. Revise & re-work options d. Decision conference (JCB) e. Articulating Capability Options post EP baseline (Note: This activity is not forming part of the initial DEC implementation of MODAF and hence it does not form part of the Customer 1 process diagram at this time. It is however mentioned here in earnest, because of its potential benefits, and likely implementation at some point soon afterwards.) 108. Figure 3-19 shows the key architectural products for Establishing an Equipment Programme, and how this fits within the overall process, as previously shown in Figure 3-2. Develop Capability Taxonomy Conduct Capability Audit Develop Options Capability Management Establish Equipment Programme Requirements Development StV-3 AcV-2 Capability Option Report Preferred Capability Option(s) (JCB) Updated CAP Review Programmes & Expenditure Revise & Re-work Options Updated CAP Decision Conference (JCB) EP Figure 3-19: Key MODAF Relationship to Establish Equipment Programme Activities MODAF-M Version

35 3.6.1 Report Preferred Capability Option(s) To JCB 109. The capability options are collated and submitted to the Joint Capabilities Board (JCB) for prioritisation, and this forms the end of the first year of the two-year EP cycle Review Programmes & Expenditure 110. In the beginning of the second year of the EP cycle, a process of acquisition programme review and investment priority agreement enable the capability options to be prioritised and finalised by the JCB If the capability option cost decomposition is expressed against capability functions in the integrated StV-2 Capability Taxonomy provided by MODAF, then direct comparisons of cost can be made across the Capability Options, and conclusions drawn more quickly (see Figure 3-20). Savings may extend from a specific combination of options between DECs, therefore enabling investment in further capability within the same epoch. Option 1 Option 2 Capability 1 Capability 1.1 Capability 1.2 Capability 1.3 Capability 1.4 Capability 1.5 Capability 2 Capability 2.1 Capability 2.2 Capability 2.3 Capability k 1.1m 500k 600k vs vs vs vs 500k 2m 0k 0k Capability 1 Capability 1.1 Capability 1.2 Capability 1.3 Capability 1.4 Capability 1.5 Capability 2 Capability 2.1 Capability 2.2 Capability 2.3 Capability m vs 2.5m Figure 3-20: MODAF facilitating capability option comparison through commonality of capability language used from StV-2 Capability Taxonomy Revise & Re-work Options 112. With reference to the initial capability option development stage, MODAF Views StV-3 and AcV-2 are updated to reflect any changes extending from option development Decision Conference (JCB) 113. The JCB presents the preferred combination of capability options as a baseline Equipment Plan (EP) to the Defence Management Board (DMB) for endorsement. A Decision Conference is undertaken to vote on the preferred capability options, and the majority preference is worked into the EP, forming a baseline version against which procurement activities can commence Articulating Capability Options Post EP Baseline 114. (Note: As mentioned above, this section is not forming part of the initial DEC implementation of MODAF but is mentioned here because of its potential benefits MODAF-M Version

36 and likely implementation at some point soon.) The baseline of the Equipment Plan is a starting point for developing a set of MODAF Views to articulate the chosen capability options in this equipment round. MODAF recommends the following views to articulate a capability option. a. StV-3 and AcV-2, as used in capability option development section b. Strategic View StV-5 Capability to Systems Deployment Mapping c. Operational Views OV-1a,b & c - the High Level Operational Concept Graphic, its description and performance attributes respectively 115. Returning to the DEC Hybrid StV-3 Capability Phasing View, Figure 3-21 shows how it can be annotated to articulate three dimensions of a Capability Option. Figure 3-21: StV-3 indicating a Capability Option 116. Firstly, it highlights the capability taxonomy from which a reduced set of capability functions are selected to form the first dimension of a particular option. Secondly, it highlights the capability levels that are characteristic of that capability option (or systems if the full MODAF compliant StV-3 was to be used). Finally, it highlights the epochs over which the capability is delivered as the third dimension to the capability option StV-3 can be supported by StV-5 to provide two additional dimensions in the specification of a capability option. It identifies, in addition to the dimensions of capability taxonomy, systems and epochs, the dimensions of organisational deployment and system interconnectivity A StV-5 specified capability option has a clear organisational scope, and a clear interconnectivity scope. Given that more complex interconnectivity requirements correlate with higher risks of implementation, the use of StV-5 is highly recommended in support of StV-3 for specification of a capability option. Returning to AcV-2, Figure 3-22 shows how it can now be used to articulate a capability option as amended programme and milestone information annotated to the existing delivery picture. MODAF-M Version

37 Figure 3-22: Hybrid AcV-2 indicating a capability option 119. With a requirement to graphically articulate the capability option, its interfaces and the environmental context to which the capability will be deployed, OV-1a is a highly effective mechanism. The flexibility of the OV-1a High Level Operational Concept Graphic enables a capability option to be depicted with all of its key interfaces. See worked example section 4.4 for an example of capability options shown as OV-1a OV-1b is a textual description of OV-1a, and must be produced with every OV- 1a created. OV-1c supports the OV-1a by listing the performance metrics associated with it. These can be drawn from the StV-2 Capability Taxonomy where available. 3.7 Requirements Development 121. This section describes the use of MODAF in the Requirements Development process. The key activity that is helped by the use of MODAF is Develop URD. This section also highlights, in summary, the activities beyond the baseline of the URD Figure 3-23 shows the proposed key architectural products for Requirements Development, and how this fits within the overall process, as previously shown in Figure 3-2. (Note: at the time of issue of this Deskbook, the proposed MODAF views and URD development sequence were not approved by the designated MOD URD process owner. They were suggested from consensus of opinion. Formal approval is expected in the next version.) Develop Capability Taxonomy Conduct Capability Audit Develop Options Capability Management Establish Equipment Programme Requirements Development Operational View Suite URD Development Sequence StV-6 OV-1 OV-2 OV-3 OV-5 TV-1 StV-6 OV-1 OV-2 OV-3 OV-5 TV-1 Pre Concept E E R Initial Gate (IG) E E E HD HD HD Main Gate (MG) E E E E E E EP Develop URD URD Figure 3-23: Key MODAF Relationship to Requirements Development Activities MODAF-M Version

38 123. SMART acquisition principles ensure that the statement of a requirement (whether it be in the CRD, URD or SRD), is distinct from that of a constraint. Requirements are pure capability statements, focussed on what needs to achieved, and not stating any association with a type solution or extant/ proposed operational environment. Constraints are used to place the requirement in context of the extant/ proposed environment, by specifying the constraining factors associated with a particular type of solution For example, a requirement might be for an underwater personnel transport capability, range 10km, capacity 20 personnel. An associated constraint might be that if the solution is a submarine, it must be able to dock at existing submarine docking stations, and satisfy the relevant standards, policies and procedures. It supplier could propose an alternative solution, along with modified or new docking stations Note that constraints can easily be confused with requirements; one could argue that there is a requirement for a solution to interface to an existing system. This is actually a constraint, as it might be that the supplier could propose a solution that avoids the need for that interface, but delivers the requirements - or capability sought after MODAF Views can be used to specify both the requirements, and the constraints. Views can be either constraint or requirement based depending on their content. As such, their use in the requirements documents needs to be clarified as the content is developed. It can be generally said that Strategic & Operational Viewpoints are more appropriate to the Requirements space, whereas System and Technical Viewpoints, the constraints space. However, the views must be considered carefully, as there are exceptions. In the following text, views are identified as supporting requirements or constraints as appropriate to the data they contain Develop URD 127. The finalised EP is used as a basis for the selection and grouping of acquisition programmes. For these programmes, user requirement sets are developed and maintained throughout the acquisition process The User Requirements Document (URD) is developed to specify the user needs, linking them back to the Capability Taxonomy, or CRD. The linkage between URD and CRD is not necessarily a one-to-one mapping; a capability may be satisfied by more than one acquisition programme and URD MODAF supports the URD with a set of Views that link the URD to the CRD, and articulate the user requirements and constraints. The choice of MOD Views is based on the use of operational scenarios and vignettes to articulate the requirements; the scenarios being based on the SAG scenarios. Visual representations of requirements and constraints provided by MODAF views are used to strengthen textual requirements, and provide a means of clarifying the complex issues involved MODAF provides StV-6 to specify the links between the capability, and the operational scenarios and vignettes. It provides a suite of Operational Views to articulate the detail of each scenario or vignette. (Note that each of the operational scenario and vignettes contained in the URD should comprise the same set of operational Views, so as to retain the ability to compare and contrast Views with each other.) 131. The development of the URD is progressive during the Concept and Assessment phases of the CADMID acquisition cycle. As such, MODAF Views are MODAF-M Version

39 applied in a progressive manner over these phases to reflect this approach to its development. This is shown in Figure 3-24; Essential MODAF Views are shown as rectangular objects, and Highly Desirable Views as ellipse objects at each step of the cycle. For further examples, please refer to the Worked Example Section Operational View suites. Concept IG Assessment MG Demonstration StV-6 StV-6 StV-6 Operational Viewpoint Suite OV-1 OV-2 Operational Viewpoint Suite OV-1 OV-2 Operational Viewpoint Suite OV-1 OV-2 Scenario/ Vignette 1 Scenario/ Vignette N OV-3 OV-5 TV-1 OV-3 OV-5 TV-1 Figure 3-24: URD MODAF Views through CADMID 132. Approaching the process in steps, firstly consider pre-concept. A StV-6 is created to provide a framework for the URD scenarios and vignettes. Scenarios are articulated as a whole StV-6, which identifies a set of capability functions and operational activities. Vignettes are identified as an annotated sub-set of capability functions and operational activities within a scenario A generic StV-6 shown in Figure 3-25 shows how to articulate a vignette comprising Activities 5, 9, 10 and 12, and Capability 2 as part of a scenario. Activity 1 Activity 2 Activity 3 Activity 4 Activity 5 Activity 6 Activity 7 Activity 8 Activity 9 Activity 10 Activity 11 Activity 12 Activity 13 Activity 14 Activity 15 Capability 1 Capability 2 Capability 3 Capability 4 Capability 5 X X X X X X X X X X X X X X X X Articulating a vignette: A set of operational activities to demonstrate Capability 2 X Figure 3-25: StV-6 articulating a vignette, within a scenario 134. This has now framed the structure of the URD, and the next step is to develop the suite of Operational Views that support it. One suite of Operational Views is created for each scenario and vignette. (Note: it is intended that the operational view suite articulates the requirement space rather than the constraint space. However, the nature of MODAF views makes its possible for a requirements architect to solutioneer at this stage unless careful consideration is given to the content of the OVs. If there is a need to include systems, interfaces etc, consider explicitly identifying and positioning that view in the constraints space rather than the requirements space.) MODAF-M Version

40 135. For the Initial Gate, the suites must comprise OV-1 and OV-2 as follows. a. OV-1, and its constituent components, is used to describe the scenario or vignette, within which the required capability will operate. The High Level Operational Concept Graphic, OV-1a identifies the operational environment, business entities and relationships within which the capability will operate. It must be supported by OV-1b, its description, and can be enhanced by an OV-1c to list operational performance attributes. b. OV-2 Operational Node Connectivity Description specifies the operational nodes, connectivity and need line information flow requirements for the scenario or vignette, and to be satisfied by the solution. This View ensures that the supplier is aware of the operational communications and interdependencies that will underpin the success of the solution For the Main Gate, OV-3 and OV-5 must form part of the suite: a. OV-3 Operational Information Exchange Matrix specifies the information exchange requirements for the scenario or vignette, and to be satisfied by the solution. This View ensures that the supplier has sufficient detail on the information flows underpinning the design of the solution. When considering information flow requirements is critical to take into account what actually happens at present, rather what is supposed to happen at present. b. OV-5 Operational Activity Model specifies the operational activity requirements for the scenario or vignette, and to be satisfied by the solution. This View ensures that user activities are visible to the supplier and highlights the dynamic nature of operational staff roles. When considering activity requirements is critical to take into account what is the actually happens at present, rather what is supposed to happen at present In addition to the Operational View suite, the Technical View is created for Main Gate. It can both specify requirements or constraints and must be placed accordingly. TV-1 can be created for individual vignettes, or be singular to the whole URD View Suite. TV-1 might specify requirements that include quality expectations, operational doctrine and sustainment SOPs. It might specify constraints that include standards for interoperability The Essential architecture supporting the URD at Main Gate is now complete. However, note that other Views may be beneficial to particular scenarios or vignettes where there is a specific need. For example, System Views can be used to highlight and define the deployed Systems requiring interconnectivity. Refer to Appendix 1, the MODAF View Summary for further information Beyond URD Baseline 139. Following the baseline of the URD, the IPT appointed by DPA, DLO or DCSA takes control of solution development, manufacture, and ultimately delivery to Customer Customer 1, as owners of the URD and with responsibility for capability delivery, are involved by IPT throughout the stages of the CADMID cycle to assure progress and accept the solution against the user requirements expressed in the URD by MODAF Views. The URD is under change control and requests for change can be raised as required, and reviewed by the designated authority. Refer to MODAF-M Version

41 Acquisition Management System (AMS) 18 for further details on maintenance of the URD. 18 Acquisition Management System (AMS) - MODAF-M Version

42 4. Worked Example 141. This section presents a worked example of MODAF View development in the Customer 1 community. It adds clarity, and realism, to the overview of the MODAF View relationship to Customer 1 processes provided in the previous section The example illustrated is based in the ISTAR community, and its level of complexity is simplified in order to avoid the need to understand specific ISTAR systems and technologies. The example does not represent the UK's ISTAR assets; it contains a number of fictional systems and entities. (Note: this worked example is based on as-is MOD processes and aspects of the capability option and user requirement development processes are expressed more in line with the solution space, than the pure capability requirement space. The later being the basis of SMART acquisition principles. As further worked example material becomes available during MODAF implementation and as requirements are developed with a purer capability focus, it is recommended that this illustrative example is replaced with something more appropriate.) 4.1 ISTAR Worked Example Introduction 143. The example covers the two-year EP cycle from the View of the ISTAR DEC. As in each of the DEC areas, systems are due into, and out of, service; in addition, doctrinal changes and revisions produce changes and subsequent enhancements to the Capability that must be delivered. Throughout this example, the process of the development and use of MODAF Views is covered in a greater level of detail than the associated EP processes, with which it is assumed that the audience is familiar. The 'as-is' ISTAR situation is shown in an OV-1a, as Figure 4-1. OV-1a is always supported by an OV-1b, its description, as provided in Figure 4-2. Figure 4-1: ISTAR 'As-is' OV-1a View MODAF-M Version

43 .ISTAR information is currently provided by the SPECS system, the LOOKER UAV system and by the NEMESIS system. SPECS is an Operational level asset, and communicates via a data link to its dedicated base station. LOOKER is a tactical UAV system that can transmit real-time video footage directly to either Fighting Patrols or to the Brigade HQ. 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 by Satellite communications or directly to a receiver based on board a Naval vessel.. Figure 4-2: Extract from the ISTAR 'As-is' OV-1b View 144. LOOKER and SPECS are both mature systems with run-out dates in the near future. NEMESIS has just entered service and has an envisaged run-out date of Develop Capability Taxonomy 145. The first step of the Capability Audit process is to decompose the Strategic Vision into a Capability Taxonomy. The Strategic Vision, in this case the HLOC, is represented as a StV-1 Capability Vision View. The relevant extract to DEC ISTAR is shown in Figure 4-3. 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. Figure 4-3: StV-1 Capability Vision Example HLOC 146. The HLOC has been revised since the last EP round, and in accordance with the associated doctrine updates, highlights the requirement for increased tactical levels of ISTAR provision and the need for near real-time data collection and fusion. MODAF-M Version

44 This Capability Vision is now decomposed into a Capability Taxonomy, represented in the StV-2 Capability Taxonomy View. The StV-2 that was developed during the previous audit is used as the basis for development of the revised StV Figure 4-4 shows the process of decomposition, and Figure 4-5 shows the resultant StV-2, including the associated parameters and metrics for each of the Capability functions. UNCLASSIFIED THE JOINT HIGH LEVEL OPERATIONAL CONCEPT Information Acquisition Information Management Effe cts 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. 1. Strategic Range: 120km km Duration: 24hrs 2. Operational Range: 20km - 120km Duration: 20hrs 3. Tactical Range: 0km - 20km Duration: 16hrs 1. Analysis 1. Targeting Accuracy: 10m 2. Fusion 2. Plan Engagement 3. Quality Assurance 3. Conduct Engagement 4. Dissemination 4. Battle Damage Assessment Figure 4-4: Decomposing StV-1 ISTAR HLOC into Capability Functions 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 4-5: ISTAR StV-2 Parameters and Metrics 148. Please note that for the purposes of this example, only a reduced set of Capability functions within the ISTAR domain are included. MODAF-M Version

45 4.3 Conduct Capability Audit Gather Information For Capability Audit 149. Firstly, relevant information and updates are gathered and collated. In this example the key information sources required are as follows: a. The latest version of the ISTAR DEC Capability Area Plan (CAP) b. The set of MODAF Views developed during the last Capability Audit and subsequent Option development c. Relevant Doctrine and Concepts revisions and updates In addition to the information gathered from the Customer 1 and Doctrinal domains, it is essential that programmatic information on current ISTAR systems, related dependant systems and other ongoing procurement activity is included. This is displayed in the form of an AcV-2 View, as shown in Figure 4-6. ISTAR SYSTEMS DISP START DISP FIN SPECS DISP START NEMESIS DISP START DISP FIN LOOKER LoD 'Segment' Project Phase Training Equipment No outstanding issues Pre-IG Key to View Personnel Information Lo gistics I nf rastructure Manageable issues Critical issues IG to MG MG to IOC IOC to FOC Doctrine/ Concepts Organisation DLOD Absent In Service Disposal DLOD Not Applicable Figure 4-6: ISTAR AcV-2 SoS Acquisition Programme 151. In this example, the run-out dates of LOOKER and SPECS are confirmed as falling at the end of Epoch 1 (date range set by the ISTAR DEC). In addition, the DPA have received a proposal for the manufacturer of SPECS, that it is possible to enhance the functionality of the system and hence prolong its in-service life Analyse Data & Identify Capability Issues 152. The next stage of the audit is to map the required capability functions to the systems that deliver or will deliver the capability. This is achieved initially using both the StV-2 Capability Taxonomy View and the StV-3 Capability Phasing View. The StV-2 View provides the taxonomy for the required capability to be delivered. MODAF-M Version

46 Systems can then be 'mapped' and 'phased' against the Capability Functions, in the StV-3 View. This mapping is shown in Figure 4-6. Capability Functions Epoch 1 Epoch 2 Epoch 3 Information Acquisition Strategic NEMESIS NEMESIS Information Acquisition Information Management Effe cts Operational SPECS 1. Strategic Range: 120km km Duration: 24hrs 2. Operational Range: 20km - 120km Duration: 20hrs 3. Tactical Range: 0km - 20km Duration: 16hrs 1. Analysis 1. Targeting Accuracy: 10m 2. Fusion 2. Plan Engagement 3. Quality 3. Conduct Assurance Engagement 4. Dissemination 4. Battle Damage Assessment Tactical LOOKER Information Management Analysis NEMESIS NEMESIS Fusion NEMESIS NEMESIS Quality Assurance NEMESIS NEMESIS Dissemination BOWMAN, SAT BOWMAN, SAT Effects Targeting LOOKER, SPECS Plan BISA BISA Engagement Conduct CR2, MILAN, CR2, FGA CR2, FGA Engagement FGA BDA FGA, SAT FGA, SAT FGA, SAT Figure 4-7: Creating & analysing ISTAR StV-3 Capability Phasing 153. The StV-3 View shows that there will be gaps in Capability in the Operational and Tactical Information Acquisition areas (ISTAR) from Epoch 2 onwards. In addition, the Analysis, Fusion and Quality Assurance functions are only being provided by NEMESIS. Although there is no specific gap, this solution does not satisfy the objectives set out in the StV-1 Capability Vision for real-time data fusion The combined use of the StV-1, 2, and 3 Views has identified a Capability shortfall, namely the timely fusion and dissemination of ISTAR information, and a Capability gap, in the lack of Operational and Tactical ISTAR assets from Epoch 2 onwards. Further analysis can now be carried out to confirm the findings, and understand the nature of the capability issue. StV-4 Capability Clusters and StV-5 Capability to Systems Deployment Mapping are used to achieve this Figure 4-8 shows the StV-4. It highlights 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. MODAF-M Version

47 Analysis Quality Assurance Targeting Battle Damage Assessment Information Management Effects Fusion Dissemination Plan Engagement Conduct Engagement Strategic Operational Information Acquisition Tactical Figure 4-8: StV-4 identifying capability dependencies 156. Figure 4-9 shows the StV-5, depicting system deployment across organisations over the three epochs being considered. It shows SPECS and LOOKER going outof-service, leaving Capability gaps in Information Acquisition in Epoch 2. But more specifically, that the decommissioning of SPECS results in a capability gap for organisations PJHQ and JFQ, and that the decommissioning of LOOKER results in a capability gap for organisations Tactical Brigade and Tactical - Special Forces. Figure 4-9: ISTAR StV-5 Capability to Systems Deployment Mapping 4.4 Develop Options 157. Now that the Capability gaps and shortfalls have been confirmed, potential options are analysed to inform the Equipment Programme (EP). Two Capability Options are identified to overcome the capability shortfall that results from the disposal of both SPECS and LOOKER at end of Epoch 1. Option 1 is defined in OV- 1a and OV-1b, as shown in Figure 4-10 and Figure (Note: the articulation of an option using an OV-1 is a recommended way of articulating a capability option post EP-baseline, rather than at this point in the process (refer to section 3.6.5, with MODAF-M Version

48 linkage to section 3.5.2). For the purposes of understanding the worked example however, the OV-1 is incorporated here.) Figure 4-10: ISTAR OV-1a Capability Option 1 SPECS 2 Option 1: the LOOKER system has been replaced with KESTREL, a smaller system that would plan to deploy at least three UAV's for every one LOOKER system. SPECS has been upgraded to SPECS 2, and a Common ISTAR Base Station has been brought into service to enable data fusion between all ISTAR assets. Figure 4-11: ISTAR OV-1b Capability Option 1 SPECS Figure 4-12 shows an updated fully compliant StV-3 for Option 1 (Highly Desirable) and Figure 4-13 the compliant AcV-2 (Essential). MODAF-M Version

49 Capability Functions Epoch 1 Epoch 2 Epoch 3 Information Acquisition Strategic ISTAR NEMESIS NEMESIS Operational ISTAR SPECS SPECS 2 SPECS 2 Tactical ISTAR LOOKER KESTREL KESTREL Information Management Analysis NEMESIS NEMESIS ISTAR BASE STATION ISTAR BASE STATION Fusion NEMESIS NEMESIS ISTAR BASE STATION ISTAR BASE STATION Quality Assurance NEMESIS NEMESIS ISTAR BASE STATION ISTAR BASE STATIN Dissemination BOWMAN, SAT BOWMAN, SAT Effects Targeting LOOKER, SPECS KESTREL, SPECS 2 Plan Engagement BISA BISA KESTREL, SPECS 2 Conduct Engagement CR2, MILAN, FGA CR2, FGA CR2, FGA BDA FGA, SAT FGA, SAT FGA, SAT Figure 4-12: ISTAR StV-3 Capability Option 1 SPECS 2 ISTAR SYSTEMS KESTREL DISP START DISP FIN SPECS DISP START NEMESIS DISP START DISP FIN LOOKER HASS LoD 'Segment' Project Phase Tr aini ng Equipment No outstanding issues Pre-IG Key to View Pe rso nnel Logistics Manageable issues IG to MG MG to IOC Inf ormation Infrastructure Critical issues IOC to FOC D octrine/ C oncepts Organisation DLOD Absent DLOD Not Applicable In Service Disposal Figure 4-13: ISTAR AcV-2 Capability Option 1 SPECS 2 MODAF-M Version

50 159. Secondly, Option 2 is defined, as shown by OV-1a and b, in Figure 4-14 and Figure 4-18 respectively. Figure 4-14: ISTAR OV-1a Capability Option 2 HASS Option 2: KESTREL has again replaced the LOOKER system. This time however, SPECS has been replaced by the High Altitude Surveillance System (HASS), and the Common ISTAR Base Station has been brought into service to enable Data fusion between all ISTAR assets. Figure 4-15: ISTAR OV-1b Capability Option 2 HASS 160. Figure 4-16 shows an updated fully compliant StV-3 for Option 2 and Figure 4-17 shows the compliant AcV-2. MODAF-M Version

51 Capability Functions Epoch 1 Epoch 2 Epoch 3 Information Acquisition Strategic ISTAR NEMESIS NEMESIS Operational ISTAR SPECS HASS HASS Tactical ISTAR LOOKER KESTREL KESTREL Information Management Analysis NEMESIS NEMESIS ISTAR BASE STATION Fusion NEMESIS NEMESIS ISTAR BASE STATION Quality Assurance NEMESIS NEMESIS ISTAR BASE STATION ISTAR BASE STATION ISTAR BASE STATION ISTAR BASE STATION Dissemination BOWMAN, SAT BOWMAN, SAT Effects Targeting LOOKER, SPECS KESTREL KESTREL Plan Engagement BISA BISA Conduct Engagement CR2, MILAN, FGA CR2, FGA CR2, FGA BDA FGA, SAT FGA, SAT FGA, SAT Figure 4-16: ISTAR StV-3 Capability Option 2 HASS ISTAR SYSTEMS KESTREL DISP START DISP FIN SPECS DISP START NEMESIS DISP START DISP FIN LOOKER HASS LoD 'Segment' Project Phase Tr aining Equipment No outstanding issues Pre-IG Key to View Pe rso nnel Logistics Manageable issues IG to MG MG to IOC Inf ormation Infrastructure Critical issues IOC to FOC D octrine/ C oncepts Organisation DLOD Absent DLOD Not Applicable In Service Disposal Figure 4-17: ISTAR AcV-2 Capability Option 2 HASS MODAF-M Version

52 4.5 Establish Equipment Programme 161. During comparison of the two options, the JCB identify that: a. Option 1 (SPECS 2 & KESTREL) offers a lower level of Capability, however the delivery of capability is constant b. Option 2 (HASS & KESTREL) provides a better level of Capability, however there is a shortfall before HASS can be delivered To avoid the shortfall, the JCB select Option 1, and this is then integrated in the baseline Equipment Plan (EP). 4.6 Requirements Development 163. The finalised EP is used as a basis for the selection and grouping of acquisition programmes. In this example, a User Requirements Document (URD) is developed to specify the user requirements for SPECS 2. The specification and development of KESTREL will be the responsibility of a separate IPT and URD The development of the SPECS 2 URD starts with the identification of the scenarios to be considered. For this example, a single scenario limited warfighting engagement is considered The scenario is articulated in an StV-6, as shown in Figure For clarity of the scenario components and composition, refer to Figure 4-21 for a graphical representation StV-6 identifies that the limited warfighting scenario makes use of Information Acquisition, Information Management and Effects capabilities. It also identifies that the scenario involves a set of operational activities, from Recce through to Recuperate. Information Acquisition Information Management Effects Recce X Collate Intelligence X Conduct Estimate X Coordinate Plan X X X Attack X X X Recuperate X Figure 4-18: SPECS 2 StV-6 URD scenario 167. Having defined the scenario, a set of vignettes are identified to articulate the full range of activities and capabilities expected of SPECS 2. Two vignettes have been selected and defined as in this worked example. The first vignette is associated with the identification of a target armoured enemy vehicle. The second vignette is associated with information exchange and fusion with US JSTAR. The StV-6 representations of these vignettes are shown in Figure 4-19 and Figure 4-20 MODAF-M Version

53 respectively. Figure 4-25 and Figure 4-28 provide a graphical representation of these vignettes. Information Acquisition Information Management Effects Recce X Collate Intelligence X Conduct Estimate X Coordinate Plan X X X Attack X X X Recuperate X Figure 4-19: StV-6 articulating vignette 1 identify target Information Acquisition Information Management Effects Recce X Collate Intelligence X Conduct Estimate X Coordinate Plan X X X Attack X X X Recuperate X Figure 4-20: StV-6 articulating vignette 2 - interoperability 168. With an StV-6 View created to represent the scenario and vignettes, a set of MODAF Operational Views are produced in line with the URD development sequence to articulate the SPECS 2 operational requirements. For Initial Gate, this comprises OV-1 and OV Firstly we address the overall scenario. OV-1a is created as a graphical representation of SPECS 2 in its operational context, and with its interconnectivity to ISTAR base station. This is supported by OV-1b, its description, and an OV-1c, the performance metrics for the scenario. MODAF-M Version

54 CARRIER NEMESIS SPECS 2 PJHQ FIGHTING PATROL ENEMY ISTAR BASE STATION KESTREL BDE HQ MAIN OPERATING BASE Figure 4-21: OV-1a articulating warfighting scenario.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 4-22: Extract from the OV-1b describing warfighting scenario MODAF-M Version

55 Attribute Measure Target SPECS 2 Flight Time Maximum number of hours for a single flight SPECS 2 Range Maximum number of km from ISTAR base station SPECS 2 Downtime Number of days required for maintenance SPECS 2 Video Support Number of individual video channels provided SPECS 2 Video Delay Maximum time delay (seconds) viewing tasked location Figure 4-23: OV-1c articulating warfighting scenario performance metrics 170. OV-2 is created to show SPECS 2 and its need line information flows to the other operational nodes in the scenario. The numbering of information flows in the OV-2 represents the sequence of information flow. ISTAR INFORMATION 17 ISTAR INFORMATION 10 PJHQ AIRCRAFT CARRIER NEMESIS 8 TASKING ORDER 9 TASKING ORDER PATROL REPORT 1 TASKING ORDER ISTAR INFORMATION ISTAR INFORMATION 16 ISTAR INFORMATION 12 BRIGADE HQ ISTAR BASE STATION SPECS 2 6 TASKING ORDER 7 ISTAR TASK ORDER 2 PATROL REPORT 14 TASKING ORDER PATROL REPORT 15 ISTAR INFORMATION 5 MAIN OPERATING BASE FIGHTING PATROL KESTREL 3 TASKING ORDER 4 ISTAR TASK ORDER Figure 4-24: OV-2 articulating warfighting scenario 171. With the overall scenario now articulated as an OV-1 and OV-2, each vignette is addressed. Figure 4-25, Figure 4-26 and Figure 4-27 address Vignette 1 - identification of the target. MODAF-M Version

56 Figure 4-25: OV-1a articulating vignette 1 identify target.to identify the target, PJHQ directly task SPECS 2 to identify the target. SPEC 2, having then identified the target returns the identification data to both PJHQ and the common base station.. Figure 4-26: OV-1b describing vignette 1 identify target ISTAR BASE STATION 1 ISTAR TASK ORDER ISTAR INFORMATION 3 2 PJHQ SPECS 2 ISTAR INFORMATION ISTAR INFORMATION 4 ENEMY Figure 4-27: OV-2 articulating vignette 1 identify target MODAF-M Version

57 172. The second vignette 2 addresses interoperability with US JSTAR to obtain and fuse information (Figure 4-28, Figure 4-29 and Figure 4-30). Figure 4-28: OV-1a articulating vignette 2 interoperability..pjhq directly tasks SPECS 2 to fuse information with US JSTAR. SPEC 2 sends its information to USJSTAR, and requests that from US JSTAR in return. It fuses the returning information with that of its own and returns the combined information to PJHQ to complete the order Figure 4-29: OV-1b describing vignette 2 interoperability US JSTAR AIRCRAFT ISTAR INFORMATION 3 ISTAR INFORMATION 4 ISTAR TASK ORDER PJHQ 1 SPECS 2 ISTAR INFORMATION 2 Figure 4-30: OV-2 articulating vignette 2 - interoperability MODAF-M Version

58 173. This completes the View set that supports the URD textual requirements at the Initial Gate. For the Main Gate, OV-3 and OV-5 are constructed (or updated if created for Initial Gate) As before, we firstly address the overall scenario. OV-3 is created to show the information exchanges between the nodes on the OV-2, this includes the direct exchanges to SPECS 2. OV-5 is created to articulate the scenario as a set of operational activities. Needline ID Fr o m To Content Medium 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 ISTAR BASE STATION OPERATIONAL ISTAR TASK ORDER BOWMAN 7 ISTAR BASE 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 NEMESIS AIRCRAFT CARRIER STRATEGIC ISTAR INFO LINK NEMESIS ISTAR BASE STATION STRATEGIC ISTAR INFO LINK SPECS 2 ISTAR BASE 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 ISTAR BASE STATION BDE HQ OPERATIONAL ISTAR INFO BOWMAN 17 AIRCRAFT CARRIER PJHQ STRATEGIC ISTAR INFO SAT COMM Figure 4-31: OV-3 articulating warfighting scenario PJHQ BDE HQ ISTAR BASE STATION SPECS 2 Request SPECS 2 be prepared for Recce of target area Request launch of SPECS 2 Execute SPECS 2 launch procedure Take off Provide suspected target location Provide SPECS 2 search area coordinates Enter SPECS 2 search area flight profile Moves to search area flight profile Provide preferred target information requirements Request SPECS 2 provide live video footage/ data reports Configure SPECS 2 to provide video footage/ data reports Captures/ fuses live video footage/ data reports Decide whether to take action Provide target status Relay video footage/ data reports Figure 4-32: OV-5 articulating warfighting scenario MODAF-M Version

59 175. Then OV-3 and OV-5 are created for each vignette. Firstly vignette 1 - SPECS 2 identification of the target. Needline Number From To Nature Content Means 1 PJHQ SPECS 2 MESSAGE TASK ORDER UHF 2 SPECS 2 PJHQ ISTAR DATA DATA ON ENEMY LINK 16 3 SPECS 2 ISTAR BSE STATION ISTAR DATA DATA ON ENEMY LINK 16 4 ENEMY SPECS 2 ISTAR DATA DATA ON ENEMY LINK 16 Figure 4-33: OV-3 articulating vignette 1 identify target PJHQ ISTAR BASE STATION SPECS 2 Request SPECS 2 be prepared for Recce of target area Execute SPECS 2 launch procedure Take off Provide SPECS 2 search area coordinates Enter SPECS 2 search area flight profile Moves to search area flight profile Request SPECS 2 identify tagret Configure SPECS 2 to identify target Captures target video and data Analyse video and data Relay video footage/ data reports Decide whether to take action Store video and data Figure 4-34: OV-5 articulating vignette 1 identify target 176. Secondly, OV-3 and OV-5 are created for vignette 2 - SPECS 2 interoperability with US JSTAR to obtain and fuse information. MODAF-M Version

60 Needline Number From To Nature Content Means 1 PJHQ SPECS 2 MESSAGE TASK ORDER UHF 2 SPECS 2 PJHQ ISTAR DATA DATA ON ENEMY LINK 16 3 SPECS 2 US JSTAR ISTAR DATA DATA ON ENEMY LINK 16 4 US ENEMY JSTAR SPECS 2 ISTAR DATA DATA ON ENEMY LINK 16 Figure 4-35: OV-3 articulating vignette 2 interoperability PJHQ SPECS 2 US JSTAR Request SPECS 2 manuovre insight of of US JSTAR Enter SPECS 2 flight profile Moves to flight profile Request SPECS 2 fuse data with US JSTAR Authorise SPECS 2 to exchange data Sends data to US JSTAR Sends data to SPECS 2 Fuses US JSTAR & SPECS 2 data Analyse data Relay fused data Decide whether to take action Figure 4-36: OV-5 articulating vignette 2 interoperability 177. The OV-3 tables can contain a number of columns beyond that shown; the detail of these are contained in the Technical Handbook 19. This completes the MODAF Operational View suite required to support the textual requirements at the Main Gate In additional to the Operational View Suite, the Main Gate requires TV-1, to specify the policies and standards that SPECS 2 must satisfy. The TV-1 for SPECS 2 is shown in Figure MODAF Technical Handbook. Reference: MODAF-M MODAF-M Version

61 Service Area Service Applicable Elements Standard/ Policy ISTAR Governance Operations Fielded capability SOPs Acceptance Fielded capability ISTAR Acceptance Procedure MOD Strategy Systems Engineering SPECS 2 & interfaces MOD Systems Engineering Management Plan (SEMP) MODAF CESG Information Security Standards Infosec Vol 1,2,3 MOD Interoperability Communications/ Networking SPECS 2 external UK communication network interfaces OGD Networking & Communications Policy US Interoperability Communications/ Networking SPECS 2 external US communication network interfaces Satcom: See US guidance notes WAN Protocol: SDH, PDH LAN Protocol: TCP/IP, Ethernet, CAT 5 Sustainment & Logistics Ability to sustain capability SPECS 2 and DLoD support MOD Sustainment & Logistics guidelines Figure 4-37: TV-1 specifying SPECS 2 standards and policies 4.7 Summary 179. This example provides a simplified explanation of how MODAF can be applied within the Customer 1 COI. Notice how common data elements across MODAF views bear the same name and relationships in each view. This is what distinguishes MODAF from the generation of custom views. The consistency of the data elements and relationships provided by the meta-model ensures the architecture is integral, and delivers the benefits resulting from a commonality of language in the architectural framework In a real example the number of Systems involved, the variety and depth of the Capability Taxonomy, and the number and complexity of interdependency will be greatly increased. As MODAF View development is an iterative process for each View, it is certain that there will be several versions to allow comparison and evaluation. MODAF-M Version

62 5. Document Maintenance 181. It is intended that the MODAF product suite will evolve through time in order to reflect learning from experience, changes to the MOD s processes and the evolution of architectural best practice. A change control process will be established for all MODAF products and suggestions upon the refinement / improvement of this and related products are welcome. The formal MODAF change control process will be published in due course (see In the interim, suggestions should be forwarded to the MODAF team through: /ProgrammesProjectsAndWorkingGroups/MinistryOfDefenceArchitectureFramework modaf.htm Acknowledgements This document has been developed by MODAF partners as part of the MODAF 1.0 Baseline that is being prepared by DEC CCII supported by the IA. Other MOD organisations that have contributed to the content and / or review of this document are: ECC CSD Apps DEC UWE DLO DG Info (incl. CBM J6) DCSA DPA DEC CCII Capability Strategy D Def Acq The MODAF development team also wish to acknowledge the support that these organisations offered to the Project Board, User Group and Technical Working Group. The role of Industry is also acknowledged in providing support to the MODAF development and in reviewing the MODAF products prior to its release. MODAF partners The MODAF 1.0 Baseline has been developed for the MOD by MODAF partners. The MODAF partners team leaders for this work have been: Fariba Hozhabrafkan Cornwell Management Consultants Home Barn Court The Street Effingham Surrey KT24 5LG Tel: Dave Mawby PA Consulting Group 123 Buckingham Palace Road London SW1W 9SR Tel: MODAF-M Version

63 6. Bibliography The following were used to provide background context for the development of this Deskbook: Architectural Frameworks: IEEE Std , Architectural Descriptions of Software Intensive Systems, September DOD Architectural Framework, Version 1.0, February Federal Enterprise Architecture Framework, Version 1.1, September TOGAF 8, The Open Group Architectural Framework, December Zachman Framework for Enterprise Architecture, see Network Enabled Capability (NEC) and Network Centric Warfare (NCW): Network Enabled Capability, JSP 777, Edn 1, January NEC: Next Steps Progress and Review, D/CMIS/2/1, April NEC Outline Concept, Dstl/IMD/SOS/500/2, Issue 2, May Network Centric Warfare, Alberts D, Garstka J, Stein F, CCRP, August DoD Joint Technical Architecture, Version 6.0, October MOD Processes and Standards: Smart Acquisition Handbook, Edition 5, January Acquisition Management System, ECC Handbook, Issue 3, December Joint Second Customer Handbook, Draft Edition 1, July MODAF-M Version

64 APPENDIX 1: MODAF View Mapping To Customer 1 Process MODAF-M Version