TOGAF TO MODAF MAPPING

Transcription

1 A part of BMT in Defence TOGAF TO MODAF MAPPING Reference: C370-EP-01 Date: 9th December 2010

2 We help deliver complex programmes through the integration of programme management and systems engineering. This means that you maintain a clear picture of your goals and how they are being realised, which builds the coherence you need to make informed decisions. E: info@hiqsigma.com W: Basingstoke Taylormade Court Jays Close, Viables Business Park Basingstoke Hants RG22 4BS T: +44 (0) F: +44 (0) Bath office: 5 Riverside Court Lower Bristol Road Bath BA2 3DZ T: +44 (0) F: +44 (0) Company registered in England, number Registered Office: Goodrich House, 1 Waldegrave Road, Teddington, TW11 8LZ.

3 DOCUMENT AUTHORISATION Author(s): (this issue) First Name Surname R Forder & M Duffy.. (Written or Electronic Signature) (Date) First Name Surname.. (Written or Electronic Signature) (Date) First Name Surname.. (Written or Electronic Signature) (Date) Reviewer(s): First Name Surname.. (Written or Electronic Signature) (Date) COPYRIGHT STATEMENT The copyright in this document is vested in the Crown and the document is the property of the Crown. This document is released in confidence, to the recipient nominated by the Crown and is for use only for the purposes of the Crown pursuant to the Contract. This Document shall not be copied or further disclosed except as authorised by the Crown. Any further disclosure shall be under the terms of this legend, and any copies shall be the property of the Crown. On Completion of the task in connection with which this Document is released, the recipient shall return the Document (and any correspondence) to the issuing Authority. CROWN COPYRIGHT 2009 Reference: C370-EP-01 Page i of viii

4 CHANGE RECORD Version Date Description of Change /12/2010 Updated to reflect BMT Branding DISTRIBUTION LIST Name Copy Number Reference: C370-EP-01 Page ii of viii

5 Intentionally Blank Reference: C370-EP-01 Page iii of viii

6 CONTENTS 1 introduction The approach Background Enterprise and Frameworks Enterprise Benefits Ministry of Defence Framework (MODAF) Open Group Framework (TOGAF) Purpose The Evolutionary Context Overview Of Mapping Analysis Results TOGAF ADM to MODAF mapping concept of analysis The Enterprise Reference Model MODAF Summary Of Views Relationships between MODAF views Overview Of Development Methods Background Rationale for the development guidance provided MODAF Development Process DODAF Development Process Introduction Summary of DODAF Development Stages Sequence of DODAF View Development TOGAF ARCHITECTURE development method (adm) Mapping DODAF Development Procces To togaf adm Phases MODAF s Iterative Approach to development The Implications For Mapping Iteritive Product Development Development Method (ADM) With MODAF Artefacts Introduction ADM architecture requirements management Objective Approach MODAF Models Building Block Specification Process in the ADM Levels of Modelling Mapping the Modelling Levels to the ADM workflow modelling conventions USED IN THIS DOCUMENT Reference: C370-EP-01 Page iv of viii

7 8.4 Preliminary Phase: Framework And Principles Objective Approach Framework Inputs Steps Tailored Steps with MODAF Outputs phase a: vision Objective Inputs Steps Business Scenarios Tailored Steps with MODAF Outputs Phase B: Business architecture Objective Inputs Tailored Steps with MODAF Outputs Phase c: information systems architecture Objective Approach Inputs Steps Tailored Steps with MODAF Outputs phase d: technology architecture Objective Approach Inputs Steps Tailored Steps with MODAF Outputs phase e: opportunities and solutions Objective Approach Reference: C370-EP-01 Page v of viii

8 8.9.3 Inputs Steps Tailored Steps with MODAF Outputs phase f: migration planning Objective Approach Inputs Steps Tailored Steps with MODAF Outputs phase g: implementation governance Objective Approach Inputs Steps Tailored Steps with MODAF Outputs phase h: architecture change management Objective Approach Inputs Steps Tailored Steps with MODAF Outputs MODAF Product development Within The Context Of the TOGAF ADM phases All View Products Overview and Summary Information (AV-1) Integrated Dictionary (AV-2) Capability View Products Enterprise Vision (StV-1) Capability Taxonomy (StV-2) Capability Phasing (StV-3) Capability Dependencies (StV-4) Capability to Organisation Deployment Mapping (StV-5) Operational Activity to Capability Mapping (StV-6) Operational View Products Reference: C370-EP-01 Page vi of viii

9 9.3.1 High Level Operational Concept (OV-1) Operational Node Relationship Description (OV-2) Operational Information Exchange Matrix (OV-3) Organisational Relationships Chart (OV-4) Operational Activity Model (OV-5) Operational Activity Sequence & Timing Description (OV-6a, 6b & 6c) Information Model (OV-7) Service Oriented View Products Service Taxonomy Description (SOAV-1) Services Specification Description (SOAV-2) Service Composition Description (SOAV-3) Service Orchestration Description (SOAV-4) Service Behaviour Description (SOAV-5) Service Provision Description (SV-13) System View Products Resource Interaction Specification (SV-1) Systems Communications Description (SV-2a, 2b, 2c) System Port Specification (SV-2a) Resource Interaction Matrix (SV-3) Functionality Description (SV-4) Function to Operational Activity Traceability Matrix (SV-5) Systems Data Exchange Matrix (SV-6) Resource Performance Parameters Matrix (SV-7) Capability Configuration Management (SV-8) Technology and Skills Forecast (SV-9) Resource Sequence & Timing Description (SV-10a, 10b, & 10c) Physical Schema (SV-1 1) Technical View Products Technical Standards Profile (TV-1) Technical Standards Forecast (TV-2) Acquisition View Products Acquisition Clusters (AcV-1) Programme Timelines (AcV-2) Reference: C370-EP-01 Page vii of viii

10 Intentionally Blank Reference: C370-EP-01 Page viii of viii

11 G. Implementation Governance H. Change Management F. Migration Planning Prelim: Framework & Principles A. Vision Requirements E. Opportunities & Solutions B. Business D. Technology C. Information Systems Requirements Drive Supports Governs Maps to Depends on Produces/ consumes Governs Conducts To use Deployed on Decomposes Has Governs Governs Deployed at Deliver Projects Articulates the capability picture to support capability management and equipment planning Articulates the type and level of services required, how they are assembled and interact, and what interfaces are required Articulates acquisition programme construct, milestones, dependencies and LoDs status Provides summary information that specifies the architecture product,pertinent to the entire architecture Articulates operational picture to support operational analysis, requirements definition, and solution acceptance Articulates system composition and interconnectivity to support systems analysis and through life management Articulates policy, standards, guidance and constraints to specify and assure quality expectations TOGAF TO MODAF MAPPING 1 INTRODUCTION Enterprise (EA) is the outcome of applying a development process known as an Design Methodology (ADM) to a set of rules defined in an Enterprise Framework (EAF). EA = (ADM) + (EAF) In the context of this document, these components are: Enterprise = Stakeholder defined views of Defence Logistics: THE WHAT Design Methodology = TOGAF ADM (v8.1.1): THE HOW Enterprise Framework = MODAF (v1.1): THE RULES 1.1 THE APPROACH Figure 1 shows the approach adopted in producing this TOGAF to MODAF Mapping Report. In essence the approach used a generic Enterprise Reference Model as a frame of reference for relating the nine processes that comprise the TOGAF Development Method (ADM) to the creation of Views as defined by the MOD Framework. The Enterprise Reference Model is simply a logical presentation of the key elements that make up an enterprise (and their fundamental relationships). The TOGAF ADM has been used as it is an off-the-shelf methodology that is fast becoming the de facto industry standard for developing architecture products. Furthermore, it is well documented and supported through The Open Group and is probably the most complete, consistent and coherent architecture development method in existence. Development Methodology (TOGAF v8.1.1) (9 stage process) Unifying Enterprise Reference Model (Elements important to the enterprise) Strategy, Policy & Objectives Activity Information Data Produces/ consumes Systems Capability Organisational Unit Trained competence Infrastructure Technical Standards Enterprise Framework (MODAF v1.0) (Defines 7 Viewpoints & 44 Views) Services Viewpoint Acquisition Viewpoint Strategic Viewpoint MODAF Operational Viewpoint Systems Viewpoint Technical Viewpoint All Viewpoint & TOGAF to MODAF Mapping Report THIS DOCUMENT Figure 1: Approach to mapping TOGAF and MODAF 1.2 BACKGROUND The Defence end-to-end Logistics community is currently served by a large complex IT infrastructure that has developed over the years, mainly to meet single service needs. It consists of a multitude of Reference: C370-EP-01 Page 9 of 84

12 systems, applications, networks and databases of various sizes and types most of which are not interconnected and suffer from duplicate functionality. It is the desire of the logistics community to rationalise these systems and, wherever possible, to have a joint approach to managing and supporting the logistics chain from Factory to Foxhole. Enterprise is seen as being key to understanding the complexity of the existing systems then specifying the future systems by reusing or extending existing functionality to meet the future business or operational needs Enterprise and Frameworks Enterprise is a representation of any collection of collaborative organisations and suborganisations, such as government agencies, private companies or divisions/departments of a larger organisation that need to interact at all levels to achieve common set of goals. Because of the inherent complex nature of an enterprise the representations need to take range of different perspectives at different levels of abstraction to be able to properly understand and describe the enterprise in terms of its architecture. The guidelines and rules to define describe and develop an architecture, which can be the current or future architecture, are defined by an Framework. The framework provides a set of standard building blocks that help ensure consistency both within a single architecture or across several architectures. An Framework suitable for describing an Enterprise needs to be able to describe an enterprise in terms of a number of viewpoints, typically: Strategic vision; Business processes, information needs and constraints; The underlying technology and its constraints to support the business needs. Each of the viewpoints also need to be described in terms of views that show behaviour and structure at varying levels of abstraction. The complexity of the enterprise is captured not just by capturing the entities and concepts within the viewpoints and underlying views but also by describing the complex dependencies that exist between them. There are several architecture frameworks in existence, often built to meet a slightly different requirement, and are not necessarily in competition with each other; in fact, they are often complementary as will be shown in this report Enterprise Benefits An Enterprise can present a clear vision of an enterprise in all of its dimensions and complexity both in terms of its existing state and its desired or future state. When the architecture is implemented by a competent and empowered team under adequate governance, the result can support all aspects of the enterprise including: Business planning at all levels - vision, goals, governance and strategy Operations (both supporting and frontline) organisational structures, business processes, information need Automation applications and databases Technical Infrastructure computers, networks and operating systems Because of the breadth and depth of a coherent architecture, it will provide significant support to realising the following benefits: Business Benefits The alignment of business and IT in a sustainable and efficient way Facilitation of change in a controlled manner with minimal adverse impact Reference: C370-EP-01 Page 10 of 84

13 Operational and business agility through common understanding of situational awareness and information exploitation A fully integrated and efficient support chain from factory to foxhole Improved and consistent information exchange Risk reduction Financial Benefits Alignment of the IT business case to strategic initiatives Reuse of functionality leading to lower support and acquisition costs Time savings Technical adaptability Human Resource Benefits Increased manpower flexibility Adequately trained personnel The architecture will proved direct support to stakeholders involved in the following tasks: Project management and decision making Requirements specification and management Identification and definition of services Solution development and delivery Testing and integration Through life management Ministry of Defence Framework (MODAF) MODAF s main requirement is as an enabler to MOD s Network Enabled Capability (NEC). It defines a set of key business and technical information for describing an enterprise architecture. This architectural framework defines the following viewpoints: Strategic context (capability, enterprise vision, capability configuration and enterprise goals); Operational context (organizations, locations, processes, information exchanges, etc.); Service context (this is currently work in progress within the MODAF Project); System architecture (systems, functions, interfaces, data specifications, protocols, etc.); Supporting standards; Acquisition context (projects and project milestones). The following diagram illustrates the relationship of MODAF Viewpoints. Reference: C370-EP-01 Page 11 of 84

14 Strategic Viewpoint Articulates the capability picture to support capability management and equipment planning Operational Viewpoint Articulates operational picture to support operational analysis, requirement definition and solution acceptance The What Services Viewpoint Articulates the type and level of services required, how they are assembled and interact MODAF Systems Viewpoint Articulates system composition and interconnectivity to support systems analysis and through life management The How Acquisition Viewpoint Articulates programme construct, milestones, dependencies and LoD status All Viewpoint Provides summary information that specifies the architecture product pertinent to the entire architecture Technical Viewpoint Articulates policy, standards, guidance and constraints to specify and assure quality expectations Figure 2: MODAF Viewpoints Open Group Framework (TOGAF) The Open Group Framework (TOGAF) is a framework for Enterprise which provides a comprehensive approach to the design, planning, implementation, and governance of an enterprise information architecture. As indicated in Figure 3 the architecture is typically focused at four levels or domains: Business; Application; Data; Technology. The 4 domains are modelled by following a methodology comprising 9 discrete but iterative phases: Reference: C370-EP-01 Page 12 of 84

15 Development Method (ADM) Prelim: Framework & Principles H. Change Management A. Vision B. Business Framework Business G. Implementation Governance Requirements C. Information Systems Information & Data System & Application Technology F. Migration Planning D. Technology TOGAF E. Opportunities & Solutions Figure 3: TOGAF Development Method (ADM) TOGAF is published by the Open Group and consists of three main parts: The TOGAF Development Method (ADM), as shown in Figure 3, which describes how to develop an Enterprise by breaking the process down into a nine distinct phases. Each phase is documented with a description and a number of process steps including the inputs and outputs. The mappings described in this document are between the Phases within the ADM and the MODAF views. The Enterprise Continuum which is a virtual repository of Assets, such as models, patterns, architecture descriptions and standards that provide the building blocks for an. The Enterprise Continuum can exist both within the enterprise or within the domain of interest at large. The TOGAF Resource Base, which is a set of resources consisting of guidelines, templates, examples and other background information that help an architect to use the ADM and Enterprise Continuum. This document can be considered to form part of the TOGAF Resource Base. 1.3 PURPOSE This document will be useful to any person, primarily from the Defence End to End Logistics Community, who has to undertake or manage an architecting task. Together with the MODAF handbooks and the TOGAF Manual, it provides guidance for creating and maintaining architectures in terms of what to do and how to present it. The intention is to establish a set of mappings between the ADM phases and the MODAF views that are considered suitable for supporting analysis and documenting each ADM phase. In support of the mappings the document also provides an overview of both MODAF and TOGAF. The open Group has recently published a mapping between DODAF and TOGAF. This piece of work expands upon the DODAF TOGAF work and is, intentionally, very similar in style and content. Reference: C370-EP-01 Page 13 of 84

16 1.4 ARCHITECTURE THE EVOLUTIONARY CONTEXT Both TOGAF and MODAF can be traced back to the Technical Architectural Framework for Information Management (TAFIM) reference model which was developed by the Defence Information Systems Agency (DISA) to guide the evolution of Department of Defence (DOD) systems, including sustaining base, strategic, and tactical systems, as well as interfaces to weapon systems. TAIFM was influenced by ISO/IEC which was used to describe the Portable Operating System Interface (POSIX). TOGAF version 1 is a direct descendent of TAFIM and was created as an industry response to the DOD s architectural framework. Since its inception, TOGAF has been through a number of iterations and is currently at version 8.1 with the next version due in late 2007 or early The C4ISR Framework was created as a successor to TAFIM which was withdrawn in The US DOD Architectural Framework (DODAF) was mainly a rename of the C4ISR Framework with the intention of broadening its context. The DODAF currently remains at version 1. DODAF is the most mature and widely adopted architectural framework in the defence industry today and is seen as a fundamental part of the DOD s drive towards Network Centric Warfare. MODAF is based on the DODAF specification, and uses many aspects of DODAF without alteration; this is to provide interoperability between the two frameworks. MODAF also adds a number of new views needed to support MOD-specific processes and structures. The MODAF is currently at version 1.1. The revised version 1.1 seeks to better integrate the concepts from the Strategic and Acquisition views with the core views inherited from DODAF (OV, SV, TV, AV). The NATO Framework (NAF), which is still in development, is also based upon DODAF and informed by the additional MODAF views. NAF also introduces a number of new Service Views to support Service Orientated. It is likely that MODAF and NAF may converge into a single or very closely related architecture sometime in the near future. Figure 4 shows the evolutionary context for both TOGAF and MODAF and highlights the parallel development of TOGAF and DODAF from which, in turn, MODAF has been developed. JTA References DoDAF 2004 Influencing ISO/IEC Zachman 1987 Influenced TAFIM Influenced Influenced Supported by EAP 1992 Adopted by DoD TRM References Influenced Influenced TOGAF 1995 (US Industry response to DOD EA initiative) References FEAF 1999 References Influenced Influenced Influenced C4ISR 1999 Influenced Influenced Supported by TOGAF 2003 (v8.1) TEAF 2000 (US Treasury) Influenced Influenced Influenced MODAF 2005 TOGAF 2006 (v8.1.1) Zachman 2005 FEAF 2005 Influencing Influencing NAF (NATO) TOGAF 2007/8 (v9) E2AF Figure 4: Evolutionary context for development of architecture frameworks Reference: C370-EP-01 Page 14 of 84

17 2 OVERVIEW OF MAPPING ANALYSIS RESULTS Table 1 and Figure 5 provide a summary of the results of a comparative analysis between MODAF and TOGAF. The primary tools used in this comparative analysis were: The detailed Product Descriptions for each MODAF View which were extracted from MODAF (version 1.1); The TOGAF Development Method as defined by the detailed instructions for each of the nine ADM Phases (TOGAF 8.1). The analysis used as its starting point the work reported in the The Open Group White Paper that examined the mapping between the US DODAF and TOGAF 1. This document was provided as a source reference to the study team that produced this document by D Log Info (AD ). A major part of the content of this reference document consists of material extracted directly from TOGAF Note: 1. TOGAF version is actually the latest issue of TOGAF. However, it is only available in hard copy (349 pages) which did not lend itself to the working practices of the authors. However, there is no substantive difference between TOGAF 8.1 and TOGAF The differences 3 are all accounted for by updates to version references throughout the TOGAF document. 2. MODAF version 1.1 is the most recent issue of MODAF (Apr 07). The new version of MODAF is an evolution of v1.0, and seeks to better integrate the concepts from the Strategic and Acquisition views with the core views inherited from DODAF (OV,SV,TV,AV). In addition, the following improvements have been made: Clearer emphasis in the documentation of the logical nature of the Operational Views (esp. OV-2 & 5). Clearer distinction between OV & SV, with OV being seen as the what and the SV the how i.e. logical architecture independent of implementation in the OV being released as a solution specification architecture in the SVs Addition of Problem Domain concept in OV-2 to clarify the trade-space for to-be architectures. Addition of human factors in the SVs organisations, posts and roles can now be explicitly shown in SV-1, and functions in SV-4 can be conducted by roles (human), systems (machines) or Capability Configurations (combinations of humans, systems, platforms, etc.). StV-6 purpose and use clarified now acts as repository for Standard Operational Activities which can then be re-used in multiple OV-2s. It is likely that these will be JETLs or similar. StV-5 shows organisational deployment of capability configurations. The detailed Product Descriptions for each MODAF View and the associated analysis of how the development of each MODAF View relates to the TOGAF ADM are provided in the section of this document entitled: MODAF product development within the context of the TOGAF ADM Phases Table 1 provides an overview of the relationship between these frameworks from a TOGAF-to- MODAF perspective. 1 The Open Group Framework and the US DoDDOD Framework: A White Paper by Dr Dandashi (MITRE Corporation, R. Siegers (Raytheon), J. Jones (Architecting the Enterprise), T. Blevins (MITRE Corporation). Nov TOGAF (The Open Group Framework) Version 8.1 Enterprise Edition. 3 TOGAF Corrigendum UO65 ( I95/GO51) details specific changes to TOGAF v8.1 that result in TOGAF v Reference: C370-EP-01 Page 15 of 84

18 TOGAF Phase Focus Applicable MODAF Models Preliminary Framework & Principles StV-1, StV-2, AV-1, OV-1 A Vision StV-1, StV-2, AV-1, OV-1 B Business Stv-1, StV-5, StV-2, StV-6, AV-2, OV1. OV-2, OV-3, 0V-4, OV-5, OV-6, SOAV-1, SOAV-2, SOAV-4, SOAV-5, SV13 C InformationSystems : Data StV-5, OV-7, SOAV-1, SOAV-2, SOAV-4, SOAV-5, SV13, SV-4, SV-5, SV-6, SV-10, SV-11, D Technology StV-3, StV-4, StV-5, SOAV-2, SV-13, SV-1, SV-2, SV-5, SV-7, SV-10, TV-1 E Opportunities & Solutions StV-3, StV-4, SOAV-3, SV-8, SV-9, TV-2, AcV-1, AcV-2 F Migration Planning StV-5, SOAV-3, SOAV-4, SV-8, AcV-1, AcV-2 G Implementation Governance StV-1, StV-2,StV-3, StV-4, AV-1, OV-1, SOAV-2, SOAV-3, SOAV-4, AcV-1, AcV-2 H Change Management StV-1, SV-9, TV-2 Table 1: Summary relating TOGAF ADM Phases to MODAF Models Figure 5: Summary of TOGAF ADM with MODAF Views as the Description is a visualization of the relationship between these frameworks from a TOGAF-to-MODAF perspective using the TOGAF circles diagram. Reference: C370-EP-01 Page 16 of 84

19 Prelim: Framework & Principles StV-1, StV-2, AV-1, OV-1 StV-1, StV-2, AV-1, OV-1 StV-1, SV-9, TV-2 H. Change Management A. Vision B. Business Stv-1,StV-2, StV-5, StV-6, AV-2, OV1. OV-2, OV-3, 0V-4, OV-5, OV-6, SOAV-1, SOAV-2, SOAV-4, SOAV-5, SV13 StV-1, StV-2,StV-3, StV-4, AV-1, OV-1, SOAV-2, SOAV-3, SOAV-4, AcV-1, AcV-2 G. Implementation Governance StV-5, SOAV-3, SOAV-4, SV-8, AcV-1, AcV-2 F. Migration Planning Requirements N/A E. Opportunities & Solutions StV-3, StV-4, SOAV-3, SV-8, SV-9, TV-2, AcV-1, AcV-2 C. Information Systems StV-5, OV-7, SOAV-1, SOAV-2, SOAV-4, SOAV-5, SV13, SV-4, SV-5, SV-6, SV-10, SV-11, D. Technology StV-3, StV-4, StV-5, SOAV-2, SV-13, SV-1, SV-2, SV-5, SV-3, SV-4, SV-7, SV-10, TV-1 Figure 5: Summary of TOGAF ADM with MODAF Views as the Description It is worth noting that Not Applicable appears against the Requirements element of the TOGAF ADM. This might, at first sight, seem surprising given that the MODAF project has developed a Customer 2 Deskbook that provides guidance to the Capability Management function on how to use MODAF to capture and manage requirements in the form of MODAF products. The reason for the N/A annotation shown in the above Figure is that in the TOGAF ADM, the Requirements circle denotes not a static set of requirements, but rather a continuous and dynamic process whereby requirements for enterprise architecture - and subsequent changes to those requirements - are identified, stored and fed into and out of the relevant ADM phases. The TOGAF Requirements Management process itself does not dispose of, address or prioritise any requirements; this is done within the relevant phase of the ADM. To emphasise the point, it is merely the process for managing requirements throughout the overall ADM. Reference: C370-EP-01 Page 17 of 84

20 3 TOGAF ADM TO MODAF MAPPING CONCEPT OF ANALYSIS The model shown in Figure 6: Concept of Analysis for mapping TOGAF to MODAF captures the approach that has been adopted in developing this paper. It shows how the development methodology (The HOW ) that is TOGAF relates the architecture outputs (the WHAT ) that are created by following the MODAF design criteria. This should not be confused with MODAF version 1.1 where the Operational Viewpoints (OVs) are now described as the WHAT and the System Viewpoints as the HOW, where the former is describing the process of architecting and the latter is describing the architecture. Each element of the model is briefly discussed to show its relevance to the subsequent analysis and discussion contained in this paper. Figure 6: Concept of Analysis for mapping TOGAF to MODAF 3.1 THE ENTERPRISE REFERENCE MODEL An Enterprise Reference Model is a conceptual specification of the types of elements that are important to the enterprise namely: activities, organisations, people, services, information, systems and supporting infrastructure, and to a first-order level of detail just how these types of elements are classified and related to deliver the desired outcome. In the case of MOD the desired outcome of assembling these enterprise components in response to strategy, policy doctrine and specific scenarios is the provision of a defined level of Capability. It can be seen that there is a broad relationship between the components that make up the Enterprise Reference Model as shown and the generally accepted Defence Lines of Development (i.e. training, Reference: C370-EP-01 Page 18 of 84

21 equipment, personnel, information, concepts & doctrine, organisation, logistics and infrastructure) all set in the overarching theme of interoperability. A conceptual view of an enterprise, such as the Enterprise Reference Model, is particularly useful when attempting to align or map process (such as TOGAF ADM) and output (such as MODAF Views). It provides a solution-neutral tool for achieving understanding and consensus. The same Enterprise Reference Model also offers a potential starting point for developing a taxonomy/ontology for classifying and cataloguing the enterprise as a foundation for robust enterprise architecture. The same reference model is also useful in that it shows conceptually how requirements and project management/delivery relate to architecture. Such a reference model is shown in Figure 7. A very similar version of this Enterprise Reference Model has been used in the past by members of the MODAF Project and while it has achieved broad acceptance it has no formal endorsement. For the purpose of the task in hand a new element has been added by the authors of this document to support analysis. Namely, the element called Services has been inserted between the elements of Activity and Information in attempt to provide a context for the evolving SOA Views that are being developed by MOD and NATO. This is based on the authors assumption that the principle service of interest to the MODAF community is an Information Service. However, an examination of the SOA View Profiles suggests that their utility is wider than just information services. This issue of scope of service is outside the terms of reference of this assignment. Strategy, Policy & Objectives Governs Depends on Capability Decomposes Governs Requirements Drive Supports Activity Uses Creates Services Produces consumes Information Maps to Data Produces/ consumes Systems Conducts To use Deployed on Organisational Unit Has Trained competence Infrastructure Deployed at Deliver Projects Governs Governs Technical Standards Figure 7: Enterprise Reference Model Reference: C370-EP-01 Page 19 of 84

22 4 MODAF SUMMARY OF VIEWS Table 2 presents a summary of all of the currently defined and approved MODAF Viewpoints and their constituent Views. For completeness the table also contains summaries of the Service Oriented (SOA) Views that are emerging from joint MOD/NATO working. These are still in the early stages of development and have yet to be exposed to review amongst the many Communities of Interest. They are therefore likely to undergo changes as part of this review process. Reference: C370-EP-01 Page 20 of 84

23 Ref MODAF Viewpoint View View Name View Description 1 All Views AV-1 Overview and Summary Information Provides executive-level summary information in a consistent form that allows quick reference and comparison between architectural descriptions. 2 All Views AV-2 Integrated Dictionary Presents all the Elements as a specialisation hierarchy, along with a text definition and a reference the source of the element. 3 Strategic StV-1 Enterprise Vision Defines the strategic context for a group of Enterprise capabilities by documenting the strategic vision often for transformational endeavours. 4 Strategic StV-2 Capability Taxonomy Show the required capabilities for one or more enterprises, in the form of a hierarchy, for current and future points in time. 5 Strategic StV-3 Capability Phasing Addresses the planned achievement of capability at different points in time or during specific periods of time. 6 Strategic StV-4 Capability Dependencies Describes the dependencies between planned capabilities. It also defines logical groupings of capabilities (capability clusters). 7 Strategic StV-5 Capability to Organisation Deployment Mapping 8 Strategic StV-6 Operational Activity to Capability Mapping 9 Operational OV-1a High Level Operational Concept Graphic 10 Operational OV-1b Operational Concept Description Addresses the fulfilment of capability requirements, in particular by network enabled capabilities. Describes the mapping between the capabilities required by an Enterprise and the operational activities that those capabilities support. High-level graphical description of business concept showing the main Operational Nodes and interesting or unique aspects of the architecture domain. Provides a supplementary textural description that explains and details the scenario contained within the associated OV- 1a. 11 Operational OV-1c Operational Performance Attributes Provides detail of the operational performance attributes associated with the scenario / use case represented in the High Level Operating Concept Graphic (OV-1) and how these might evolve over time. 12 Operational OV-2 Operational Node Relationships Description Primarily addresses localisation of operational capability and may also be used to express the capability boundary. A secondary purpose is to define a logical network of information flows. Reference: C370-EP-01 Page 21 of 84

24 Ref MODAF Viewpoint View View Name View Description 13 Operational OV-3 Operational Information Exchange Matrix 14 Operational OV-4 Organisational Relationships Chart Describes, in detail, information exchanged between nodes and the relevant attributes of that exchange. Shows typical or actual organisational structures and collaborative interactions. 15 Operational OV-5 Operational Activity Model Describes the activities, or tasks, that are normally conducted in the course of achieving a mission or a business goal along with information flow. 16 Operational OV-6a Operational Rules Model Specifies operational or business rules that are constraints on the way that business is done in the enterprise. 17 Operational OV-6b Operational State Transition Description 18 Operational OV-6c Operational Event Trace Description Describes how an operational node or activity responds to various events by changing its state. Provides a time-ordered examination of the information exchanges between participating operational nodes as a result of a particular scenario. 19 Operational OV-7 Information Model Describes the information that is associated with the information exchanges of the architecture. Included are information items, their attributes and their inter-relationships. 20 Service SOAV-1 Service Taxonomy Documents the hierarchy of services, their attributes and associated policies (constraints) 21 Service SOAV-2 Services Specification Defines interfaces, operations, messages and parameters 22 Service SOAV-3 Service Composition Defines services composed of other services. This view is under review and may be subsumed into other views and removed. 23 Service SOAV-4 Service Orchestration Specifies how services support operational activities 24 Service SOAV-5 Service Behaviour Documents functions (activity models), state machines and interactions 25 Service SV13 Service Provision Defines which combinations of systems and people (capability configurations) are required to provide services 26 System SV-1 Resource Interaction Specification Links together the operational and systems architecture views by depicting how resources are structured and interact in order to realise the logical architecture specified in an OV-2. Reference: C370-EP-01 Page 22 of 84

25 Ref MODAF Viewpoint View View Name View Description 27 System SV-2a System Port Specification Specifies the ports on a system, and the protocols used by those ports when communicating with other systems. 28 System SV-2b System To System Port Connectivity 29 System SV-2c System Connectivity Clusters 30 System SV-3 Resource Interaction Matrix specifies the communications links between systems and may also list the protocol stacks used in connections. Defines how individual connections between systems are grouped into logical connections between parent resources. Allows a quick overview of all the resource interactions specified in one or more SV-1 diagrams. 31 System SV-4 Functionality Description Address human and system functionality. The SV-4 is the systems view counterpart to the Activity Model (OV-5) of the operational view. 32 System SV-5 Function to Operational Activity Traceability Matrix 33 System SV-6 Systems Data Exchange Matrix 34 System SV-7 Systems Performance Parameters Matrix 35 System SV-8 Capability Configuration Management 36 System SV-9 Technology and Skills Forecast 37 System SV-1 0a Resource Constraints Specification 38 System SV-1 0b Resource State Transition Description 39 System SV-1 0c Resource Event-Trace Description Addresses the linkage between functions described in SV-4 and Operational Activities specified in OV-5. Specifies the characteristics of the system data exchanged between systems. The focus is often on data crossing the system boundary. Depicts the performance characteristics of a Functional Resource (system, role or capability configuration) Presents a whole lifecycle view of a resource, describing how its configuration changes over time. Defines the underlying current and expected supporting technologies and skills. Only those skills and technologies that can be reasonably forecast given expected improvements / trends. Specifies functional and non-functional constraints on the implementation aspects of the architecture (i.e. the structural and behavioural elements of the SV viewpoint). Graphical method of describing a resource (or function) response to various events by changing its state. Provides a time-ordered examination of the interactions between functional resources. Reference: C370-EP-01 Page 23 of 84

26 Ref MODAF Viewpoint View View Name View Description 40 System SV-1 1 Physical Schema Defines the structure of the various kinds of system data that are utilised by the systems in the. 41 Technical TV-1 Standards Profile Technical and non-technical standards, guidance and policy applicable to the architecture. 42 Technical TV-2 Standards Forecast Expected changes in technology-related standards and conventions, which are documented in the TV-1 Product. 43 Acquisition AcV-1 Acquisition Clusters Enables the user to model the organisational structures needed to manage a portfolio of projects. 44 Acquisition AcV-2 Programme Timelines Captures the dependencies between projects and the integration of all the DLODs to achieve a successfully integrated military capability. Table 2: Summary of MODAF Views With the exception of the SOA Views, detailed profiles for all of the above MODAF Views are contained in the MODAF documentation available on Reference: C370-EP-01 Page 24 of 84

27 5 RELATIONSHIPS BETWEEN MODAF VIEWS The model in Figure 8 shows the key relationships between MODAF View relationships. Originally produced by one of the authors of this paper, it is taken from Appendix C to the MODAF Overview (version 1.0) document. This model is included here for general reference and guidance to the architects responsible for developing MODAF Views. The model shows the complexity of the many-to-many View relationships that can exist across a MODAF compliant architecture. It also illustrates how TOGAF driven development methods, which are themselves iterative and not view constrained, can result in a ripple change effect throughout the architecture. OV-4 OV-7 SV-11 SV-4 SV-10 System Event StV-1 SV-9 StV-3 StV-5 Organization Datamodel Entity Relationship Attribute System State System Constraint Function Function Flow Capability Vision SV-7 SV-1 SV-3 SV-2 SV-8 AcV-1 AcV-2 System StV-4 SV-6 System Connection SV-2d System Port Port Connection Project Milestone SV-5 Capability Cluster Capability StV-2 StV-6 OV-2 Node OV-5 OV-6 Operational Event Capability Dependenc y Operational Activity Activity Flow OV-3 Needline (Information) Operational State Operational Constraint SV-6 Information Element Link covered by MODAF view (labelled on line) Information Exchange Figure 8: Relationships between MODAF Views Reference: C370-EP-01 Page 25 of 84

28 6 OVERVIEW OF ARCHITECTURE DEVELOPMENT METHODS 6.1 BACKGROUND Both DODAF and MODAF offer the architect some non-prescriptive guidance on the build process and sequence for creating Views. However none of the suggested processes are sufficiently complete, consistent and coherent as to be able to call themselves a methodology. This was recognised by the US IT industry and, in the 1990s, the major suppliers of IT to the US Military undertook to produce just such a methodology to support what was then the DOD s C4ISR Framework that has now evolved to become DODAF. This was the start of TOGAF that is currently at Version This is still undergoing evolutionary development with a stronger enterprise level Version 9.0 expected later this year. At the heart of TOGAF is the TOGAF Development Method (ADM) that has all the attributes of a development methodology. This means there is a strong and direct linkage in the evolution of, and relationship between, DODAF and TOGAF. In developing the MODAF documentation, the development team originally decided not to include any guidance on a process for developing MODAF Views. However, towards the end of the MODAF development activity it was decided to produce an Overview document with some development process guidance. While the MODAF development team used the DODAF advisory guidance as its baseline which means there is no fundamental difference in the advice given - it decided to adopt a slightly different presentation style that has had the unintended effects of masking the DODAF genealogy of MODAF guidance and obscuring the strong relationship to the TOGAF ADM. The recent version 1.1 of MODAF seeks to better integrate the concepts from the Strategic and Acquisition views within the core views inherited from DODAF. 6.2 RATIONALE FOR THE DEVELOPMENT GUIDANCE PROVIDED This section will briefly review both the MODAF and DODAF development guidance available to architects and then briefly review TOGAF Development Method (ADM) as defined in TOGAF 8.1. (Note there is no substantive difference between TOGAF Version 8.1 and Version The only difference is that Version has updated and tidied up some of the Version referencing). The logical sequence for presenting the information contained in this Section might appear to be timeline driven, i.e.: DODAF, TOGAF and then MODAF. However, given the stronger evolutionary ties between DODAF and TOGAF it has been requested by D Log Info staff that these be kept together and be dealt with in sequence. Furthermore, in order to emphasise the greater experience behind DODAF development guidance over that supporting MODAF guidance, MODAF guidance will be presented first in this Section of the document. 6.3 MODAF DEVELOPMENT PROCESS While the MODAF documentation set was derived from the US DODAF and included a number of additional Viewpoints and Views, the MODAF development team decided - like DODAF - not to endorse a prescriptive development process. Indeed, the MODAF documentation does not ever go as far as DODAF in offering detailed development advice to the architect. Like DODAF, the MODAF Overview document suggests a six-stage, iterative development process that is captured in Figure 9. This diagram also indicates four potential iteration loops in the process: 1. Having generated the architecture there are periodic analysis/update cycles without any major refresh of the architecture itself. 2. Another type of iteration would be where the architecture is refreshed with more up to date data before analysis is repeated. 3. In some cases it may be appropriate to periodically return right back to the start of the architecture process to review the purpose, scope and data sources. Reference: C370-EP-01 Page 26 of 84

29 4. Sometimes, as the data is being gathered and entered into the architecture it may become apparent that it is not going to be possible to achieve the desired results using the elements being considered. In this case it may be necessary to re-visit the architecture scope and/or data gathering plan in order to develop an architecture that will satisfy the original objectives Establish Intended Use 2. Define Scope 3. Develop Data Requirements 4. Capture 5. Conduct Analysis 6. Document Results Figure 9: Suggested iterative development cycle for MODAF Although not included in any of the MODAF documentation, the resulting notional build sequence for MODAF products (including Strategic and Acquisition Views, but excluding the still embryonic SOA Views) would be as shown in Figure 10. AcV-1 AcV-2 StV-1 StV-2 StV-4 StV-5 OV-2 OV-4 OV-3 StV-3 SV-9 TV-1 TV-2 SV-8 AV-1 AV-2 OV-1 StV-6 OV-5 OV-7 OV-6a OV-6b OV-6c SV-4 As-Is To-Be SV-5 SV-1Oa SV-10b SV-10c SV-6 SV-11 SV-1 SV-3 SV-2 SV-7 Figure 10: Notional Build Sequence for MODAF Views This still shows the importance of starting with the Operational Views within the context of the All Views but now with the additional context provided by some of the Strategic Views. 6.4 DODAF DEVELOPMENT PROCESS Reference: C370-EP-01 Page 27 of 84

30 6.4.1 Introduction DODAF did not develop a DOD community-wide endorsed process or methodology for developing DODAF products. It still does not support or endorse any specific process for developing architecture descriptions. However, to assist the architect the DODAF Deskbook does provide some practical guidance based on experience gained in certain segments of the DOD community. The DODAF Desk book provides a detailed description of a six stage process that ensures consistency between products and ensures that all essential entity relationships are captured to support analysis. This method focuses on data and data relationships rather than products and moves the construction of the final product to the end of the process. Figure 11 captures this six-stage Development Process Determine the intended use of the architecture Purpose Critical issues Target objectives Key tradeoffs Probable analysis methods 2 2. Determine scope of architecture 3 3. Determine data required to support architecture development 4 4. Collect, organise, correlate & store architecture data 5 5. Conduct analyses in support of architecture objectives 6 6. Document results iaw Framework Geographical, functional & operational bounds Technological bounds Time frames Architectural resource & schedule constraints Required Architectural characterisics: entities Levels of detail Units of measure Automated repositories Activity models Data models Dynamic models Organisational models Shortfall analyses Capacity analyses Interoperability assessments Investment trade-offs Business process analyses products & views (Operational, systems, technical) Reusable architecture data Analysis reports Figure 11: DODAF Six-stage Development Process Summary of DODAF Development Stages For the convenience of the reader this section provides extracts from DODAF Deskbook that summarise the suggested development stages. Step 1 Determine the intended use of the. The intended use explains why the architecture is being developed. For example, it may be developed for business process reengineering (BPR) purposes (i.e., identifying nonmaterial solutions, such as improved procedures, realigning organizations, better training, or modifying functions), to establish and quantify acquisition requirements (e.g., systems, personnel, or facilities), or to assess the feasibility of attaining a particular vision under a specific set of circumstances. The purpose also explains what the architecture will accomplish and how it may affect organizations or system development. The importance of unambiguously stating the purpose is that it establishes clear and concise exit criteria to measure the architecture s satisfaction of the customer s overall requirement. Step 2 Determine architecture scope. The scope defines the boundaries that establish the depth and breadth of the architecture. The scope bounds the architecture s problem set and helps define its context. Other elements of the context that bound the architecture are the environment and the organization s mission and vision. This step involves describing geographic, operational, functional, and technological limits of the architecture; determining applicable time frame(s); and recognizing available architecture development resources and schedule constraints. The architecture s scope includes: Reference: C370-EP-01 Page 28 of 84