TOGAF TO MODAF MAPPING

(1)

TOGAF TO MODAF

MAPPING

Reference: C370-EP-01

Version: 2.1

(2)

Basingstoke

Taylormade Court

Jays Close, Viables Business Park Basingstoke Hants RG22 4BS T: +44 (0) 1256 302270 F: +44 (0) 1256 302271 Bath office: 5 Riverside Court Lower Bristol Road Bath BA2 3DZ

T: +44 (0) 1225 820980 F: +44 (0) 1225 820981 E: [email protected]

W: www.hiqsigma.com

Company registered in England, number 2158796.

Registered Office: Goodrich House, 1 Waldegrave Road, Teddington, TW11 8LZ.

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

(3)

DOCUMENT AUTHORISATION

Author(s):

(this issue)

First Name Surname

R Forder & M Duffy

………. ………….

(Written or Electronic Signature) (Date)

First Name

Surname ………. ………….

First Name

Surname ………. ………….

Reviewer(s): First Name

Surname ………. ………….

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.

(4)

CHANGE RECORD

Version Date Description of Change

2.1 09/12/2010 Updated to reflect BMT Branding

DISTRIBUTION LIST

(5)

(6)

CONTENTS

1 introduction ... 9

1.1 The approach ... 9

1.2 Background ... 9

1.2.1 Enterprise Architecture and Architecture Frameworks ... 10

1.2.2 Enterprise Architecture Benefits ... 10

1.2.3 Ministry of Defence Architecture Framework (MODAF) ... 11

1.2.4 Open Group Architecture Framework (TOGAF)... 12

1.3 Purpose ... 13

1.4 Architecture – The Evolutionary Context ... 14

2 Overview Of Mapping Analysis Results ... 15

3 TOGAF ADM to MODAF mapping – concept of analysis ... 18

3.1 The Enterprise Reference Model ... 18

4 MODAF – Summary Of Views... 20

5 Relationships between MODAF views ... 25

6 Overview Of Architecture Development Methods ... 26

6.1 Background ... 26

6.2 Rationale for the development guidance provided ... 26

6.3 MODAF Development Process ... 26

6.4 DODAF Development Process... 27

6.4.1 Introduction... 28

6.4.2 Summary of DODAF Development Stages ... 28

6.4.3 Sequence of DODAF View Development ... 30

6.5 TOGAF ARCHITECTURE development method (adm) ... 31

6.6 Mapping DODAF Development Procces To togaf adm Phases ... 33

7 MODAF’s Iterative Approach to development – The Implications For Mapping ... 35

7.1 Iteritive Product Development ... 35

8 Architecture Development Method (ADM) With MODAF Artefacts ... 36

8.1 Introduction ... 36

8.2 ADM architecture requirements management ... 36

8.2.1 Objective ... 36

8.2.2 Approach ... 36

8.2.3 MODAF Models ... 36

8.2.4 Building Block Specification Process in the ADM ... 36

8.2.5 Levels of Modelling ... 38

8.2.6 Mapping the Modelling Levels to the ADM ... 39

(7)

8.4 Preliminary Phase: Framework And Principles ... 40 8.4.1 Objective ... 40 8.4.2 Approach ... 40 8.4.3 Framework ... 41 8.4.4 Inputs ... 41 8.4.5 Steps ... 41

8.4.6 Tailored Steps with MODAF ... 41

8.4.7 Outputs... 42

8.5 phase a: Architecture vision ... 42

8.5.2 Inputs ... 43

8.5.3 Steps ... 43

8.5.4 Business Scenarios ... 43

8.5.6 Outputs... 45

8.6 Phase B: Business architecture ... 46

8.6.2 Inputs ... 46

8.6.4 Outputs... 48

8.7 Phase c: information systems architecture ... 49

8.7.2 Approach ... 50

8.7.3 Inputs ... 50

8.7.4 Steps ... 51

8.7.6 Outputs... 52

8.8 phase d: technology architecture ... 53

8.8.2 Approach ... 53

8.8.3 Inputs ... 53

8.8.4 Steps ... 54

8.8.6 Outputs... 56

8.9 phase e: opportunities and solutions ... 57

(8)

8.9.3 Inputs ... 58

8.9.4 Steps ... 58

8.9.6 Outputs... 59

8.10 phase f: migration planning ... 59

8.10.1 Objective ... 59

8.10.2 Approach ... 60

8.10.3 Inputs ... 61

8.10.4 Steps ... 61

8.10.5 Tailored Steps with MODAF. ... 62

8.10.6 Outputs... 62

8.11 phase g: implementation governance ... 62

8.11.1 Objective ... 62

8.11.2 Approach ... 63

8.11.3 Inputs ... 63

8.11.4 Steps ... 63

8.11.6 Outputs... 64

8.12 phase h: architecture change management ... 65

8.12.1 Objective ... 65

8.12.2 Approach ... 65

8.12.3 Inputs ... 65

8.12.4 Steps ... 66

8.12.6 Outputs... 67

9 MODAF Product development Within The Context Of the TOGAF ADM phases ... 68

9.1 All View Products ... 68

9.1.1 Overview and Summary Information (AV-1) ... 68

9.1.2 Integrated Dictionary (AV-2) ... 68

9.2 Capability View Products ... 69

9.2.1 Enterprise Vision (StV-1)... 69

9.2.2 Capability Taxonomy (StV-2) ... 69

9.2.3 Capability Phasing (StV-3) ... 69

9.2.4 Capability Dependencies (StV-4) ... 69

9.2.5 Capability to Organisation Deployment Mapping (StV-5) ... 70

9.2.6 Operational Activity to Capability Mapping (StV-6) ... 70

(9)

9.3.1 High Level Operational Concept (OV-1) ... 71

9.3.2 Operational Node Relationship Description (OV-2) ... 72

9.3.3 Operational Information Exchange Matrix (OV-3) ... 72

9.3.4 Organisational Relationships Chart (OV-4) ... 72

9.3.5 Operational Activity Model (OV-5) ... 73

9.3.6 Operational Activity Sequence & Timing Description (OV-6a, 6b & 6c) ... 73

9.3.7 Information Model (OV-7)... 74

9.4 Service Oriented Architecture View Products ... 74

9.4.1 Service Taxonomy Description (SOAV-1) ... 75

9.4.2 Services Specification Description (SOAV-2) ... 75

9.4.3 Service Composition Description (SOAV-3)... 75

9.4.4 Service Orchestration Description (SOAV-4) ... 75

9.4.5 Service Behaviour Description (SOAV-5) ... 75

9.4.6 Service Provision Description (SV-13) ... 75

9.5 System View Products ... 76

9.5.1 Resource Interaction Specification (SV-1) ... 76

9.5.2 Systems Communications Description (SV-2a, 2b, 2c) ... 76

9.5.3 System Port Specification (SV-2a) ... 77

9.5.4 Resource Interaction Matrix (SV-3) ... 78

9.5.5 Functionality Description (SV-4) ... 78

9.5.6 Function to Operational Activity Traceability Matrix (SV-5)... 78

9.5.7 Systems Data Exchange Matrix (SV-6) ... 79

9.5.8 Resource Performance Parameters Matrix (SV-7) ... 79

9.5.9 Capability Configuration Management (SV-8) ... 79

9.5.10 Technology and Skills Forecast (SV-9) ... 79

9.5.11 Resource Sequence & Timing Description (SV-10a, 10b, & 10c) ... 79

9.5.12 Physical Schema (SV-1 1) ... 81

9.6 Technical View Products ... 81

9.6.1 Technical Standards Profile (TV-1) ... 81

9.6.2 Technical Standards Forecast (TV-2) ... 82

9.7 Acquisition View Products ... 82

9.7.1 Acquisition Clusters (AcV-1) ... 82

(10)

(11)

1

INTRODUCTION

Enterprise Architecture (EA) is the outcome of applying a development process known as an Architecture Design Methodology (ADM) to a set of rules defined in an Enterprise Architecture Framework (EAF).

EA = (ADM) + (EAF)

In the context of this document, these components are:

Enterprise Architecture = Stakeholder defined views of Defence Logistics: THE WHAT Architecture Design Methodology = TOGAF ADM (v8.1.1): THE HOW

Enterprise Architecture 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 Architecture Development Method (ADM) to the creation of Views as defined by the MOD Architecture 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.

Unifying Enterprise Reference Model

(Elements important to the enterprise)

TOGAF to MODAF Mapping Report

Enterprise Architecture Framework (MODAF v1.0)

(Defines 7 Viewpoints & 44 Views)

Architecture Development Methodology (TOGAF v8.1.1) (9 stage process) THIS DOCUMENT ----

---&

Requirements A. Architecture Vision B. Business Architecture C. Information Systems Architecture H. Architecture Change Management G. Implementation Governance F. Migration Planning E. Opportunities & Solutions D. Technology Architecture Prelim: Framework & Principles Capability

Strategy, Policy & Objectives

Technical Standards P ro je cts R e q u ire m en ts Infrastructure Systems Data Information Activity Trained competence Organisational Unit Deliver Drive G overns G overns Conducts Support s Governs Governs Deployed on To use Deplo yed at Has Pro duces/ consum es Maps to Depends on Decomposes Produces/ consumes Acquisition Viewpoint Articulates acquisition programme construct, milestones, dependencies and LoDs status Strategic Viewpoint Articulates the capability picture to support capability management and equipment planning

Technical Viewpoint Articulates policy, standards, guidance and constraints to specify and assure quality expectations Operational Viewpoint Articulates operational picture to support operational analysis, requirements definition, and solution acceptance

Systems Viewpoint Articulates system composition and interconnectivity to support systems analysis

and through life management

All Viewpoint Provides summary information that specifies the architecture product,pertinent to the entire

architecture Services Viewpoint Articulates the type and level of services required, how they are assembled and interact,

and what interfaces are required

MODAF

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

(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 Architecture 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.

1.2.1 Enterprise Architecture and Architecture Frameworks

Enterprise Architecture is a representation of any collection of collaborative organisations and sub-organisations, 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 Architecture Framework. The framework provides a set of standard building blocks that help ensure consistency both within a single architecture or across several architectures.

An Architecture Framework suitable for describing an Enterprise Architecture 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.

1.2.2 Enterprise Architecture Benefits

An Enterprise Architecture 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

(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

1.2.3 Ministry of Defence Architecture 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).

(14)

Figure 2: MODAF Viewpoints

1.2.4 Open Group Architecture Framework (TOGAF)

The Open Group Architecture Framework (TOGAF) is a framework for Enterprise Architecture 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:

Strategic

Viewpoint

Articulates the capability picture to support capability management and equipment

planning

Services

Viewpoint

Articulates the type and level of services required, how they are

assembled and interact

Acquisition

Viewpoint

Articulates programme construct, milestones, dependencies and LoD status

MODAF

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

Systems

Viewpoint

Articulates system composition and interconnectivity to support systems analysis and through

life management The How

Operational

Viewpoint

Articulates operational picture to support operational analysis,

requirement definition and solution acceptance The What

(15)

Figure 3: TOGAF Architecture Development Method (ADM)

TOGAF is published by the Open Group and consists of three main parts:

 The TOGAF Architecture Development Method (ADM), as shown in Figure 3, which describes how to develop an Enterprise Architecture 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 Architecture Assets, such as models, patterns, architecture descriptions and standards that provide the building blocks for an

Architecture. 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.

Requirements A. Architecture Vision B. Business Architecture C. Information Systems Architecture H. Architecture Change Management G. Implementation Governance F. Migration Planning E. Opportunities & Solutions D. Technology Architecture Prelim: Framework & Principles

Architecture Development Method (ADM)

Business Architecture Information & Data Architecture Technology Architecture System & Application Architecture TOGAF Architecture Framework

(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 14252 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 2008.

The C4ISR Architecture Framework was created as a successor to TAFIM which was withdrawn in 2000. The US DOD Architectural Framework (DODAF) was mainly a rename of the C4ISR Architecture 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 Architecture 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 Architecture. 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.

1985 1990 1995 2000 2005 Zachman 1987 JTA FEAF 1999 DoDAF 2004 MODAF 2005 FEAF 2005 E2AF 2005 TAFIM DoD TRM TOGAF 1995 C4ISR 1999 TOGAF 2003 (v8.1) Zachman 2005 EAP 1992 TEAF 2000 (US Treasury) Infl ue nc ed Influe_nced Influ_en ced Influenced Refere_nces References Adopted by In flu en_ce d In flu_e n c_e d Referenc es References Sup porte d by Supp orted by In flu en ce_d Influe nced Influenced Influen ced Influ_enc ed (US Industry response to DOD EA initiative) Influ en ce_d ISO/IEC 14252 2007 NAF (NATO) TOGAF 2006 (v8.1.1) TOGAF 2007/8 (v9) Influenced Influen cing Influen_cing Influencing

(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 Architecture 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 TOGAF1. This document was provided as a source reference to the study team that produced this document by D Log Info (AD Architecture). A major part of the content of this reference document consists of material extracted directly from TOGAF 8.12

Note:

1. TOGAF version 8.1.1 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 8.1.1. The differences3 are all accounted for by updates to version references throughout the TOGAF 8.1.1 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 Architecture Framework and the US DoDDOD Architecture Framework: A White Paper by Dr Dandashi (MITRE Corporation, R. Siegers (Raytheon), J. Jones (Architecting the Enterprise), T. Blevins (MITRE Corporation). Nov 2006

2_{TOGAF (The Open Group Architecture Framework) Version 8.1 “Enterprise Edition”.} 3

TOGAF Corrigendum UO65 (12.07.06 I95/GO51) details specific changes to TOGAF v8.1 that result in TOGAF v8.1.1.

(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 Architecture 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

Architecture: Data Architecture

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 Architecture 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 Architecture Description is a visualization of the relationship between these frameworks from a TOGAF-to-MODAF perspective using the TOGAF circles diagram.

(19)

Requirements A. Architecture Vision StV-1, StV-2, AV-1, OV-1 B. Business Architecture C. Information Systems Architecture H. Architecture Change Management G. Implementation Governance F. Migration Planning E. Opportunities & Solutions D. Technology Architecture Prelim: Framework & Principles StV-1, StV-2, AV-1, OV-1 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-5, OV-7, SOAV-1, SOAV-2, SOAV-4, SOAV-5, SV13, SV-4, SV-5, SV-6, SV-10, SV-11, 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 StV-3, StV-4, SOAV-3, SV-8, SV-9, TV-2, AcV-1, AcV-2 StV-5, SOAV-3, SOAV-4, SV-8, AcV-1, AcV-2 StV-1, StV-2,StV-3, StV-4, AV-1, OV-1, SOAV-2, SOAV-3, SOAV-4, AcV-1, AcV-2

StV-1, SV-9, TV-2

N/A

Figure 5: Summary of TOGAF ADM with MODAF Views as the Architecture 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.

(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,

(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.

Figure 7: Enterprise Reference Model

Capability

Strategy, Policy & Objectives

Technical Standards

P

ro

je

c

ts

R

e

q

u

ire

m

e

n

ts

Infrastructure

Data

Information

Activity

Trained

competence

Organisational

Unit

Deliver Drive G o v e rn s G o v e rn s Conducts S u p p o rt s Governs Governs Deployed on To use D e p lo y e d a t H a s P ro d u c e s / c o n s u m e s Maps to Depends on Decomposes Produces consumes

Services

Systems

Uses Creates

(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 Architecture (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.

(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

Addresses the fulfilment of capability requirements, in particular by network enabled capabilities.

8 Strategic StV-6 Operational Activity to

Capability Mapping

Describes the mapping between the capabilities required by an Enterprise and the operational activities that those capabilities support.

9 Operational OV-1a High Level Operational

Concept Graphic

High-level graphical description of business concept showing the main Operational Nodes and interesting or unique aspects of the architecture domain.

10 Operational OV-1b Operational Concept

Description

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.

(24)

Ref MODAF Viewpoint

13 Operational OV-3 Operational Information

Exchange Matrix

Describes, in detail, information exchanged between nodes and the relevant attributes of that exchange.

14 Operational OV-4 Organisational

Relationships Chart

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

Describes how an operational node or activity responds to various events by changing its state.

18 Operational OV-6c Operational Event Trace

Description

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.

(25)

Ref MODAF Viewpoint

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

specifies the communications links between systems and may also list the protocol stacks used in connections.

29 System SV-2c System Connectivity

Clusters

Defines how individual connections between systems are grouped into logical connections between parent resources.

30 System SV-3 Resource Interaction

Matrix

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

Addresses the linkage between functions described in SV-4 and Operational Activities specified in OV-5.

33 System SV-6 Systems Data Exchange

Matrix

Specifies the characteristics of the system data exchanged between systems. The focus is often on data crossing the system boundary.

34 System SV-7 Systems Performance

Parameters Matrix

Depicts the performance characteristics of a Functional Resource (system, role or capability configuration)

35 System SV-8 Capability Configuration

Management

Presents a whole lifecycle view of a resource, describing how its configuration changes over time.

36 System SV-9 Technology and Skills

Forecast

Defines the underlying current and expected supporting technologies and skills. Only those skills and technologies that can be reasonably forecast given expected improvements / trends.

37 System SV-1 0a Resource Constraints

Specification

Specifies functional and non-functional constraints on the implementation aspects of the architecture (i.e. the structural and behavioural elements of the SV viewpoint).

38 System SV-1 0b Resource State Transition

Description

Graphical method of describing a resource (or function) response to various events by changing its state.

39 System SV-1 0c Resource Event-Trace

Description

Provides a time-ordered examination of the interactions between functional resources.

(26)

Ref MODAF Viewpoint

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 Architecture.

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 www.MODAF.org.uk.

(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. SV-6 SV-9 SV-10 SV-8 OV-6 AcV-2 AcV-1 StV-4 StV-2 StV-6 StV-3 StV-5 OV-3 OV-5 OV-2 SV-3 SV-2 SV-1 OV-4 SV-4 SV-2d SV-5

Link covered by MODAF view (labelled on line)

Needline (Information) Node Activity Flow Operational Activity Organization Function Function Flow Port Connection System Port Capability StV-1 Capability Vision Capability Dependenc y Capability Cluster Project Milestone Information Element Operational Event Operational State SV-7 SV-11 OV-7 System System Connection System State System Event Entity Relationship Attribute Datamodel System Constraint Operational Constraint SV-6 Information Exchange

(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 Architecture Framework that has now evolved to become DODAF. This was the start of TOGAF that is currently at Version 8.1.1. 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 Architecture 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 Architecture Development Method (ADM) as defined in TOGAF 8.1. (Note – there is no substantive difference between TOGAF Version 8.1 and Version 8.1.1. The only difference is that Version 8.1.1 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.

(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.

1. Establish Intended Use 6. Document Results 5. Conduct Analysis 4. Capture Architecture 3. Develop Data Requirements 2. Define Architecture Scope 1 4 3 2

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.

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

AV-1 OV-1 OV-5

OV-2 OV-3 OV-4 AV-2 OV-7 OV-6a OV-6b OV-6c StV-1 StV-4 StV-5 StV-2 StV-6 StV-3 AcV-2 AcV-1 SV-1Oa SV-10b SV-10c SV-11 SV-4 SV-5 SV-1 SV-7 SV-2 SV-3 SV-6 SV-8 SV-9 TV-2 TV-1 As-Is To-Be

(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 Architecture Development Process.

 Purpose  Critical issues  Target objectives  Key tradeoffs  Probable analysis methods 2. Determine scope of architecture 2 3. Determine data required to support architecture development 3 4. Collect, organise, correlate & store architecture data 4 5. Conduct analyses in support of architecture objectives 5 6. Document results iaw Architecture Framework 6 1. Determine the intended use of the architecture  Geographical, functional

& operational bounds

 Technological bounds

 Time frames

 Architectural resource &

schedule constraints 1 Required Architectural characterisics:  Architecture 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

 Architecture products &

views (Operational, systems, technical)

 Reusable architecture data

 Analysis reports

Figure 11: DODAF Six-stage Development Process

6.4.2 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 Architecture. 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.

(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 nodal-related 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 

(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 Architecture Framework. The final step in the process involves building architecture products in accordance with templates established in the DODAF. Architecture developers will build only those products necessary to meet the intended use of the architecture (as defined in Step 1). Architecture 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)

6.4.3 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.

Figure 12: Notional Build Sequence for DODAF Views

AV-1 OV-1 OV-5

OV-2 OV-3 OV-4 AV-2 OV-7 OV-6a OV-6b OV-6c SV-1OaSV-10b SV-10c SV-11 SV-4 SV-5 SV-1 SV-7 SV-2 SV-3 SV-6 SV-8 SV-9 TV-2 TV-1 As-Is To-Be 1 2 3 4 4 3 5 5 6 6 7 8 8 8 9 9 10 11 3

(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 Architecture 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 Architecture 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: Architecture Concepts and Design Guidance for TOGAF‟s Architecture 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: Architecture Development Method (ADM);  Part III: Enterprise Continuum;

 Part IV: Resources.

The first seven releases of TOGAF ADM (1995-2001) 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 Architecture Development Method (ADM), commonly referred to as “crop circles”, along with the conventional pyramid model of the TOGAF Architecture 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 Architecture and the System & Application Architecture.

(34)

Figure 13: TOGAF

Table 3 provides an overview of each of the nine phases that guide the architect through the TOGAF ADM. Requirements A. Architecture Vision B. Business Architecture C. Information Systems Architecture H. Architecture Change Management G. Implementation Governance F. Migration Planning E. Opportunities & Solutions D. Technology Architecture Prelim: Framework & Principles Business Architecture Information & Data Architecture Technology Architecture System & Application Architecture TOGAF

(35)

Phase Name Description

Preliminary Framework & Principles

Identify additional framework(s) to use; define architecture principles to guide the architecture work

A Architecture

Vision

Define scope; create vision; identify relevant stakeholders; define business/mission requirements and constraints; obtain approvals

B Business

Architecture

Develop Baseline and Target Business Architectures, 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

C Information

Systems Architecture

Develop target architecture(s) covering either the Data or

Application Systems domains (perhaps both depending on project scope)

D Technology

Architecture

Develop Technology Architecture to form the basis of the following implementation work

E Opportunities and

Solutions

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 Implementation

Governance

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

H Architecture

Change Management

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 Architecture 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 Architecture 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.

(36)

The 6-stage DODAF Development Process (Figure 11) can be mapped to the TOGAF ADM nine-phase 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).

Requirements A. Architecture Vision B. Business Architecture C. Information Systems Architecture H. Architecture Change Management G. Implementatio n Governance F. Migration Planning E. Opportunities & Solutions D. Technology Architecture Prelim: Framework & Principles DODAF Step 2 Determine scope of architecture DODAF Step 3 Determine data required

to support architecture development

DODAF Step 5 Conduct analyses in support of architecture objectives

DODAF Step 1 Determine the intended use of the

architecture

DODAF Step 4 Collect, organise, correlate & store architecture data

DODAF Step 6 Document results iaw Architecture

Framework

(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 Architecture 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 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 Architecture 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