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: [email protected] 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

31 Subject Area - describes the applicable capability, organizational area, or domain to which the architecture applies Timeframe - describes the point in time to which the architecture is applicable (Examples of words used to express time frame are current [As-Is or baseline], programmed [budgeted or planned], and objective [To-Be or future].) Intended Users and Uses - identifies the audience the architecture is intended to serve and how it is expected to use the architecture Dimensionality - helps identify the boundaries of the breadth and level of detail at which the architecture is to be developed; directly related to the purpose and perspective of the architecture. Step 3 Determine data required to support architecture development. During this step, the data entities and attributes (such as activities, organizations, information elements, and other architecture components) are selected. Also selected is the level of detail to which these entities and attributes need to be identified to meet the objectives of the architecture. This step determines the type of data that needs to be collected in Step 4. Recognized data types for consideration include: Rules that govern how activities should perform Guidance for mapping activities to organizational elements and nodes Information needed to accomplish activities Command relationships, task lists, required information about organizational elements and nodes Standard data dictionaries Rules on geo-distribution and environment Guidance for developing linkages among activities Results from specific activities Known likely external interfaces with other organizations (joint or coalition) Linkages to higher-level activities such as Universal Joint Task List (UJTL) tasks Step 4 Collect, organise, correlate and store architecture data. Following data collection, cataloguing, organizing, and entering the data into automated repositories permit subsequent analysis and reuse. As data is captured and stored, it should be defined and tagged with source information. Included in this step is the correlation of data in terms of activity, data, organizational, and dynamic models. For reuse purposes, architecture data should be entered into a database. The contents of the database should be stored in terms of models. The database will include the scope, operational concept model, information process model, node connectivity model, behavioural model, and nodalrelated data for the architecture. Information collected will be in sufficient detail to lead subject matter experts through the development of the activity model and related business rules Step 5 Conduct analyses to support architecture objectives. The types of analyses that are typically performed are: Determination of shortfalls between requirements and capabilities Assessments of processing and communications capacities Assessments of interoperability Analysis of alternatives to determine investment tradeoffs Analyses of business processes to determine possible non-materiel solutions Reference: C370-EP-01 Page 29 of 84

32 The analytical process provides insights into issues and concerns that were not readily apparent at the outset, and, as a result, Step 5 includes the identification of additional data collection requirements. During analysis, the architect selects, compares, assesses, and transforms contextual and architectural inputs based upon the operational concept. The environment is then assessed and defined in terms of a set of assumptions and constraints (as specified in the operational concept) regarding operational, cultural, political, economic, and technological factors. These are examined against current and emerging doctrine, various threat conditions, and perceived needs. Typically, one or more scenarios are used to confirm expectations, discover shortfalls, or identify new opportunities. Operational impacts related to functions and capabilities enabled by leap-ahead technology are also considered. Step 6 Document results iaw the Framework. The final step in the process involves building architecture products in accordance with templates established in the DODAF. developers will build only those products necessary to meet the intended use of the architecture (as defined in Step 1). products will be captured in reusable and shareable form. A number of architecture tools are available to support this step. The tool should be selected based on the intended use of the architecture (Step 1) Sequence of DODAF View Development Based on the use of six-staged DODAF Development Process, and in particular Stage 5, the DODAF Deskbook suggests a general order of precedence in the sequence in which Views are developed in order to maintain data integrity. While it recommends that the All View products are developed first at the start of an architecture project, this is only to provide a frame of reference for the development work. The main recommendation is that the operational views, and in particular OV-5, is seen to be the foundation for development work. The Desk book goes on to recommend the data-centric notional build sequence shown in Figure 12. This is not intended to be prescriptive. Rather it is intended to be iterative, with some Views being developed in parallel. 3 OV-2 OV OV-3 10 SV-9 TV-1 TV-2 SV AV-1 OV-1 OV-5 AV-2 3 OV-7 3 OV-6a OV-6b OV-6c SV To-Be As-Is 6 SV SV-1Oa SV-10b SV-10c 8 SV-1 SV-6 8 SV-11 7 SV-3 SV-7 9 SV-2 9 Figure 12: Notional Build Sequence for DODAF Views Reference: C370-EP-01 Page 30 of 84

33 6.5 TOGAF ARCHITECTURE DEVELOPMENT METHOD (ADM) The US Department of Defense developed a series of architecture guidance documents in the early 1990s known as the Technical Framework for Information Management (TAFIM). The purpose of these eight volumes was to provide:...the services, standards, design concepts, components, and configurations that can be used to guide the development of technical architectures that meet specific mission requirements to evolve the US Department of Defence technical infrastructure. [TAFIM-1996]. The TAFIM was matured to Version 3.0 and then provided to The Open Group for its ongoing maturation and promulgation across government and industry. TAFIM was the baseline for the development of The Open Group Framework (TOGAF) in 1995 and was subsequently retired. The US Defense Information Systems Agency (DISA) contributed heavily to the development of TOGAF 1.0, which primarily leveraged TAFIM Volume 2: Technical Reference Model for TOGAF s Technical Reference Model and TAFIM Volume 3: Concepts and Design Guidance for TOGAF s Development Method (ADM). The TOGAF ADM is a prescriptive, step-by-step instruction guide for how to architect. It is presented in a series of phases that guide the architect or architecture team through the architecting lifecycle of system development. (Note that although the TOGAF phases have alphabetic identifiers, there is an understanding that enterprise specific iterations within and between phases is required.) TOGAF is comprised of four parts: Part I: Introduction; Part II: Development Method (ADM); Part III: Enterprise Continuum; Part IV: Resources. The first seven releases of TOGAF ADM ( ) were focused on providing technical architecture guidance. The 2002 release of TOGAF 8.0 extended this earlier technical focus with elements of business, data, and applications architectures. Once populated with relevant architecture artefacts, this layered collection of architecture viewpoints is commonly known as the enterprise architecture. TOGAF Versions 8.0 (and beyond) are referred to as the enterprise edition, a superset of the pre-8.0 technical edition releases but with increasing emphasis on the enterprise continuum. Figure 13 presents a model of the TOGAF Development Method (ADM), commonly referred to as crop circles, along with the conventional pyramid model of the TOGAF Framework. Phase B, C and D of the crop circle presentation of TOGAF and the four layer pyramid presentation are similarly colour coded to relate development phases to the resulting architecture views. It can be seen that Phase C generates two layers of the pyramid, namely the Information & Data and the System & Application. Reference: C370-EP-01 Page 31 of 84

34 Prelim: Framework & Principles H. Change Management A. Vision B. Business Business G. Implementation Governance Requirements C. Information Systems Information & Data System & Application Technology F. Migration Planning D. Technology TOGAF E. Opportunities & Solutions Figure 13: TOGAF Table 3 provides an overview of each of the nine phases that guide the architect through the TOGAF ADM. Reference: C370-EP-01 Page 32 of 84

35 Phase Name Description Preliminary A B C D E Framework & Principles Vision Business Information Systems Technology Opportunities and Solutions Identify additional framework(s) to use; define architecture principles to guide the architecture work Define scope; create vision; identify relevant stakeholders; define business/mission requirements and constraints; obtain approvals Develop Baseline and Target Business s, describing product and/or service strategy and organizational, functional, process, information, and geographic aspects of the business/mission environment, based on business/mission principles, business/mission goals, and strategic drivers Develop target architecture(s) covering either the Data or Application Systems domains (perhaps both depending on project scope) Develop Technology to form the basis of the following implementation work Evaluate and select among the implementation options identified in candidate target architectures; identify strategic parameters for change and top-level work packages or projects required to move from current state to target state F Migration Planning Asses dependencies, costs, and benefits of the various migration projects; prioritize list of projects to form basis of detailed Implementation and Migration Plan G H Implementation Governance Change Management Make recommendations for each implementation project; construct architecture contract to govern overall implementation and deployment process; perform governance functions while system is implemented and deployed; ensure conformance with defined architecture Provide for the continual monitoring of new developments in technology and changes in the business environment, and for determining whether to formally initiate a new architecture evolution cycle Table 3: TOGAF Development Method (ADM) - Phase Descriptions The TOGAF ADM prescribes no architectural models. This aspect of the architecting process is outside of the defined scope of this architecture framework. The architect must identify which architecture models are required for the specific development activity, along with which elements of the defined models are most appropriate for the receiving stakeholders: The TOGAF Development Method therefore does not prescribe any specific set of enterprise architecture deliverables although it does describe a set, by way of example. Rather, TOGAF is designed to be used with whatever set of deliverables the TOGAF user feels is most appropriate. [TOGAF-2003]. DODAF and MODAF both prescribe a set of architectural models that together comprise one integrated super-model for describing the architecture of concern. Such a visual architecture model facilitates architectural decisions made following the TOGAF architecture methodology. 6.6 MAPPING DODAF DEVELOPMENT PROCCES TO TOGAF ADM PHASES Reference: C370-EP-01 Page 33 of 84

36 The 6-stage DODAF Development Process (Figure 11) can be mapped to the TOGAF ADM ninephase methodology (Figure 13) as shown in Figure 14. This mapping shows that DODAF development guidance concentrates on creating and using the architecture for its intended purpose but with little regard for architecture governance processes. (Note: a similar mapping exercise would show the same for MODAF). DODAF Step 1 Determine the intended use of the architecture H. Change Management Prelim: Framework & Principles A. Vision DODAF Step 2 Determine scope of architecture B. Business DODAF Step 3 Determine data required to support architecture development DODAF Step 4 Collect, organise, correlate & store architecture data G. Implementatio n Governance Requirements C. Information Systems DODAF Step 6 Document results iaw Framework F. Migration Planning E. Opportunities & Solutions D. Technology DODAF Step 5 Conduct analyses in support of architecture objectives Figure 14: Mapping of DODAF Development Process to the TOGAF ADM Reference: C370-EP-01 Page 34 of 84

37 7 MODAF S ITERATIVE APPROACH TO DEVELOPMENT THE IMPLICATIONS FOR MAPPING 7.1 ITERITIVE PRODUCT DEVELOPMENT The following text has been abstracted from the MODAF Technical Handbook (Version 1.0) as it has implications for any attempt to directly map MODAF products to specific stages of any development methodology and particularly one such as TOGAF s Development Methodology (ADM) which is itself iterative. MODAF Architectural Products may be described at varying levels of detail for example, an architect may wish to produce a high-level, summary OV-2 which hides some detail, and a set of detailed OV- 2s. This approach allows MODAF to be used in iterative design processes, where the Views are progressively filled in with more detail as the emerges from the design and development process. MODAF Views have dependencies between them, and the frequent changes (which are an aspect of an iterative development process) can ripple across many Views for example, changes in an OV can drive changes in the SV and TV Views. During this iterative development process, different models are developed at varying levels of abstraction with Products that trace from one model to another. At the highest level of abstraction a minimal set of Products may be developed to produce a single model of the (denoted Model A). This initial model may comprise only highly abstract/generic sets of Operational Nodes, operational activities, and so forth. Later, when new details are added and the is expanded to show more design detail, plus additional Products as necessary, a new model is developed. (Model B, consisting of modified Model A Views plus additional Views as necessary). The new Products that then make up Model B include and trace back to the original group of Products (which make up Model A of the ). The Operational Node of Model A's OV-2 Product (as part of Model A) may have been used to represent an aggregated organisation or command (one that may consist of multiple subordinate Operational Nodes) but it is deemed unnecessary to show those subordinate Nodes at the Model A level. In Model B, the Operational Node of Model A s View may be expanded to show the subordinate Nodes. No new root level Framework Operational Nodes are introduced at this level that do not trace back to the previous model. For example, if (in the process of model refinement) it is determined that an Operational Node is part of the, and that this Node is not yet a part of any of the aggregated Operational Nodes of OV-2 included in Model A, then Model A s OV-2 is revised to include the newly identified node. Model B s OV-2 may then include that subordinate Node - which will be a decomposition of the Model A node, and will trace back to that node. Consequently, while this paper will attempt to provide mappings between the TOGAF ADM Phases and Stages to the creation of specific MODAF Views it is not possible to guarantee a one to one mapping. Not only are TOGAF ADM and MODAF Views fundamentally different things but enterprise architecting is as much an art as it is a science which is often why one architecture team and their outputs are so much more effective than another. Reference: C370-EP-01 Page 35 of 84

38 8 ARCHITECTURE DEVELOPMENT METHOD (ADM) WITH MODAF ARTEFACTS 8.1 INTRODUCTION This section of the document consists of excerpts from the TOGAF ADM specification each of which has been extended to include a workflow interpretation of each Phase of the ADM and specific tailored steps where appropriate to show how the MODAF products/views are created. Each of the nine discrete Phases (Preliminary Phase and Phases A to H) will be described using a similar format consisting of the following headings: Objectives of the Phase; Approach to be adopted; Inputs to the Phase; Steps of the Phase; Tailored steps with MODAF (this will only be a very high level summary; the reader will need to refer to the MODAF documentation for more detailed guidance). Furthermore, the steps will need to be further tailored to meet the specific architecture vision and objectives of each organisation. Workflow model of the Phase; Outputs from the Phase. As already discussed, the TOGAF Requirements Management process itself does not dispose of, address, or prioritise any requirements because these activities are done within the relevant phase of the ADM. It is merely the process for managing requirements throughout the overall ADM. Therefore describing the Requirements Management Phase does not lend itself to the above format. Consequently it will be dealt with first in this section of the document. 8.2 ADM ARCHITECTURE REQUIREMENTS MANAGEMENT Objective The objectives of this phase are to define a process whereby requirements for enterprise architecture are identified, stored, and fed into and out of the relevant ADM phases Approach As indicated by the Requirements Management circle at the centre of the ADM graphic, the ADM is continuously driven by the Requirements Management process. It is important to note that the Requirements Management circle denotes, not a static set of requirements, but a 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 MODAF Models There are no constructs in MODAF v1.1 that specifically support the modelling of requirements. However, there are current activities that are looking into augmenting MODAF with the ability to capture systems requirements, and allocating requirements to the architecture elements that satisfy them. One such activity is an Object Management Group (OMG) effort to define a Unified Modelling Language Profile for DODAF and MODAF (UPDM) [OMG-2006] Building Block Specification Process in the ADM The process of building block definition takes place gradually as the ADM is followed, mainly in Phases A, B, C, and D. It is an iterative process because as definition proceeds, detailed information about the functionality required, the constraints imposed on the architecture, and the availability of Reference: C370-EP-01 Page 36 of 84

39 products may affect the choice and the content of building blocks. The key parts of the ADM at which building blocks are designed and specified are summarized below. The major work in these steps consists of identifying the Building Blocks (ABBs) required to meet the business goals and objectives. The selected set of Building Blocks is then refined in an iterative process to arrive at a set of Solutions Building Blocks (SBBs) which can either be bought off-the-shelf or custom developed. The specification of building blocks using the ADM is an evolutionary and iterative process. The key Phases and Steps within each Phase of the ADM at which building blocks are evolved and specified are summarized below, and illustrated in Figure 15. Those Steps that do not result in any building blocks are not produced are included for completeness but have been ghosted in the following Figure. When examining Figure 15 the reader is reminded that the TOGAF Enterprise Continuum comprises two components: the Continuum made up of Building Blocks (ABBs); and the Solutions Continuum made up of Solution Building Blocks (SBBs). A. Vision - High-level model of candidate building blocks Implementati on Governance Change Management Migration Planning Vision Requirements Opportunitie s & Solutions Business Technology Information Systems E. Opportunities and Solutions - Building block architectures, in both ABB and SBB forms B. Business C. Data D. Application Step 1: Baseline Description - Identify relevant Building Blocks (ABBs), drawing on the Continuum. Step 2: Reference Models, Viewpoints & Tools - Select resources from Continuum - Select viewpoints to address stakeholder concerns - Identify appropriate tools to develop/manage products Step 3: Target Model - High level description and broad model in ABB terms Step 4: Select ABBs - Identify required ABBs; check against existing library of ABBs, re-using as appropriate. - Where necessary, define new ABBs. Step 5: Checkpoint Review - Formal checkpoint review of architecture model and building blocks with stakeholders. Step 6: Review non-functional criteria - Review cost/progress of developments against mandate Step 7: Complete Target - Select standards for each ABB, reusing as much as possible from reference models selected from the Continuum - Fully document each ABB - Document final mapping of the ABBs within the Continuum - From selected ABBs identify those that might be re-used, and publish via architecture repository - Document rationale for building block decisions in architecture document Step 8: Gap Analysis - Identify building blocks to be carried over - Identify eliminated building blocks - Identify new building blocks - Identify gaps: classify as to be developed or procured Figure 15: Key Phases/Steps of ADM at which Building Blocks are evolved or specified In Phase A, the earliest building block definitions start as relatively abstract entities within the Vision. In Phases B, C, and D, building blocks within the Business, Data, Applications, and Technology s are evolved to a common pattern of steps: Step 1 - Baseline Description produces: A list of candidate building blocks, from the analysis of the baseline. Step 3 - Target Model takes the list of candidate building blocks and high-level model as inputs, and evolves them iteratively into a definition of the target architecture, specified in terms of Building Blocks Specifically, Step 3 produces: A high-level description and broad model of the target system in terms of Building Blocks; Reference: C370-EP-01 Page 37 of 84

40 A rationale for each building block decision. Step 4 - MODAF models are mainly developed during this step. By following MODAF to create the architecture models throughout the ADM, the architect is aided with MODAF s set of visual models in making architectural decisions and in generating reports to be used in the remaining steps. For each Building Block, Step 4 produces: A service description portfolio, built up as a set of non-conflicting services. Step 5 - produces: A confirmation of the merit and completeness of the model and service description portfolio, and a description of how the emerging target architecture meets the objectives of the architecture development. Step 7 - produces: A target architecture, fully specified in terms of Building Blocks; A fully-defined (by service) list of all the standards that make up the target architecture, and all the Building Blocks that will be used to implement it; A diagrammatic depiction of the building blocks at the levels needed to describe the strategic and implementation aspects of the architecture. Step 8 - produces: A gap analysis of eliminated building blocks, carried over building blocks, and new building blocks. Finally in Phase E: Opportunities and Solutions, the building blocks become more implementationspecific as Solutions Building Blocks, and their interfaces become the detailed architecture specification. The output of Phase E is the building block architecture, both in Architectural (i.e., functionally-defined) and Solution (i.e., product-specific) Building Block forms Levels of Modelling Defining and developing the context for a set of building blocks takes place at two levels: The business process level (coloured green in the following diagrams in this section). This deals only at the highest level with what has to happen for a business process to be carried out. This level generally maps to producing OV models to describe business needs and requirements, devoid of a technology solution set in the context of StV documents and models. The technical functionality and constraints level (coloured blue in the diagrams). This level deals with the component activities that form part of the business process and whether they can be supported or not. At this level of modelling, the architect mostly creates SV and TV models to describe a proposed technology solution that meets business requirements described in OV models. (The relationship to the SOA Views will need to be defined as thinking about Service Oriented evolves). Defining and developing an actual set of building blocks also takes place at two levels: The architectural model level (coloured red in the diagrams). This level identifies the systems and components that will implement the technical functionality and expresses the relationships between them. This level introduces the idea of a notation to describe the architectural elements and relationships. This level generally maps to MODAF s Operational View. The solution model level (coloured black in the diagrams). This is the level where the individual products and/or product components that will implement the architecture are identified. This level generally maps to MODAF s Systems and Technical Standards Views. Working through the four levels is an iterative process. Figure 16 shows how considerations at any level can result in change at any or all of the other levels. Reference: C370-EP-01 Page 38 of 84

41 Business Level Process High Level: - Initiate Sales process - Determine/agree requirements -... Technical Functionality & Constraints Level Component Activities: - Access product information - Run config tool -... Architectural Model Level Identify architectural elements - Select AABs - Identify relationships -... Solution Model Level Identify solution: - Select SBBs - Validate selections -... Figure 16: Iteration between the Four Levels of Modelling Mapping the Modelling Levels to the ADM The business process level of definition takes place in Phases A and B of the ADM. The technical functionality and constraints level work happens early in Phases B, C, and D, once the characteristics of the current system have been established. At that stage it is possible to identify the constraints imposed on new architecture work by the legacy of the old systems (the baseline). The architectural model and solution model levels consist of work done later in Phases B, C, and D, the target architecture steps of each phase, and Phase E, Opportunity Identification. Most architectural model work is done when taking different views of the architecture and developing the solution model work in Phase E, where selection of products and projects takes place. The rest of this Section consists of detailed excerpts of each of the nine ADM phases, augmented with the MODAF steps needed to produce MODAF models in conjunction with ADM work products. 8.3 WORKFLOW MODELLING CONVENTIONS USED IN THIS DOCUMENT This document has adopted the modelling convention used by the authors of the source reference document referred to in Section 2 of this document (Footnote 1: The Open Group Framework and the US DOD Framework: A White Paper, Nov 2006.). This convention derives from the Software Process Engineering Model (SPEM) 4 which is a metamodel used to describe a concrete software development process and their components. In the context of this document, there is no significance in the choice of this modelling convention other than consistency with a customer provided source reference. 4 OMG s SPEM Model(refer to Reference: C370-EP-01 Page 39 of 84

42 The workflow models shown in the remainder of this section use just three of the SPEM stereotypes which, for ease of reference, are defined in Table 4. Icon Name/Stereotype Definition Work Product Activity A Work Product is a description of a piece of information or physical entity produced or used by the activities of the software engineering process. Examples of Work Products include models, plans, code, executables, documents, databases etc, An Activity is a Work Definition describing what a Process Role performs. Activities are the main element of work. (Note: A Work Definition is a model element of a process describing the execution, the operations performed, and the transformations enacted on the Work Products by the roles. Activity, Iteration Phase, and Lifecycle are kinds of Work Definition) Document A Document is a specific instantiation of a Work Product. Table 4: SPEM stereotypes used in workflow models 8.4 PRELIMINARY PHASE: FRAMEWORK AND PRINCIPLES Objective The objectives of the Preliminary Phase are to: Ensure that everyone who will be involved in, or benefit from this approach, is committed to the success of the architectural process; Define the architecture principles that will inform the constraints on any architecture work; Define the architecture footprint for the organization the people responsible for performing architecture work, where they are located, and their responsibilities; Define the scope and assumptions (particularly in a federated architecture environment); Define the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned (typically, an adaptation of the generic ADM); Set up and monitor a process (normally including a pilot project) to confirm the fitness-for-purpose of the defined framework; If necessary, define a set of criteria for evaluating architecture tools (an example set of criteria is given in TOGAF Part IV), repositories and repository management processes to be used to capture, publish, and maintain architecture artefacts Approach The Preliminary Phase is about defining how we do architecture in the enterprise concerned. There are two main aspects: Defining the frameworks to be used; Defining the architecture principles that will inform the architecture work. Reference: C370-EP-01 Page 40 of 84

43 8.4.3 Framework The TOGAF ADM is a generic method, intended to be used by enterprises in a wide variety of industry types and geographies. This phase therefore involves doing any necessary work to adapt the ADM to define an organization-specific framework, using either the TOGAF deliverables or the deliverables of another framework. The issues involved in this are discussed under Adapting the ADM in the Introduction to the ADM. MODAF is an architecture framework that defines a set of elements and relationships, organized into views, that allow an architect to develop a description of the architecture of a current or postulated real-world configuration of resources, rules, and their relationships. MODAF does not prescribe a method, and using it in conjunction with the ADM allows an architect to produce an architecture description within a well-defined and repeatable process Inputs Inputs to this phase are: TOGAF ADM; MODAF v1.1; Business Strategy, Business Principles, Business Goals, and Business Drivers (when preexisting); IT Governance Strategy (when pre-existing); Principles (when pre-existing); Principles that are being subscribed to, arising from other, federated architectures Steps The TOGAF ADM is a generic method, intended to be used by a wide variety of different enterprises, and in conjunction with a wide variety of other architecture frameworks, if required. It is not practical to define specific steps for adapting the ADM to such a wide variety of potential contexts. The issues involved are discussed in detail under Adapting the ADM in the Introduction to the ADM. within the TOGAF Handbook Tailored Steps with MODAF The ADM may be used as the architecture development methodology when developing architecture artefacts that are compliant with MODAF. In completing the Preliminary Phase, initial versions of StV- 1, StV-2, AV-1 and OV-1 may be developed to capture the results of the Preliminary Phase. Figure 17 details the inputs, outputs, and the steps required to complete this phase of the TOGAF ADM. Reference: C370-EP-01 Page 41 of 84

44 Framework & Principles Constraint TOGAF ADM Constraint: Other AFs Framework Definition Business Drivers IT Governance Strategy AV1: Principles Principles Scope the Business Strategy AV-1, StV2, OV1: Business Principles Business Principles StV-1, AV-1, OV-1 Business Goals Business Goals Document Principles, Goals & Drivers StV-1, AV-1, Business Drivers Figure 17: ADM Workflow for the Preliminary Phase with MODAF Views Outputs The outputs of this phase are: Framework Definition; Principles; Restatement of, or reference to, Business Principles, Business Goals, and Business Drivers; Initial MODAF models StV-1, StV-2, AV-1, OV PHASE A: ARCHITECTURE VISION Objective The objectives of this phase are to: Ensure that this evolution of the architecture development cycle has proper recognition and endorsement from the corporate management of the enterprise, and the support and commitment of the necessary line management; Reference: C370-EP-01 Page 42 of 84

45 Validate the business principles, business goals, and strategic business drivers of the organization; Define the scope of, and to identify and prioritize the components of, the Baseline effort; Define the relevant stakeholders, and their concerns and objectives; Define the key business requirements to be addressed in this architecture effort, and the constraints that must be dealt with; Articulate an Vision that demonstrates a response to those requirements and constraints; Secure formal approval to proceed; Understand the impact on, and of, other enterprise architecture development cycles ongoing in parallel Inputs Inputs to this phase are: Request for Work; Business Strategy, Business Principles, Business Goals, and Business Drivers (when preexisting); Principles (when pre-existing); Enterprise Continuum existing architectural documentation (framework description, architectural descriptions, existing baseline descriptions, etc.) Steps Key steps in this phase include: Project Establishment; Business Principles, Business Goals, and Business Drivers; Principles; Scope; Constraints; Stakeholders and Concerns, Business Requirements, and Vision; Statement of Work and Approval Business Scenarios The ADM has its own method (a method-within-a-method ) for identifying and articulating the business requirements implied in new business functionality to address key business drivers, and the implied technical architecture requirements. This process is known as Business Scenarios, and is described in detail in TOGAF Part IV. The technique may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business. The generic Business Scenario process is as follows: 1. Problem: Identify, document, and rank the objective that is driving the project. Reference: C370-EP-01 Page 43 of 84

46 2. Business and Technical Environments: Document, as high-level architecture models, the business and technical environment where the problem situation is occurring. 3. Objectives and Measures of Success: Identify and document desired objectives, the results of handling the problems successfully. 4. Human Actors: Identify human actors and their place in the business model, the human participants and their roles. 5. Computer Actors: Identify computer actors and their place in technology model, the computing elements, and their roles. 6. Roles and Responsibilities: Identify and document roles, responsibilities, and measures of success per actor, the required scripts per actor, and the desired results of handling the situation properly. 7. Refine: Check for fitness-for-purpose of inspiring subsequent architecture work and refine only if necessary Tailored Steps with MODAF Obtain approval for Statement of Work to document Project Establishment. Gather Business Principles, Business Goals, and Business Drivers. Develop an StV-1 and an OV- 1 that models: Their relationships; Elements of the architecture that are constrained by them; Elements of the architecture that help achieve them; Develop an AV-1 to document Principles and Drivers and an StV-2 to assist in structuring the overall approach to developing the architecture; Develop StV-1 and OV-1 Views to document: Scope; constraints; Stakeholders and concerns; Business Requirements; Vision. Complete Statement of Work and Approval process within MODAF AV-1. Figure 18 details the inputs, outputs, and the steps required to complete this phase of the TOGAF ADM. Reference: C370-EP-01 Page 44 of 84

47 Vision Project Establishment Approved Statement of Work Enterprise Continuum Business Principles, Goals & Drivers Refined StV-1 and OV-1: Business Principles Request for Work Principles Principles StV-2 and AV-1: Principles Refined StV-1 & OV1 Business Goals Scope Refined StV-1 & OV1: Business Scenario Constraints Refined StV-1 & OV1: Business Drivers Stakeholders & Concerns, Business Requirements & Vision OV-1, StV-2: Vision Statement of Archtiecture Work & Approval Approved Statement of Work Figure 18: ADM Workflow for Phase A with MODAF Views Outputs The outputs of this phase are: Approved Statement of Work/Project Definition, including in particular: Scope and constraints; Plan for the architectural work; Refined statements of Business Principles, Business Goals, and Strategic Drivers; Principles (if not pre-existing); Vision; Business Scenario, including: Reference: C370-EP-01 Page 45 of 84

48 Baseline Business, Version 1; Baseline Technology, Version 1; Target Business, Version 1; Target Technology, Version 1; Refined MODAF models StV-1, StV-2, AV-1 and OV-1; Note: Multiple Business Scenarios may be used to generate a single Vision. In TOGAF terms, the Vision may also be referred to as a conceptual-level architecture. 8.6 PHASE B: BUSINESS ARCHITECTURE Objective The objectives of this TOGAF Phase are to: Describe the Baseline Business ; Develop a target Business, describing the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment, based on the business principles, business goals, and strategic drivers; Analyze the gaps between the baseline and target Business s; Select the relevant architecture Views that will enable the architect to demonstrate how the stakeholder concerns are addressed in the Business ; Select the relevant tools and techniques to be used in association with the elected viewpoints Inputs Inputs to this phase are: Request for Work; Approved Statement of Work/Project Definition; Refined statements of Business Principles, Business Goals, and Strategic Drivers; Principles; Enterprise Continuum; Vision/Business Scenario, including: Baseline Business, Version 1; Baseline Technology, Version 1; Target Business, Version 1; Target Technology, Version Tailored Steps with MODAF MODAF is not prescriptive with regard to the tools and techniques to be used in developing Views. Therefore a variety of modelling tools and techniques may be employed, if deemed appropriate (bearing in mind the above caution not to go into unnecessary detail). MODAF specifies development of the following models: Develop an initial Business context by creating OV-1 and StV-1 from the stated inputs to this Phase. Reference: C370-EP-01 Page 46 of 84

49 Identify relevant taxonomies and create a reference for each architecture element defined within the MODAF models (in all phases). The StV-2 (Capability Taxonomy) and the AV-2 (Integrated Dictionary) generated model repository can be used to provide traceability between architecture elements and their referenced taxonomies. Develop high-level OV-2, OV-5 (this probably comes first in this sequence), and OV-6, and generate matrix models to show mapping of business nodes to business functions. Utilize OV-7 to analyse inputs and outputs of business functions. Create an initial view of the information services required to support these process and data models by developing initial views of SOAV-2, SV-13. Develop OV-3 to define Information Exchange Requirements based on the initial assessment of the activity model (OV-5) and develop associated information service Views SOAV-4 and SOAV- 5. Develop more detailed OV-2 and supporting SOAV-2 to define the required information services, business groupings (nodes), the needlines between them, and the characteristics of the information exchanged. Develop more detailed OV-1 to establish a Business Baseline. Develop OV-4 to describe business nodes internal structures and SOAV-4 to determine supporting services. Generate OV-3 report to capture the information exchanged between business/operational nodes together with the key attributes of that information (many architecture tools can auto-generate this information exchange requirements matrix model.). Generate associated views of the services needed SOAV-4 and SOAV-5 - to support the activities at respective organisational nodes. Utilize all models to conduct analysis. Figure 19 details the inputs, outputs, and the steps required to complete this phase of the TOGAF ADM. Reference: C370-EP-01 Page 47 of 84

50 Updated Statement of Work Approved Statement of Work Develop a Business Baseline Description Validated Business Principles Vision Request for Work Reference Model, Viewpoints & Tools StV-1(Capability Vision), Target OV-1: Business AV2, SOAV-1: Taxonomy Description Model(s) Business Principles Enterprise Continuum Create Model for View Assure all stakeholder concerns are covered StV-5, StV-6: Business Views OV-1: Use Case Model OV-2, SOAV-2: Information & Service Operational Node Relationships Description Application Principles Information Requirements Perform Trade-Off Analysis OV-3, SOAV-4, SOAV-5: Activity/ Service/Information Exchange Matrix OV-5, OV-6 & SV-13: Business Process & Service Models OV-4 & SOAV-4: Operation Structures & Supporting Services Validate Models Business Baseline Version 2 Note & Document Changes Gap Analysis Results Technical Requirements Test Models Updated StV-1 & OV-1: Business Report Business Requirements Figure 19: ADM Workflow for Phase B with MODAF Views Outputs The outputs of this phase are: Statement of Work (updated if necessary); Validated Business Principles, business goals, and strategic drivers; Target Business, Version 2 (detailed), including: Refined StV-1 and OV-1 for the target architecture. Referenced taxonomies relevant to the architecture (defined for architecture elements and documented in AV-2 and for the capability context in StV-2). Business goals and objectives. Document business goals and objectives for each organizational unit. OV-5: Business functions. Identify and define business functions. This is a detailed, recursive step involving successive decomposition of major functional areas into sub-functions and their Reference: C370-EP-01 Page 48 of 84

51 constituent activities/processes with information of relevant organisational nodes where they take place. OV-5 & OV-6c: Business services (the services that each of the enterprise units provides to its customers, both internally and externally). OV-6c: Business processes (including measures and deliverables). Not covered explicitly by MODAF v1.1, but can be described using OV-2 and OV-4: Describes business roles, including development and modification of skills requirements, which may subsequently be updated from SV-9. SOAV-2 (Services Specification) and SV-13 (Service Provision). Based on the activities and business processes required to deliver business outcomes/objectives, develop views of the information services that will be required and the people and systems that will support these services. OV-4: Organization structure. Document the organization structure, identifying business locations and relating them to organizational units. SOAV-4 (Service Orchestration) and SOAV-5 (Service Behaviour). Documents how the information services will support the organisational activities and how these relate to organisational functions (and to the exchange of information across the organisation as defined in OV-3). OV-3: Operational Information Exchange Matrix. Developed as part of Business Data Model, detailing information requirements. Identify for each business function: when, where, how often, and by whom the function is performed; what information is used to perform it, and its source(s); and what opportunities exist for improvements. Show information that needs to be created, retrieved, updated, and deleted. The level of detail to be defined will depend on the scope and focus of the current architecture effort, as described under Approach, above. Focus on what will be worthwhile collecting for the purpose at hand. OV-2 and OV-5: Correlation of organization and functions. Relate business functions to organizational units in the form of a matrix report. Then use StV, AV, OV and SOAV MODAF models to produce: Business Baseline, Version 2 (detailed), if appropriate; Views corresponding to the selected viewpoints addressing key stakeholder concerns; Gap analysis results; Technical requirements (drivers for the Technology work): identifying, categorizing, and prioritizing the implications for work in the remaining architecture domains; e.g., by a dependency/priority matrix. (For example, guiding trade-off between speed of transaction processing and security.) List the specific models that are expected to be produced (for example, expressed as primitives of the Zachman Framework). Business Report; Updated business requirements; 8.7 PHASE C: INFORMATION SYSTEMS ARCHITECTURE Objective The objective of this phase is to develop target architectures covering either or both (depending on project scope) of the Data and Application Systems domains. The scope of the business processes supported in this phase is limited to those that are supported by information technology, and the interfaces of those IT-related processes to non-it-related processes. Reference: C370-EP-01 Page 49 of 84

52 8.7.2 Approach Development This phase involves some combination of Data and Applications, in either order. Advocates exist for both sequences. For example, Spewak s Enterprise Planning recommends a data-driven approach. The actual approach is likely to be organisation specific and will depend on factors such as: architecture vision, state of knowledge regarding the As-Is architecture, scope of the architecture endeavour and the maturity of the architecture function within an organisation. On the other hand, major applications systems such as those for Enterprise Resource Planning, Customer Relationship Management, etc. often provide a combination of technology infrastructure and business application logic, and some organizations take an application-driven approach, whereby they recognize certain key applications as forming the core underpinning of the mission-critical business processes, and take the implementation and integration of those core applications as the primary focus of architecture effort (the integration issues often constituting a major challenge). The architecture issue of interest here is just how constrained the architecture function is by out-of-thebox vendor solutions that limit degrees of freedom for the benefit of reduced implementation time and cost. Implementation Implementation of these two architectures (data and application) may not necessarily follow the same order. For example, one common implementation approach is top-down design and bottom-up implementation: Design: Business design; Data (or Applications) design; Applications (or Data) design; Technology design. Implementation: Technology implementation; Applications (or Data) implementation; Data (or Applications) implementation; Business implementation. An alternative approach is a data-driven sequence, whereby application systems that create data are implemented first, then applications that process the data, and finally applications that archive data Inputs Inputs to this phase are: Applications Principles (if existing); Data Principles (if existing); Request for Work; Statement of Work; Vision; Enterprise Continuum; Business Baseline, Version 2 (detailed), if appropriate; Reference: C370-EP-01 Page 50 of 84

53 Target Business, Version 2 (detailed); Relevant technical requirements that will apply to this phase; Gap analysis (from Business ); Re-usable building blocks (from organization's Continuum, if available) Steps Detailed steps for this phase are given separately for each architecture domain: Data. Applications Tailored Steps with MODAF Data Models: Develop the target architecture models by developing Data views to define Information Systems data elements and relationships: OV-7 Information Model; SV-1 1 Physical Schema (if appropriate) Generate SV-6 Report. Generate SV-6 Report Applications and Services architecture Models: Develop high-level view of the functionality and dynamics of Applications to support the required information services: SV-4 and SV-10 to define software services, applications, their structure and their dependencies, and generate matrix models to show mapping of business nodes to business functions. SOAV-1 to match services to functionality in accordance with an agreed taxonomy. SV-13 to understand the relationships between services, functionality, systems and people (users and operators of the service). Utilize SV-5 (Function to Operational Activity Traceability Matrix) and SOAV5 (Service Behaviour) to conduct gap analysis. Figure 20 details the inputs, outputs, and the steps required to complete this phase of the TOGAF ADM. Reference: C370-EP-01 Page 51 of 84

54 Application Principles Information Systems Updated: Statement of Work Data Principles Request for work Develop Data Models OV-7, SV-11: Data Views OV7, SV11: Target Data Statement of Work Vision Develop Apps (Services) Models Identify Candidate Application Systems SV-6: Data Report SOAV-1, SV-4, SV-10: Application Views Enterprise Continuum Business Baseline Version 2 Target Business Version 2 Relevant Technical Requirements Conduct formal checkpoint review Review the Qualitative Criteria Complete Applications Conduct Gap Analysis Use SV-5 & SOAV-5 SV-4, SV-10: Target Applications SV-5, SV13: Applications Report Use SV-5, SOAV-5: Gap Analysis Impact Analysis Gap Analysis StV-5,SOAV-2, Updated Business Requirements Figure 20: ADM Workflow for Phase C with MODAF Views Outputs The main outputs of this phase are: Statement of Work (updated if necessary); OV-7, SV-11: Target Data ; SV-4, SV-10: Target Applications ; OV-7, SV-11: Data Views corresponding to the selected viewpoints addressing key stakeholder concerns; SOAV-1, SV-4, SV-10: Applications Views corresponding to the selected viewpoints addressing key stakeholder concerns regarding required services; SV-6: Data Report, summarizing what was done and the key findings; Reference: C370-EP-01 Page 52 of 84

55 SV-5 and SV-13: Applications Report, summarizing what was done and the key findings SV-5 and SOAV-5: Gap analysis to show areas where the Business may need to change to cater for changes in the Data and/or Applications : Impact Analysis; StV-5 and SOAV-2: Updated business requirements (if appropriate). 8.8 PHASE D: TECHNOLOGY ARCHITECTURE Objective The objective of this phase is to develop a Technology that will form the basis of the following implementation work Approach Detailed guidelines for this phase, including Inputs, Steps, and Outputs, are given under TOGAF s Target Technology Detailed Description. This is the most comprehensive of the TOGAF descriptions and reflects the IT roots of the TOGAF concept. Continuum As part of this phase, the architecture team will need to consider what relevant Technology resources are available in the Continuum. In particular: The TOGAF Technical Reference Model (TRM); Generic technology models relevant to your organization's industry vertical sector; For example, the TeleManagement Forum (TMF) has developed detailed technology models relevant to the Telecommunications Industry; Technology models relevant to common systems architectures; For example, The Open Group has a Reference Model for Integrated Information Infrastructure that focuses on the application-level components and underlying services necessary to provide an integrated information infrastructure; Some additional resources not identified in TOGAF are; US Department of Defense Enterprise Reference Models; US Department of Defense NetCentric Operations & Warfare Reference Model; UK MOD Framework (MODAF); NATO C3 Technical Framework Inputs Inputs to this phase are: Technology Principles (if existing); Request for Work; Statement of Work; Vision; Relevant technical requirements from previous phases Reference: C370-EP-01 Page 53 of 84

56 Gap analysis (from Data ); Gap analysis (from Applications ); Business Baseline, Version 2 (detailed), if appropriate; Baseline Data, if appropriate; Baseline Applications, if appropriate; Target Business, Version 2 (detailed); Re-usable building blocks (from organization's Enterprise Continuum, if available); Target Data ; Target Applications Steps Technology Baseline Description Review Business Baseline, Data Baseline, and Application Systems Baseline, to the degree necessary to inform decisions and subsequent work. Develop a baseline description of the existing Technology, to the extent necessary to support the target Technology. The scope and level of detail to be defined will depend on the extent to which existing technology components are likely to be carried over into the target Technology, and on whether existing architectural descriptions exist, as described under Approach, above. Define for each major hardware or software platform type: Name (short and long); Physical location; Owner(s); Other users; Plain language description of what the hardware/software platform is and what it is used for; Business functions supported; Organizational units supported; Networks accessed; Applications and data supported; System inter-dependencies (for example, fall-back configurations). To the extent possible, identify and document candidate Technology building blocks (potential reusable assets). Draft the Technology Baseline Report: summarize key findings and conclusions, developing suitable graphics and schematics to illustrate baseline configuration(s). If warranted, provide individual Technology Baseline Descriptions as Annexes. Route the Technology Baseline Report for review by relevant stakeholders, and incorporate feedback. Refine the Baseline Description only if necessary. Target Technology See detailed steps. Detailed activities for this step, including Inputs, Activities, and Outputs, are given under Target Technology Detailed Description. Reference: C370-EP-01 Page 54 of 84

57 8.8.5 Tailored Steps with MODAF During Phase D, SV models that model the distribution of application and information systems across the systems environment and the dependencies of legacy systems on the IT infrastructure and services can be modelled using the following: Develop the Baseline Technology models SOAV-2, SV-1, SV-4, and SV-10; Document technology constraints in SV-7 and TV-1; Generate SV-5 reports to ensure the Technology meets business objectives; Generate SV-3 report; Document validated technology principles by refining SV-7 and TV-1 (if appropriate); Develop the Target Technology models (version 1) by refining StV-5, SV-1, SV- 4(refined), SV-1(refined), and SV-2 (if appropriate); Conduct Gap Analysis to generate Technology Deployment Plan (StV-3, StV-4, SV-5 and SV-13). Figure 21 details the inputs, outputs, and the steps required to complete this phase of the TOGAF ADM. Reference: C370-EP-01 Page 55 of 84

58 Technical Principles Phase D Technology Request for Work Review Business Baseline, Data Baseline, & Applications System Baselin Statement of Work Vision Develop Technical Baseline Identify and document candidate Technology Building Blocks Draft Technology Baseline Report Updated Statement of Work Relevant Technical Requirements Develop Technical Baseline Data Gap Analysis Application Gap Analysis Business Baseline Version 2 (detailed) Data Baseline descriptoin Application Baseline description Target Business Version 2 (detailed) Review Technical Baseline Consider Views Determine Criteria Create Baseline Select Services Select Building Blocks Create Architectural Models Confirm Business Objectives SOAV-2, SV1, SV-4, SV10: Technology Baseline Description SV-7, TV1: New Technology Principles SV-5: Confirm functionality matches business need SV-3: Technology Report SV-7, TV1: Validated Technology Principles Target Data Define Technology StV-5, SV-1, SV-2, SV-4(refined), SV-10(refined): Target Technology Version 1 Target Application Conduct Gap Analysis StV-3, StV-4, SV-5 (refined) & SV-13: Technology Deployment Plan Figure 21: ADM Workflow for Phase D with MODAF Views Outputs The outputs of this phase are: Statement of Work (updated if necessary); Baseline Technology : SOAV-2, SV-1, SV-4, SV-1 0. Validated Technology Principles, or new Technology Principles: SV-7, TV-1. Reference: C370-EP-01 Page 56 of 84

59 Technology Report: SV-3 (summarizing what was done and the key findings); Target Technology, Version 1; Technology gap report based on analysis of: StV-5, SV-1, SV-2, SV-4, SV-10; Viewpoints addressing key stakeholder concerns; Views corresponding to the selected viewpoints; 8.9 PHASE E: OPPORTUNITIES AND SOLUTIONS Objective The objectives of this phase are to: Evaluate and select among the implementation options identified in the development of the various target architectures (for example, build-versus-buy-versus-re-use options, and suboptions within those major options); Identify the strategic parameters for change, and the top-level work packages or projects to be undertaken in moving from the current environment to the target; Assess the dependencies, costs, and benefits of the various projects; Generate an overall implementation and migration strategy and a detailed Implementation Plan(s) Approach This phase identifies the parameters of change, the major phases along the way, and the top-level projects to be undertaken in moving from the current environment to the target. The output of this phase will form the basis of the Implementation Plan required to move to the target architecture. This phase also attempts to identify new business opportunities arising from the architecture work in previous phases. Sometimes the process of identifying implementation opportunities allows a business to identify new applications, and in this case it may be necessary to iterate between Phase E and previous phases. Iteration must be limited by time or money to avoid wasting effort in the search for a perfect architecture. Phase E is the first phase which is directly concerned with implementation and sees the first appearance of the MODAF-unique Acquisition Viewpoint and associated Views. The task is to identify the major work packages or projects to be undertaken. Expressing these in terms of capability over time also draws on the other MODAF-unique Viewpoint the Strategic Viewpoint. Phase E also makes use of the still evolving Service Oriented Views being created for MODAF that have been included in this document as a prototyping activity. An effective way to do this is to use the gap analysis on the business functions between the old environment and the new, created in Phase D. Any functions appearing as new items will have to be implemented (developed or purchased and deployed). Slightly harder to identify are the projects required to update or replace existing functions which must be done differently in the new environment. One of the options to be considered here is leaving an existing system in place and coexisting with the new environment. During this final step in the specification of building blocks it must be verified that the organizationspecific requirements will be met. Key to this is reason checking against the business scenario driving the scope of this project. It is important to note that the ensuing development process must include recognition of dependencies and boundaries for functions and should take account of what products are available in the marketplace. An example of how this might be expressed can be seen in the Building Blocks Example in TOGAF Part IV. Reference: C370-EP-01 Page 57 of 84

60 Coexistence appears on the surface to be easy. After all, the original system is left in place, largely unchanged. Unfortunately, it is not always as easy as it looks. The main problems with coexistence are: User interfaces: Combining user interfaces to the old and new applications in a single unit on the users' desks can be difficult, if not impossible. Access to data: Often the new applications need to share some data with the old applications, and some kind of data sharing must be established. This can be difficult unless the old and new systems use the same database technology. Connectivity: This may involve expenditure on software and gateway equipment. In difficult cases, equipment simply may not be available in a useful timescale. Often this happens because the old system is simply too out of date for connectivity solutions to be still on the market. The most successful strategy for Phase E is to focus on projects that will deliver short-term pay-offs and so create an impetus for proceeding with longer-term projects Inputs Inputs to this phase are: Request for Work; Statement of Work; Target Business ; Target Data ; Target Applications ; Target Technology ; Re-usable Building Blocks (from organization's Enterprise Continuum, if available); Product information Steps Key steps in this phase include: Identify the key business drivers constraining the sequence of implementation (for example, reduction of costs; consolidation of services; introduction of new customer services; etc.); Review the gap analysis generated in Phase D; Brainstorm technical requirements from a functional perspective; Brainstorm co-existence and interoperability requirements; Perform architecture assessment and gap analysis; Identify major work packages or projects, and classify as new development, purchase opportunity, or re-use of existing system; Tailored Steps with MODAF During Phase E, SV models that model the long-term Migration Plans and forecasts of technology and technology applications can be modelled using the following: Develop a long-term Migration Plan set in the context of capability delivery supported by information services and system roll-outs (StV3, SOAV-3 and SV-8); Reference: C370-EP-01 Page 58 of 84

61 Document technology forecasts and their possible application in future technology investments to optimise phased capability delivery through structured programmes (StV-4, AcV1, TV-2 and SV- 9); Conduct impact analysis to determine optimum project portfolio to match technology forecasts to capability phasing (AcV-2 and Project List). Figure 22 details the inputs, outputs, and the steps required to complete this phase of the TOGAF ADM. Opportunities & Solutions Identify Key Business Drivers StV3, SOAV-3, SV-8: Implementation & Migration Strategy Request for Work Review Gap Analysis Statement of Work Brainstorm Technical Requirements StV-4, AcV-1, SV-9, TV-2, :High Level Implementation Plan Baseline Version 2 Brainstorm co-existence & interoperability requirements Technology Perform Assessment & Gap Analysis AcV-2, Project List: Impact Analysis Project List: Impact Analysis Identify Major Work Packages Figure 22: ADM Workflow for Phase E with MODAF Views Outputs The outputs of this phase are: Implementation and migration strategy: StV-3, SOAV-3 and SV-8; High-level Implementation Plan: StV-4, AcV-1, SV-9 and, TV-2; Impact Analysis: AcV-2 and project list PHASE F: MIGRATION PLANNING Objective The objective of this phase is to sort the various implementation projects into priority order. Activities include assessing the services to be delivered, their dependencies, costs, and benefits in terms of the Reference: C370-EP-01 Page 59 of 84

62 various migration projects. The prioritized list of projects will go on to form the basis of the detailed Implementation and Migration Plan Approach There are some important questions to be asked before embarking on a migration exercise: What are the implications of this project on other projects and activities? What are the dependencies between this project and other projects and activities? What products are needed? What components must be developed? Does the organization have the resources needed to develop such components? What standards are the products or components built on? When will they be available? Will the products stand the test of time, both because of the technology they use and also because of the viability of the supplier? What is the cost of retraining the users? What is the likely cultural impact on the user community, and how can it be controlled? What is the total cost of the migration, and what benefits will it deliver? It is important to look at actual benefits, and not presumed benefits. Is the funding available? Is the migration viable? Many things affect the answers to these questions, including the current and future architectures, the size of the organization and its complexity, and the value of technology to the core functions of the organization. Other things to consider are the asset value of the current systems, and the level of risk associated with changing the solution and/or the supplier. Most organizations find that a change of architecture has too much impact on the organization to be undertaken in a single phase. Migration often requires consideration of a number of technical issues, not the least of which are those associated with the means of introducing change to operational systems. Issues requiring special consideration may include: Parallel operations; Choices of proceeding with phased migration by subsystem or by function; The impact of geographical separation on migration; The decisions resulting from these considerations should be incorporated in the Implementation Plan. There are a number of strategies for developing the Migration and Implementation Plan. The most successful basic strategy is to focus on projects that will deliver short-term pay-offs and so create an impetus for proceeding with longer-term projects. One common approach is to implement business functions in a data-driven chronological sequence; i.e., create the applications and supporting technology that create data before those that process the data, before those that simply store, archive, or delete data. For example, the following detailed description of this approach is taken from [SPE 68794]: 1. Determine the future disposition of current systems. Each current system is classified as: Mainstream systems part of the future information system. Contain systems expected to be replaced or modified in the planning horizon (next three years). Reference: C370-EP-01 Page 60 of 84

63 Replace systems to be replaced in the planning horizon. The current system disposition decisions should be made by business people, not IT people. 2. Applications should be combined or split into parts to facilitate sequencing and implementation. This rearrangement of applications creates a number of projects, a project being equivalent to an application or to combinations or parts of applications. 3. Develop the data sequence for the projects as described in the Data. Using the CRUD (Create/Read/Update/Delete) matrix developed as part of the Data, sequence the projects such that projects that create data precede projects that read or update that data. 4. Develop an estimated value to the business for each project. To do this, first develop a matrix based on a value index dimension and a risk index dimension. The value index includes the following criteria: principles compliance, which includes financial contribution, strategic alignment, and competitive position. The risk index includes the following criteria: size and complexity, technology, organizational capacity, and impact of a failure. Each of the criteria has an individual weight. The index and its criteria and weighting are developed and approved by senior management early in the project. It is important to establish the decision-making criteria before the options are known. In addition, there will be key business drivers to be addressed that will also tend to dictate the sequence of implementation, such as: Reduction of costs; Consolidation of services; Ability to handle change; A goal to have a minimum of interim solutions (they often become long-term/strategic!) Another, possibly complementary approach is for the individual projects or work packages to be group-sorted into a series of plateaux, each of which can be achieved in a realistic timescale. The following description assumes a Target with only a single time horizon Inputs Inputs to this phase are: Request for Work; Statement of Work; Target Business, Version 2; Target Technology ; Impact Analysis acquisition programme and project list; Steps Key steps in this phase include: Prioritize projects; Estimate resource requirements and availability; Perform cost/benefit assessment of the various migration projects; Perform risk assessment; Generate implementation roadmap (time-lined); Document the Migration Plan; Reference: C370-EP-01 Page 61 of 84

64 Tailored Steps with MODAF. During Phase F, a detailed SV-8 can be refined to model short and long-term Migration Plans and to conduct impact analysis. Figure 23 details the inputs, outputs, and the steps required to complete this phase of the TOGAF ADM. Migration Planning Prioritize Projects StV-5 Capability Delivery Plan: Impact Analysis Request for Work Estimate Resource Requirements Statement of Work Perform Cost/Benefit Assessment AcV-1, AcV-2 Programme Delivery Plan: Impact Analysis Baseline Version 2 Perform Risk Assessment Technology Generate Implementation Roadmap SOAV-3, SOAV-4 Service Delivery Plan: Impact Analysis Project List: Impact Analysis Document the Migration Plan SV-8 Detailed Implementation & Migration Plan: Impact Analysis Figure 23: ADM Workflow for Phase F with MODAF Views Outputs The output of this phase is: Capability Delivery Plan: StV-5 (in terms of capability improvements based on system delivery); Programme Delivery Plan: AcV-1, AcV-2 (in terms of system acquisition); Service Delivery Plan: SOAV-3, SOAV-4 (converts system delivery into services as recognised by end-users) Impact Analysis: SV8 (Detailed Implementation and Migration Plan, including Implementation Contract, if appropriate) PHASE G: IMPLEMENTATION GOVERNANCE Objective Reference: C370-EP-01 Page 62 of 84

65 The objectives of this phase are to: Formulate recommendations for each implementation project contained in the Implementation Plan. Construct an architecture contract to govern the overall implementation and deployment process in terms of capability improvements and service delivery. Perform appropriate governance functions while the system and associated services are being implemented and deployed. Ensure conformance with the defined architecture by implementation projects and other projects Approach It is here that all the information for successful management of the various implementation projects is brought together. Note that in parallel with this phase there is the execution of an organizationalspecific development process, where the actual development happens. This phase establishes the connection between architecture and implementation organization, through the Contract. Project details are developed, including: Name, description, and objectives; Scope, deliverables, and constraints; Measures of effectiveness; Acceptance criteria; Risks and issues. Implementation governance is closely allied to overall Governance, which is discussed in TOGAF Part IV, Governance. A key aspect of this phase is ensuring compliance with the defined architecture(s), not only by the implementation projects but also by other ongoing projects within the enterprise. The considerations involved with this are explained detail in TOGAF Part IV, Compliance Inputs Inputs to this phase are: Request for Work; Statement of Work; Re-usable Solutions Building Blocks (from organization's Solutions Continuum, if available); Impact Analysis Detailed Implementation and Migration Plan (including Implementation Contract, if appropriate) Steps Key steps in this phase include: Project recommendation formulation; for each separate implementation project do the following: Document scope of individual project in Impact Analysis; Document strategic requirements (from the architectural perspective) in Impact Analysis; Document change requests (such as support for a standard interface) in Impact Analysis; Document rules for conformance in Impact Analysis; Reference: C370-EP-01 Page 63 of 84

66 Document timeline requirements from roadmap in Impact Analysis. Document Contract - Obtain signature from all developing organizations and sponsoring organization; Ongoing implementation governance and architecture compliance review Tailored Steps with MODAF During Phase G, the architecture description created as a set of integrated models during the previous phases may be utilized to produce implementation recommendations. The StV, SOAV, SV and TV models can be utilized by system integrators as a high-level system of systems architecture model that describes capability in terms of information services and systems interoperability needs and a possible technology solution. StV-1, AV-1 and OV-1 are additional resources to ensure that the architecture s implementation complies with key information captured in this model (assumptions, constraints, principles, drivers, etc.). Figure 24 details the inputs, outputs, and the steps required to complete this phase of the TOGAF ADM. Implementation Governance Contract based on full range of Refined Outputs (below) Request for Work Project Recommendation Formulation Refined AV-1: Implementation Recommendations & Impact Analysis Statement of Work Document Contract Refined OV-1: compliant Implemented System Refined StV-1, StV-2, StV-3, StV4: Strategic Implementation Roadmap Detailed Implementation & Migration Plan: Impact Analysis Ongoing Implementation Governance Refined AV-1, AV-2: input to the Through Life Management Plan Refined SOAV-2, SOAV- 3, SOAV-4: Service Level Agreement Figure 24: ADM Workflow for Phase G with MODAF Views Outputs The outputs of this phase are: Impact Analysis: AV-1 (refined) providing Implementation recommendations; Reference: C370-EP-01 Page 64 of 84

67 Contract: As recommended in TOGAF Part IV and based on the full range of output products from this Phase; The architecture-compliant implemented system: OV-1(refined); Strategic Implementation Roadmap: Strategic Views that together show how capability will be delivered and integrated with existing capability to move towards the target architecture (StV-1, StV-2, StV-3 and StV-4). Through Life Management Plan ( input): AV-1 (supported by AV-2) provides an overall summary view of what the architecture is to deliver supported by a clear statement of the services that will result (SOAV-2, SOAV-3 and SOAV-4). Note: The implemented system is actually an output of the development process. However, given the importance of this output, it is stated here as an output of the architecture development method. The direct involvement of architecture staff in implementation will vary according to organizational policy, as described in TOGAF Part IV, Governance PHASE H: ARCHITECTURE CHANGE MANAGEMENT Objective The objective of this phase is to establish an Change Management process for the new enterprise architecture baseline that is achieved with completion of Phase G. This process will typically provide for the continual monitoring of such things as new developments in technology and changes in the business environment, and for determining whether to formally initiate a new architecture evolution cycle. This phase also provides for changes to the Framework and Principles set up in the Preliminary Phase Approach The goal of an Change Management process is to ensure that changes to the architecture are managed in a cohesive and architected way, and to establish and support the implemented enterprise architecture as a dynamic architecture; that is, one having the flexibility to evolve rapidly in response to changes in the technology and business environment. The Change Management process once established will determine: The circumstances under which the enterprise architecture, or parts of it, will be permitted to change after implementation; and the process by which that will happen; The circumstances under which the enterprise architecture development cycle will be initiated again to develop a new architecture. The Change Management process is very closely related to the architecture governance processes of the enterprise, and to the management of the Contract between the architecture function and the business users of the enterprise. In this phase it is critical that the governance body establish criteria to judge whether a change request warrants just an architecture update or whether it warrants starting a new cycle of the architecture development method. It is especially important to avoid creeping elegance, and the governance body must continue to look for changes that relate directly to business value by reference to the relevant Governance documents (e.g. Request for Work) and their relevance to the Contract and the business context (which is defence in the case of MODAF) established by products such as StV-1 and AV-1. Guidelines for establishing these criteria are difficult to prescribe, as many companies accept risk differently, but as the architecture development method is exercised, the maturity level of the governance body will improve, and criteria will become clear for specific needs Inputs Inputs to this phase are: Reference: C370-EP-01 Page 65 of 84

68 Request for Change technology changes: New technology reports; Asset management cost reduction initiatives; Technology withdrawal reports; Standards initiatives. Request for Change business changes: Business developments; Business exceptions; Business innovations; Business technology innovations; Strategic change developments; Steps Key steps in this phase include: Ongoing monitoring of technology changes; Ongoing monitoring of business changes; Assessment of changes and development of position to act; Meeting of Board (or other governing council) to decide on handling changes (technology and business) Tailored Steps with MODAF During Phase H, the MODAF architecture models that were created as a set of integrated models during the previous phases may be utilized to conduct change management, where all modification changes are made in the model and communicated to the various stakeholders. Further, StV-1, SV-9 and TV-2 may be specifically used to model future plans for the systems modelled in the various MODAF models. Figure 25 details the inputs, outputs, and the steps required to complete this phase of the TOGAF ADM. Reference: C370-EP-01 Page 66 of 84

69 Change Management Request for Change Technology Changes Ongoing Monigtoring of Technology Changes StV-1, SV-9, TV-2: Updates Ongoing Monitoring of Business Changes New Request for Work Request for Change Business Changes Assessment of Changes Meeting of Board Figure 25: ADM Workflow for Phase H with MODAF Views Outputs The outputs of this phase are: StV-1: The overall business context for MODAF products SV-9, TV-2: updates; Changes to Framework and Principles; New Request for Work (to move to another cycle). Reference: C370-EP-01 Page 67 of 84

70 9 MODAF PRODUCT DEVELOPMENT WITHIN THE CONTEXT OF THE TOGAF ADM PHASES The following subsections document our TOGAF relationship observations associated with each MODAF architecture model, now defined in the MODAF Version 1.1 document, which supercedes the Technical Handbook (Version 1.0). It is important to note that there are cases where no MODAF descriptive model was identified for a certain TOGAF construct. This should not be considered a problem. The goal of this document is to outline which parts of the TOGAF ADM relate to the intended content of each MODAF architectural model. MODAF can thus be leveraged to develop a visual model of the architecture and to use this model in facilitating and documenting decisions made during each one of the iterative ADM steps. The TOGAF ADM build cycle is both incremental and iterative in which means that there is likely to be complex many-to-many linkages between the ADM phases and the developments of each of the MODAF Views which, as outlined in the previous section of this paper, are themselves intended to be developed iteratively. Therefore to capture and document all of the mappings between TOGAF ADM phases and steps with the resulting MODAF Views would be a case of too much detail to be of use to the busy architect. Furthermore, the detailed mapping of TOGAF ADM phases and steps to MODAF Views will, to some extent, depend on specific organisational factors and also on the specific approach adopted by the architectural team. Consequently, this document will only map what are considered to be the most significant relationships between the TOGAF ADM and MODAF Views. Each of the following subsections provides a Product Description for each of the MODAF Views together with a high level summary of the relationship mapping with TOGAF phases and steps. For completeness, the following subsection includes Product Descriptions and summary mappings for those MODAF Service Oriented (SOA) Views that are emerging from joint MOD/NATO working. It should be noted that, at this moment in time, there is only limited information available on SOA View profiles and, furthermore, there are no formally endorsed SOA Views. 9.1 ALL VIEW PRODUCTS Overview and Summary Information (AV-1) Product Description: The Overview and Summary Information (AV-1) provides executive-level summary information in a consistent form that allows quick reference and comparison between s. AV-1 includes assumptions, constraints, and limitations that may affect high- level decisions relating to the. AV-1 contains sufficient textual information to enable a reader to select one from among many to read in more detail. AV-1 serves two additional purposes. In the initial phases of development, it serves as a planning guide. Upon completion of, AV-1 provides summary textual information about the. TOGAF ADM Relationships: TOGAF ADM elements supporting the development of AV-1 include Vision, IT Governance Strategy, Principles, and Impact Analysis. AV-1 is initially populated during TOGAF s Preliminary Phase and Phase A: Vision. It is updated to reflect results during TOGAF Phase G: Implementation Governance Integrated Dictionary (AV-2) Product Description: The Integrated Dictionary (AV-2) presents all the Elements used in an architecture as a stand alone structure. All the Elements are modelled as a specialisation hierarchy, must provide a text definition for each one and references the source of the element (e.g. MODAF Ontology, IDEAS Model, local, etc.). An AV-2 shows elements from the MODAF Ontology that have been used in the architecture and new elements (i.e. not in the MODAF Ontology) that have been introduced by the architecture. TOGAF ADM Relationships: AV-2 development begins during TOGAF Phase B: Business and evolves across all remaining phases of TOGAF ADM. Reference: C370-EP-01 Page 68 of 84

71 9.2 CAPABILITY VIEW PRODUCTS Enterprise Vision (StV-1) Product Description: The Enterprise Vision (StV-1) addresses the enterprise concerns associated with the overall vision for transformational endeavours and thus defines the strategic context for a group of Enterprise capabilities. The purpose of an StV-1 is to provide a strategic context for the capabilities described in the. It also provides a high-level scope for the which is more general than the scenario-based scope defined in an OV-1. The Views are high-level and describe capabilities using terminology which is easily understood by non-technical readers (though they may make extensive use of military terminology and acronyms that are clearly defined in the AV-2 View). TOGAF ADM Relationships: StV-1 defines the total business environment as it articulates the primary business output, namely Capability, required of MOD (not just architecture). It therefore must be available from the very outset in order to provide context for AV-1 and OV-1. Therefore StV-1 development begins during TOGAF s Preliminary Phase is continued in Phase A: Vision and is further refined as part of Phase B: Business. Because of its strategic nature it is also relevant to Phase G: Implementation Governance and to Phase H: Change Management Capability Taxonomy (StV-2) Product Description: The Capability Taxonomy (StV-2) presents a hierarchy of capabilities. These capabilities may be presented in context of an Enterprise Phase i.e. it can show the required capabilities for current and future enterprises. StV-2 specifies all the capabilities that are referenced throughout one or more architectures. In addition it can be used as a source document for the development of high-level use cases and Key User Requirements (KUR). TOGAF ADM Relationships: The initial view of StV-2 is developed in conjunction with StV-1 during the TOGAF Preliminary Phase and then used and refined in Phase A: Vision (Scoping the ) and again early in Phase B: Business. It may also need to be updated as a result of iterative development during TOGAF Phase G: Implementation Governance where it might affect the development of the SV-9 View (Systems Technology Forecast) Capability Phasing (StV-3) Product Description: The Capability Phasing (StV-3) View provides a representation of the planned or current available military capability at different points in time or during specific Periods of time. StV- 3 Products support the Capability Audit process and similar processes used across the different COIs by providing a method to identify gaps or duplication in capability provision. The View is created by analysing programmatic project data to determine when Systems providing elements of military capability are to be delivered, upgraded and/or withdrawn (this data may be provided in part by an SoS Acquisition Programmes (AcV-2) View). An StV-3 Product can be used to assist in the identification of capability gaps/shortfalls (no fielded capability to fulfil a particular capability function) or capability duplication/overlap (multiple fielded capabilities for a single capability function). Where a capability cannot be equated on a one-to-one mapping with a particular System, further analysis can be assisted using the information provided in a Capability to Systems Deployment Mapping (StV-5) Product. TOGAF ADM Relationships: StV-3 is a pervasive View that, it could be argued, is relevant to all TOGAF Phases. However, it is suggested that it is primarily a derivative of the Acquisition Process and is closely related to the development of AcV-2 as well as to SV-1. Therefore, it is most closely associated with TOGAF Phase E: Opportunities and Solutions and strongly influenced by Phase D: Technology and Phase G: Implementation Governance Capability Dependencies (StV-4) Reference: C370-EP-01 Page 69 of 84

72 Product Description: The Capability Dependencies (StV-4) View describes the relationships between capabilities. It also defines logical groupings of capabilities. The StV-4 View is intended to provide a means of analysing the dependencies between capabilities and between capability clusters. The groupings of capabilities are logical, and the purpose of the groupings is to guide acquisition the dependencies and clusters may suggest appropriate liaisons between acquisition projects in order to get the overall military capability. An StV-4 View shows the capabilities (or capability functions) which are of interest to the. It groups those capabilities into logical groupings ( clusters ), based on the need for those elements to be integrated. These clusters serve to inform the acquisition process and the Capability Phasing (StV-3) View. TOGAF ADM Relationships: StV-4 is very similar in nature to StV-3 the main difference being one of scope and consequent ownership of the View (with each group having a logically derived owner based primarily on Capability Management considerations but possibly influenced by Procurement Management factors). Based on the same rationale as for StV-3, StV-4 is most closely associated with TOGAF Phase E: Opportunities and Solutions and strongly influenced by Phase D: Technology and Phase G: Implementation Governance Capability to Organisation Deployment Mapping (StV-5) Product Description: The Capability to Organisation Deployment Mapping (StV-5) shows the planned capability deployment and interconnection for a particular Enterprise Phase. This view will provide a more detailed dependency analysis than is possible using StV-3. StV-5 View is used to support the capability management process and, in particular, assist the planning of fielding. It shows deployment of systems in types of organisations (e.g. echelons), and the connections between those systems, to satisfy the military capability for a particular period of time (or Epoch). When appropriate and if necessary the View can show how all relevant DLODs combine to provide the fielded capability. In order to conduct a comprehensive analysis, several StV-5 Views are created to represent the Periods of time that are being analysed. Although the StV-5 Views are represented separately, Systems and other DLODs may exist in more than one View. The information used to create the StV- 5 is drawn from other MODAF Views (StV-2, StV-4, OV-2, SV-3, AcV-2, etc), and includes: capability functions, System connectivity, Organisational structures, period of time definitions, and Programmatic information. TOGAF ADM Relationships: StV-5 is probably one of the most pervasive or highly connected Views in MODAF as can be seen from the View Relationship mapping provided earlier in this paper and as outlined in the Product Description. Given that the key aspects of StV-5 are the matching of system functionality, connectivity and organisations then StV-5 would be created during TOGAF Phase B: Business, Phase C: Information Systems (Applications) and Phase D: Technology. Given the linkage to options assessment and implementation, StV-5 is also likely to be refined during Phase F: Migration Planning Operational Activity to Capability Mapping (StV-6) Product Description: Operational Activity to Capability Mapping (StV-6) describes the mapping between the capabilities required by an Enterprise and the operational activities that those capabilities support. It is important to ensure that the operational activity matches the required capability. The StV- 6 View provides a bridge between capability analyses using StVs and operational activities analysed using OVs. Specifically, it identifies how operational activities can be performed using various available capability elements. It is similar in function to the SV5 which maps system functions to operational activities. TOGAF ADM Relationships: Although StV-6 must show the linkages between all DLODs its primary purpose is to show that all components are in place to support the business/operational needs. StV-6 is likely to be created as part of TOGAF Phase B: Business. 9.3 OPERATIONAL VIEW PRODUCTS OVs describe the tasks and activities, operational elements, and information exchanges required to conduct operations. There are twelve OV Products: High-Level Operational Concept Graphic (OV-1a); Reference: C370-EP-01 Page 70 of 84

73 Operational Concept Description (OV-1b); Operational Performance Attributes (OV- 1 c); 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 and Timing Descriptions (OV-6a, 6b, and 6c); Information Model (OV-7) High Level Operational Concept (OV-1) Product Description: The High Level Operational Concept (OV-1) sets the context for the architecture being described in the remaining models. It does this by describing a mission and highlighting the main nodes (see OV-2 definition) and any interesting or unique aspects of operations. It provides a description of the interactions between the subject architecture and its environment, and between the architecture and external assets. OV-1 should reflect the principles, constraints and environment defined in AV-1. To ensure that OV-1 contains the richness needed to support the full range of MODAF Views, it is divided into three component views: High Level Operational Concept Graphic (OV-1a); High Level Operational Concept Description (OV-1b); Operational Performance Attributes (OV-1c). TOGAF ADM Relationships: The three components of OV-1 are the graphical summary of the text that documents the Vision, IT Governance Strategy, Principles, and Impact Analysis. All three OV-1 component Views are initially developed during TOGAF s Preliminary Phase and then used and refined during Phase A: Vision (Scoping the ) and again early in Phase B: Business. It is also updated to reflect results during TOGAF Phase G: Implementation Governance High Level Operational Concept Graphic (OV1-a) Product Description: The High-Level Operational Concept Graphic (OV1-a) describes a mission, class of mission, or scenario; and highlights main Operational Nodes (see OV-2 definition) and interesting or unique aspects of operations. It provides a description of the interactions between the subject and its environment, and between the and external systems. A textual description accompanying the graphic is crucial. Graphics alone are not sufficient for capturing the necessary data. The purpose of OV-1a is to provide a quick, high-level description of what the is supposed to do, and how it is supposed to do it. An OV-1a Product can be used to orient and focus detailed discussions. Its main utility is as a facilitator of human communication, and it is intended for presentation to high- level decision makers High Level Operational Concept Description (OV-1b) Product Description: The Operational Concept Description (OV-1b) Product provides a supplementary textural description that explains and details the scenario contained within the associated High Level Operational Concept Graphic (OV-1a) View. The OV-1b Product will always be developed alongside the associated OV-1a View. An OV-1 b Product is used to explain and add further detail to the graphical presentation of the scenario shown in the associated OV-1a View. As such it will be prepared alongside the OV-1 and used together they will provide a comprehensive summary of the scenario / use case described within the Operational Views of the. The Reference: C370-EP-01 Page 71 of 84

74 OV-1 b will also be used to provide a description of the operational context for the scenario / use case under consideration within the other Operational Views Operational Performance Attribute (OV1-c) Product Description: An Operational Performance Attributes (OV-1 c) Product provides detail of the operational performance attributes associated with the scenario / use case represented in the High Level Operating Concept Graphic (OV-1). An OV-1c Product is used to specify quantifiable attributes and values within the scenario / use case represented in the OV-1 View. The values expressed define the performance of specific or multiple capability elements, and can be represented as either single values, or a range of values across a defined timescale Operational Node Relationship Description (OV-2) Product Description: The Operational Node Relationship Description (OV-2) addresses localisation of operational capability. The primary purpose of the OV-2 View is to define the Nodes that provide the focus for the expression of capability requirements within an operational context. The OV-2 may also be used to express a capability boundary. A secondary purpose of the OV-2 View is to define a logical network of information flows. The Nodes on the logical network need not correspond to specific organisations, systems or locations, allowing Information Exchange Requirements (IERs) to be established without prescribing the way that the information exchange is handled and without prescribing solutions. In addition, MODAF allows the OV-2 to show flows of people, materiel or energy between Nodes. Note that there are several significant extensions to the OV-2 as used by DoDAF. TOGAF ADM Relationships: OV-2 is developed during TOGAF Phase B which produces the Business Elements of: Business, Business Baseline, Business View and Business Data Operational Information Exchange Matrix (OV-3) Product Description: The Operational Information Exchange Matrix (OV-3) details information exchanges and identifies who exchanges what information, with whom, why the information is necessary, and how the information exchange must occur. There is not always a one-to-one mapping of OV-3 information exchanges to OV-2 Needlines; rather, many individual information exchanges may be associated with one Needline. Information exchanges express the relationship across the three basic data elements of an OV (Operational activities, Operational Nodes, and information flow) with a focus on the specific aspects of the information flow and the information content. The aspects of the information exchange that are crucial to the operational mission will be tracked as attributes in OV-3. For example, if the subject concerns tactical battlefield targeting, then the timeliness of the enemy target information is a significant attribute of the information exchange. TOGAF ADM Relationships: There is a coarse correlation between OV-3 production and TOGAF Phase B: Business (Business Modelling), where information exchanges are discussed within the context of what information is required to enable the activity model to be effective Organisational Relationships Chart (OV-4) Product Description: The Organisational Relationships Chart (OV-4) illustrates the command structure or relationships (as opposed to relationships with respect to a business process flow) among human roles, organisations, or organisation types that are the key players in an. An OV-4 Product clarifies the various relationships that can exist between organisations and sub-organisations within the and between internal and external organisations. An OV-4 Product illustrates the relationships between organisations in an. There can be many types of interorganisational relationships such as supervisory reporting, Command and Control (C2) relationships, collaboration and so on. The more commonly used types are defined in the MODAF Taxonomy. TOGAF ADM Relationships: This architectural model is developed during TOGAF ADM Phase B: Business. OV-4 maps directly to the TOGAF Business activities. TOGAF ADM requires the identification of the organisation structure and the business locations relationships to organisational units. Reference: C370-EP-01 Page 72 of 84

75 9.3.5 Operational Activity Model (OV-5) Product Description: The Operational Activity Model (OV-5) describes the operations that are normally conducted in the course of achieving a mission or a business goal. It describes operational activities (or tasks), Input/Output (I/O) flows between activities, and I/O flows to/from activities that are outside the scope of the. An OV-5 Product describes operational activities (or tasks), I/O flows between activities, and I/O flows to/from activities that originate or terminate outside the scope of the. The business rules that govern the performance of the activities can also be keyed to each activity. (Business rules are described in OV-6a.). The activities described in an OV-5 may correspond to capabilities. StV-6 describes the mapping from capabilities to the operational activities that they support. TOGAF ADM Relationships: Activity models are explicitly addressed within TOGAF ADM Phase B: Business Operational Activity Sequence & Timing Description (OV-6a, 6b & 6c) OV Products discussed in previous sections model the static structure of the elements and their relationships. Many of the critical characteristics of are only discovered when the dynamic behaviour of these elements is modelled to incorporate sequencing and timing aspects of the. The dynamic behaviour referred to here concerns the timing and sequencing of events that capture operational behaviour of a business process or mission thread for example. Thus, this behaviour is related to the activities of OV-5. Several modelling techniques may be used to refine and extend the s OV to adequately describe the dynamic behaviour and timing performance characteristics of an, OV-6 includes three such models. They are: Operational Rules Model (OV-6a); Operational State Transition Description (OV-6b); Operational Event-Trace Description (OV-6c) Operational Rules Model (OV-6a) Product Description: The Operational Rules Model (OV-6a) specifies operational or business rules that are constraints on an enterprise, a mission, operation, business, or on an. While other OV Products (e.g. OV-1, OV-2, OV-5) describe the structure and operation of a business, for the most part they do not describe the constraints and rules under which it operates At the mission level, OV-6a may consist of doctrine, guidance, rules of engagement, and so forth. At the operation level, rules may include such things as a military Operational Plan (OPLAN). At lower levels, OV-6a describes the rules under which the or its Nodes behave under specified conditions. Such rules can be expressed in a textual form, for example, If (these conditions) exist, and (this event) occurs, then (perform these actions). TOGAF ADM Relationships: The TOGAF ADM discussed rules as an element within the activity model(s) developed in Phase B: Business, as an annotation of that activity information Operational State Transition Description (OV-6b) Product Description: The Operational State Transition Description (OV-6b) is a graphical method of describing how an Operational Node or activity responds to various events by changing its state. The diagram represents the sets of events to which the will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. The explicit sequencing of activities in response to external and internal events is not fully expressed in OV-5. An Operational State Transition Description can be used to describe the explicit sequencing of the operational activities. TOGAF ADM Relationships: OV6-b is one of the MODAF OV models that model behaviour (along with OV-5 and OV-6c). TOGAF ADM does not specify a modelling notation or technique, but operational states can be described during TOGAF Phase B: Business Operational Event Trace Description (OV-6c) Reference: C370-EP-01 Page 73 of 84

76 Product Description: The Operational Event-Trace Description (OV-6c) provides a time-ordered examination of the information exchanges between participating Operational Nodes as a result of a particular scenario. Each event-trace diagram will have an accompanying description that defines the particular scenario or situation. OV-6c is valuable for moving to the next level of detail from the initial operational concepts and helps define Node interactions and operational threads. It can also help ensure that each participating Operational Node has the necessary information it needs at the right time in order to perform its assigned Operational Activity. TOGAF ADM Relationships: The dynamic behaviour referred to in MODAF concerns the timing and sequencing of events that capture the operational behaviour of operational activities, thus describing a process or a mission thread. OV-6c is a Process (Control) Flow diagram for those operational processes where the sequence is known. The TOGAF ADM requires the description of the business process and scenarios during Phase B: Business Information Model (OV-7) Product Description: The Information Model (OV-7) describes the structure of an domain s system data types and the structural business process rules (defined in the s Operational Viewpoint) that govern the system data. It provides a definition of domain data types, their attributes or characteristics, and their interrelationships. An OV-7 Product showing the domain s system data types or Entity definitions, is a key element in supporting interoperability between s, since these definitions may be used by other organisations to determine system data compatibility. TOGAF ADM Relationships: The MODAF Logical Data Model describes the structure of an architecture domain s information and data types and the structural business rules (as defined in the architecture s Operational View) that govern the data. It provides the architecture domain vocabulary, taxonomy and upper-level ontology (product, material, data enumeration lists, and decomposition) related to communities of interest. OV-7 is developed during TOGAF Phase C: Information Systems [Data ]. 9.4 SERVICE ORIENTED ARCHITECTURE VIEW PRODUCTS Subscribers can use information from the service provider s OV-2 to build the portions of their own OV-2 that include use of services from the service provider. The subscribers fill in the blanks or make specific the relevant generic portions of the service provider s OV-2. Note: At the time of publication, the MOD approach to service oriented s had not been finalised. A later release (or addendum) to the Handbook will provide clearer guidance on how to represent services in MODAF Products. The MODAF Service Oriented Views are currently being developed in a joint MOD/NATO activity to define a set of views for architecting services. The aim of this work is to enable planners to make best use of available services by understanding: What services are available and what level of service can be provided; What the services do and how they interact; What interfaces (for information) the services provide; Define how the available services are put together to achieve the planners intent. It is envisaged that there will be a Meta Model for SOA and that the scope of the SOA Views will cover anything that delivers a specified outcome. It will be defined so as to provide a way of specifying both the interfaces required to create the service and those interfaces available for the delivery of the service. These services may or may not have a physical effect. Knowing the type and level of services available and the required and available interfaces to generate and deliver them will enable planners to generate capability by orchestrating a number of services (or components) to meet specific operational requirements. Reference: C370-EP-01 Page 74 of 84

77 The concept of Service currently being adopted by the NATO/MOD development team is much wider than just information services. However, for the purpose of this paper, it will be assumed that the focus of MODAF s interest is that of information services. This is reflected in the ERM presented earlier in this paper that shows the service element as a broker between information and the activity that either consumes or creates the information Service Taxonomy Description (SOAV-1) Product Description: The Service Taxonomy Description (SOAV-1) view documents the hierarchy of services, their attributes and associated policies (constraints). This taxonomy will define the full range of services available across the enterprise (standard, value added, core enterprise, infrastructure and warfighting) supported by the full range of system services (e.g. storage, application, collaboration and situation picture). TOGAF ADM Relationships: SOAV-1 is intended to provide a business focussed definition of services. It is therefore likely to be an outcome of TOGAF Phase B: Business and also be closely linked to the development of StV-2 (Capability Taxonomy). It is also likely to be affected by the outcome of TOGAF Phase C: Information Systems (Application ) Services Specification Description (SOAV-2) Product Description: The Service Description (SOAV-2) view defines interfaces, operations, messages and data-type parameters of the service(s) required to support operations. TOGAF ADM Relationships: This View correlates operations, information and data transfer which may required a mediating input from an implementation perspective. Therefore, SOAV-2 will be created as a result of TOGAF Phase B: Business, Phase C: Information System (both Application and Information s), Phase D: Technology and Phase G: Implementation Governance Service Composition Description (SOAV-3) Product Description: The Service Composition Description (SOAV-3) defines services composed of other services, their respective inputs and outputs and the service component interfaces. TOGAF ADM Relationships: SOAV-3 is to do with the assembly of existing services into new services which is primarily a planning and governance function given that SOAV-2s already exist. Therefore SOAV-3 Views will primarily be developed as part of TOGAF Phase E: Opportunities and Solutions, Phase F: Migration Planning and Phase G: Implementation Governance Service Orchestration Description (SOAV-4) Product Description: The Service Orchestration Description (SOAV-4) specifies how a number of component services are orchestrated/assembled to support operational activities. TOGAF ADM Relationships: SOAV-4 links composite services to business needs which means there is a focus on planning and managing the integration of functionality to support business activity. SOAV-4 is therefore likely to be an outcome of TOGAF Phase F: Migration Planning, Phase B: Business, Phase C: Information Systems and Phase G: Implementation Governance Service Behaviour Description (SOAV-5) Product Description: The Service Behaviour Description (SOAV-5) documents the functions (activity models), state machines that comprise each component service as well as the interactions between those component services being orchestrated to delivery an operational capability. TOGAF ADM Relationships: Creation of SOAV-5 involves linking activity models (in the Business ) with system functionality created in the Application. Therefore SOAV-5 is developed as part of TOGAF Phase B: Business and Phase C: Information Systems (Applications) Service Provision Description (SV-13) Reference: C370-EP-01 Page 75 of 84

78 Product Description: The Service Provision Description (SV-13) defines which combinations of platforms, systems and people (capability configurations) are required to provide services. TOGAF ADM Relationships: SV-13 describes how the DLODs combine in an enterprise to deliver a specified level of service. SV-13 will therefore be developed as a result of TOGAF Phase B: Business, Phase C: Information Systems and Phase D: Technology. 9.5 SYSTEM VIEW PRODUCTS SVs in MODAF v1.1 are now, in the most part, significantly changed from DODAF. In particular, they specifically allow for human factors in solution specifications, rather than only depicting technical systems. SV Products provide a set of graphical and textual information that together describe systems and their interconnections. There are fifteen SV Products: Resource Interaction Specification (SV-1); Systems Communications Description (SV-2a,2b,2c); 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); Systems Functionality and Timing Descriptions (SV-10a, 10b, and 10c); Physical Schema (SV-1 1) Resource Interaction Specification (SV-1) Product Description: The Resource Interaction Specification (SV-1) 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. An SV-1 may represent the realisation of a requirement specified in an OV-2 (i.e. in a to-be architecture), and so there may be many alternative SV suites that could realise the operational requirement. Alternatively, in an as-is architecture, the OV-2 may simply be a simplified, logical representation of the SV-1 to allow communication of key information flows to non-technical stakeholders. A resource interaction is a simplified representation of a pathway or network, usually depicted graphically as a connector (i.e. a line with possible amplifying information). The SV-1 depicts all interactions between resources that are of interest to the architect. Note that interactions between systems may be further specified in detail in SV-2 and SV-6. Sub-resource assemblies may be identified in SV-1 to any level (i.e. depth) of decomposition the architect sees fit. SV-1 may also identify the Physical Assets (e.g. Platforms) at which resources are deployed, and optionally overlay Operational Nodes that utilise those resources. In many cases, an operational node depicted in an OV-2 product may well be the logical representation of the resource that is shown in SV-1. TOGAF ADM Relationships: SV-1 links the operational nodes described in 0V-2 with systems resident at these nodes. It also identifies the system to node interfaces. These models are used during TOGAF ADM Phase D: Technology [Developing Views: Systems Engineering View] Systems Communications Description (SV-2a, 2b, 2c) Reference: C370-EP-01 Page 76 of 84

79 The SV-2 View is split into three component Views which define the communications links between systems. The Views are: SV-2a System Port Specification - defines the ports on each system, and the protocol / hardware stack that is specified or implemented for each of those ports. SV-2b System to System Port Connectivity - defines the connections between individual ports and shows the protocols and hardware spec used for each connection. SV-2c System Connectivity Clusters - defines the bundles of system to system connections that go to make up an inter-nodal connection (see SV-1). The goal of these Views is to provide a comprehensive specification of how systems are connected, what interfaces each system exposes (ports), the hardware interface used, and the protocols which are transmitted across the interface. Key elements are repeated from View to View, and are also common to the SV-1 View. These key elements are: Systems; Nodes; Ports; System-to-system connections; Inter-nodal connections. TOGAF ADM Relationships: The Systems Communications Description depicts relevant information about communications systems, their linkages and connecting networks. SV-2 overall documents the kinds of communications media that support the systems and implement their interfaces as described in SV-1. All three components of SV-2 are developed during TOGAF ADM Phase D: Technology [Developing Views: Communications Engineering View] System Port Specification (SV-2a) Product Description: A System Port Specification (SV-2a) Product specifies the ports on a system, and the protocols used by those ports when communicating with other systems. An SV-2a Product is intended to provide a specification for how each system in the can communicate with other systems, is used to fully describe the communications protocols and hardware specifications of each port on a system. The View comprises of one diagram for each system in the. Each port on the system is specified in terms of: Its name; The communications protocols used (e.g. OSI Stack); The physical port specification (e.g. the physical element of the stack) System to System Port Connectivity (SV-2b) Product Description: A System to System Port (SV-2b) Product defines the protocol stack used by a connection between two ports. The ports may be on different systems. An SV-2b Product comprises a set of diagrams showing each connection between ports of systems. The architect may choose to create a diagram for each connection in the (recommended) or to show all the connections on one diagram (may be harder for readers to follow). Each diagram shall show: Which ports are connected; The systems that the ports belong to; The nature of the connection in terms of the physical connectivity and any protocols that are used in the connection. Reference: C370-EP-01 Page 77 of 84

80 9.5.4 Resource Interaction Matrix (SV-3) Product Description: The Resource Interaction Matrix (SV-3) provides detail on the interface characteristics described in SV-1 for the, arranged in matrix form. An SV-3 Product allows a quick overview of all the resource interactions presented in multiple SV-1 diagrams. The matrix form can support a rapid assessment of potential commonalities and redundancies (or, if faulttolerance is desired, the lack of redundancies). Furthermore, it can be organised in a number of ways (e.g., by domain, by operational mission phase) to emphasise the association of groups of system pairs in context with the purpose. SV-3 can be a useful tool for managing the evolution of systems and system infrastructures, the insertion of new technologies/functionality, and the redistribution of systems and processes in context with evolving operational requirements. TOGAF ADM Relationships: The Resource Interaction Matrix provides detail on the interface characteristics described in SV-1 and can be utilised as a supporting model within TOGAF ADM Phase D: Technology [Developing Views: System Engineering View] Functionality Description (SV-4) Product Description: The Functionality Description (SV-4) documents human and system functional hierarchies and/or data flow activity. Although there is a correlation between the Operational Activity Model (OV-5) or business-process hierarchies and the system functional hierarchy of SV-4, it need not be a one-to-one mapping, hence, the need for the Operational Activity to Systems Function Traceability Matrix (SV-5), which provides that mapping. The primary purposes of SV-4 are to: Develop a clear description of the necessary system data flows that are input (consumed) by and output (produced) by each system; Ensure that the functional connectivity is complete (i.e. that a system s required inputs are all satisfied); Ensure that the functional decomposition reaches an appropriate level of detail. TOGAF ADM Relationships: This View documents functional hierarchies and system functions and services and the system data flows between them. SV-4 supports TOGAF ADM Phase C: Information Systems [Applications ] and Phase D: Technology [Developing Views: Data Flow View] SV-4 is used to model supported system inter-dependencies, software services, applications, their structure and their dependencies Function to Operational Activity Traceability Matrix (SV-5) Product Description: The Function to Operational Activity Traceability Matrix (SV-5) is a specification of the relationships between the set of operational activities applicable to an and the set of system functions applicable to that. It thus identifies the transformation of an operational need into a purposeful action performed by a system i.e. how the system function supports the conducting of the Operational activity. SV-5 can be extended to depict the mapping of capabilities to operational activities, operational activities to system functions, system functions to systems, and thus relates the capabilities to the systems that support them. Such a matrix, in conjunction with StV-3, 5 & 6, allows decision makers and planners to quickly identify stove-piped systems, redundant/duplicative systems, gaps in military capability, and possible future investment strategies all in accordance with the time stamp given to the. TOGAF ADM Relationships: SV-5 maps the operational activity documented in OV-5 to the set of system functions/services identified that will support those activities. Although there is a correlation between Operational Activity Model (OV-5) or business process hierarchies and the functional hierarchy descriptions of SV-4, it need not be a one-to-one mapping, hence the need for the Operational Activity to Function to Operational Activity Traceability Matrix (SV-5), which provides that mapping. This information can be auto-generated by many architecture tools and can be used to support the alignment of TOGAF ADM Phase B (Business ) with Phases C (Information Systems ) and D (Technology ). Reference: C370-EP-01 Page 78 of 84

81 9.5.7 Systems Data Exchange Matrix (SV-6) Product Description: The Systems Data Exchange Matrix (SV-6) specifies the characteristics of the system data exchanged between systems. This Product focuses on automated information exchanges (from OV-3) that are implemented in systems. Non-automated information exchanges, such as verbal orders, are captured in the OV Products only. System data exchanges express the relationship across the three basic data elements of an SV (systems, system functions, and system data flows) and focus on the specific aspects of the system data flow and the system data content. These aspects of the system data exchange can be crucial to the operational mission and are critical to understanding the potential for overhead and constraints introduced by the physical aspects of the implementation. TOGAF ADM Relationships: The Systems Data Exchange Matrix model focuses on automated information exchanges (from OV-3 requirements) that are implemented in systems. Contents of the SV-6 View relate to each data element s description, consumer, producer, performance attributes, and information assurance attributes. SV- supports TOGAF Phase C: Information Systems (Applications ) Resource Performance Parameters Matrix (SV-7) Product Description: The Resource Performance Parameters Matrix (SV-7) specifies the quantitative characteristics of systems roles or capability configuration items, their interfaces (system data carried by the interface as well as communications link details that implement the interface), and their functions. The Resource Performance Parameters Matrix expands on the information presented in an SV-1 by depicting the characteristics of the Functional Resources shown in the SV-1. TOGAF ADM Relationships: The Resource Performance Parameters Matrix specifies the current performance parameters for each system, interface or system function as well as the expected or required performance parameters at specified times in the future. SV-7 supports TOGAF ADM Phase D: Technology [Developing Views, System Engineering View] Capability Configuration Management (SV-8) Product Description: Capability Configuration Management (SV-8) captures evolution plans that describe how the resource, or the in which the resource is embedded, will evolve over a lengthy period of time. Generally, the timeline milestones are critical for a successful understanding of the evolution timeline. SV-8, when linked together with other evolution Products such as AcV-2, SV-9 and TV-2, provides a clear definition of how the and its resources are expected to evolve over time. In this manner, the Product can be used as an evolution project plan or transition plan. TOGAF ADM Relationships: SV-8 documents the sequencing plan to be used to evolve from the As- Is to the To-Be system states. TOGAF ADM Phase E: Opportunities and Solutions, and Phase F: Migration Planning are both centred on this aspect of architecting and align with the MODAF model Technology and Skills Forecast (SV-9) Product Description: The Technology and Skills Forecast (SV-9) defines the underlying current and expected supporting technologies. It includes predictions of availability and readiness of emerging technologies and the skill levels required. Expected supporting technologies are those that can be reasonably forecast given the current state of technology and expected improvements. New technologies will be tied to specific time periods, which can correlate against the time periods used in SV-8 milestones. SV-9 provides a summary of emerging technologies that impact the and its existing planned systems. The focus will be on the supporting technologies that may most affect the capabilities of the or its systems and the skill resources required. TOGAF ADM Relationships: SV-9 summarises future software and hardware technologies, including skills resources, which might impact the architecture and the deployed systems over defined timeframes. Although there is no explicit relationship within TOGAF ADM, SV-9 could be utilised during TOGAF Phase E: Opportunities and Solutions as an extension to the implementation details, and during Phase H: Change Management Resource Sequence & Timing Description (SV-10a, 10b, & 10c) Reference: C370-EP-01 Page 79 of 84

82 Overview of Resource Sequence and Timing Descriptions (SV-10a, 10b, & 10c) Many of the critical characteristics of an are only discovered when an s dynamic behaviours are defined and described. These dynamic behaviours concern the timing and sequencing of events that capture system performance characteristics of an executing system (i.e., a system performing the system functions described in SV-4). Behaviour modelling and documentation is key to a successful description, because it is how the behaves that is crucial in many situations. Although knowledge of the functions and interfaces is also crucial, knowing whether, for example, a response should be expected after sending message X to Node Y can be crucial to successful overall operations. Three types of models may be used to adequately describe the dynamic behaviour and performance characteristics of a SV. These three models are: Resource Constraints Specification (SV-10a); Resource State Transition Description (SV-10b); Resource Event-Trace Description (SV-1 0c); SV-10b and SV-10c may be used separately or together, as necessary, to describe critical timing and sequencing behaviour in the SV. Both types of diagrams are used by a wide variety of different systems methodologies Resource Constraints Specification (SV-10a) Product Description: Resource Constraints Specification (SV-10a) are constraints on an, on a system(s) resources, or system hardware/software item(s), and/or on a system function(s). While other SV Products (e.g., SV-1, SV-2, SV-4, SV-11) describe the static structure of the System Viewpoint (i.e., what the systems can do), they do not describe, for the most part, what the systems must do, or what they cannot do. At the systems or system hardware/software items level, SV-10a describes the rules under which the or its system(s) resources behave under specified conditions. At lower levels of decomposition, it may consist of rules that specify the pre- and post-conditions of system functions. TOGAF ADM Relationships: SV-10b is a systems perspective of 0V-1a and describes the rules by which the architecture or its systems behave under specified conditions. The TOGAF ADM mentions rules as an element within the activity model (OV-5) in Phase B: Business, but SV-10a can be utilised as a supporting model within TOGAF ADM Phase C: Information Systems [Applications ] and Phase D: Technology [Developing Views: Systems Engineering View] Resource State Transition Description (SV-10b) Product Description: The Resource State Transition Description (SV-10b) is a graphical method of describing a system resource (or system function) response to various events by changing its state. The diagram basically represents the sets of events to which the systems in the will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. The explicit time sequencing of system functions in response to external and internal events is not fully expressed in SV-4. SV-10b can be used to describe the explicit sequencing of the system functions. Alternatively, SV-1 0b can be used to reflect explicit sequencing of the actions internal to a single system function, or the sequencing of system functions with respect to a specific system. TOGAF ADM Relationships: The Resource State Transition Description is a graphical method of describing system resources (or its functions) responses to various events by changing its state. SV- 10b is the resource transition state perspective of OV-6b. System and Resource States can be described during the TOGAF ADM Phase C: Information Systems s [Applications ] and Phase D: Technology [Developing Views: Systems Engineering View] Resource Event Trace Description (SV-10c) Product Description: The Resource Event-Trace Description (SV10-c) provides a time-ordered examination of the data and resource elements exchanged between participating systems (external Reference: C370-EP-01 Page 80 of 84

83 and internal), system functions, or human roles as a result of a particular scenario. Each event-trace diagram will have an accompanying description that defines the particular scenario or situation. SV- 10c in the System Viewpoint may reflect system-specific aspects or refinements of critical sequences of events described in the Operational Viewpoint. SV-10c Products are valuable for moving to the next level of detail from the initial systems design, to help define a sequence of functions and data interfaces, and to ensure that each participating resource, system function, or human role has the necessary information it needs, at the right time, in order to perform its assigned functionality. TOGAF ADM Relationships: SV-10c is the resource perspective of OV-6c and identifies resource specific sequences of the events described in OV-6c. SV-10c can be used to support TOGAF ADM Phase C: Information Systems s [Applications and Phase D: Technology [Developing Views: Systems Engineering Views] Physical Schema (SV-1 1) Product Description: The Physical Schema Product (sv-11) is one of the Architectural Products closest to actual system design in the Framework. SV-1 1 is an implementation-oriented Data Model that is used in the System Viewpoint to describe how the information requirements represented in Logical Information Model (OV-7) are actually implemented. The Product defines the structure of the various kinds of system data that are utilised by the systems in the and it serves several purposes, including: Providing as much detail as possible on the system data elements exchanged between systems, thus reducing the risk of interoperability errors; Providing system data structures for use in the system design process, if necessary. TOGAF ADM Relationships: SV-11 defines the structure of the various kinds of system data that are utilised by the systems in the architecture. TOGAF ADM discusses the development of higher-level database models (conceptual, logical) during Phase C: Information Systems [Data ] 9.6 TECHNICAL VIEW PRODUCTS TVs provide the technical systems-implementation standards upon which engineering specifications are based, common building blocks are established, and Product lines are developed. There are two TV Products: Technical Standards Profile (TV-1); Technical Standards Forecast (TV-2). Technical Standards Views are extended from the core DoDAF views to include non-technical standards such as operational doctrine, industry process standards, etc Technical Standards Profile (TV-1) Product Description: The Technical Standards Profile (TV-1) defines the technical and non-technical standards, guidance and policy applicable to the architecture. As well as identifying applicable technical standards, TV-1 may document the policies and standards that apply to the operational or business context. In most cases building an Profile will consist of identifying and listing the applicable portions of existing and emerging technical documentation. A TV-1 should identify both existing guidelines as well as any areas lacking guidance. As with other products, each profile is assigned a specific timescale (eg as-is, to-be or transitional). Linking the profile to a defined timescale allows the profile to consider both emerging technologies and any current technologies or standards that are expected to be updated or become obsolete. If more than one emerging standard time-period is applicable to your architecture, then you should complete a Standards Forecast (TV-2) as well as a TV-1. Reference: C370-EP-01 Page 81 of 84

84 TOGAF ADM Relationships: TV-1 can be utilised as a supporting model within TOGAF ADM Phase D: Technology [Developing Views: Systems Engineering View] Technical Standards Forecast (TV-2) Product Description: The Technical Standards Forecast (TV-2) contains expected changes in technology-related standards and conventions, which are documented in the TV-1 Product. The forecast for evolutionary changes in the standards need to be correlated against the time periods mentioned in the SV-8 and SV-9 Products. A Standards Forecast is a detailed description of emerging standards relevant to the systems and business processes covered by the architecture. The forecast should be tailored to focus on areas that are related to the purpose for which a given architecture description is being built, and should identify issues that will affect the architecture. A TV-2 complements and expands on the Standards Profile (TV-1) product and should be used when more than one emerging standard time-period is applicable to the architecture. For standards advice refer to the JSP 602 series of documents. One of the prime purposes of this Product is to identify critical technology standards, their fragility, and the impact of these standards on the future development and maintainability of the and its constituent elements. TOGAF ADM Relationships: TV-2 can be utilised as a supporting model within TOGAF ADM Phase E: Opportunities & Solutions, and during Phase H: Change Management. 9.7 ACQUISITION VIEW PRODUCTS Acquisition Views (AcVs) are unique to MODAF, implemented in addition to those in DODAF. They have been introduced to describe programmatic details, including dependencies between projects and capability integration across all of the Defence Lines of Development (DLODs). These Views guide the acquisition and fielding processes. There are two AcV Products: Acquisition Clusters (AcV-1); Programme Timelines (AcV-2) Acquisition Clusters (AcV-1) Product Description: Acquisition Clusters (AcV-1) Product describes how acquisition projects are organisationally grouped in order to form coherent acquisition programmes. The System of Systems Acquisition Clusters View enables the user to define the best acquisition structure to support the multiple projects under analysis. The goal is to populate the hierarchy of acquisition clusters and programmes with projects that integrate together and / or are highly dependent upon each other, so as to improve the ability to manage this integration / dependency. As such, this View is primarily of interest to those who are responsible for programmes of acquisition projects. TOGAF ADM Relationships: AcV-1 is about assembling realistic groupings of systems that have some common management aspects that will allow them to be managed within a project/programme portfolio. This will start with the high level implementation planning in TOGAF Phase E: Opportunities and Solutions, it will be refined as part of the more detailed implementation planning of TOGAF Phase F: Migration Planning and then empowered as part of TOGAF Phase G: Implementation Governance Programme Timelines (AcV-2) Product Description: Programme Timelines (AcV-2) Product provides an overview of a programme of individual projects, based on a time-line. It summarises, for each of the projects illustrated, the level of maturity achieved across the DLODs at each stage of the CADMID lifecycle, and the interdependencies between the project stages. The AcV-2 View is intended primarily to support the acquisition and fielding processes including the management of dependencies between projects and the integration of all the DLODs to achieve a successfully integrated military capability. The information provided by the View can be used to determine the impact of either planned or unplanned programmatic changes, and highlight opportunities for optimisation across the delivery programme. TOGAF ADM Relationships: Whereas AcV-1 is of most interest to Capability and Project Managers, AcV-2 is of most interest to the business/operational community who will be responsible for planning the introduction into service of new capability and ensuring all DLODs are in place to deliver military Reference: C370-EP-01 Page 82 of 84

85 capability. It is likely to be generated by the same TOGAF Phases as for the development of AcV-1 only this time driven by deployment issues. This means that AcV-2 will be developed by the high level implementation planning in TOGAF Phase E: Opportunities and Solutions, it will be refined as part of the more detailed implementation planning of TOGAF Phase F: Migration Planning and then empowered as part of TOGAF Phase G: Implementation Governance. Reference: C370-EP-01 Page 83 of 84

86 End of document Reference: C370-EP-01 Page 84 of 84