togaf to modaf mapping - enterprise architecture and ... · pdf file1.2.4 open group...

A part of BMT in Defence

TOGAF TO MODAF MAPPING

Reference: C370-EP-01

Version: 2.1

Date: 9th December 2010

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 need to make informed decisions.


Reference: C370-EP-01 Page i of viii

Version: 2.1

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.

CROWN COPYRIGHT 2009


Reference: C370-EP-01 Page ii of viii

Version: 2.1

CHANGE RECORD

Version Date Description of Change

2.1 09/12/2010 Updated to reflect BMT Branding

DISTRIBUTION LIST

Name Copy Number


Reference: C370-EP-01 Page iii of viii

Version: 2.1

Intentionally Blank


Reference: C370-EP-01 Page iv of viii

Version: 2.1

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

8.3 workflow modelling – conventions USED IN THIS DOCUMENT ......................................... 39


Reference: C370-EP-01 Page v of viii

Version: 2.1

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.1 Objective .................................................................................................................... 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.1 Objective .................................................................................................................... 46

8.6.2 Inputs ......................................................................................................................... 46


8.6.4 Outputs....................................................................................................................... 48

8.7 Phase c: information systems architecture ......................................................................... 49

8.7.1 Objective .................................................................................................................... 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.1 Objective .................................................................................................................... 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.9.1 Objective .................................................................................................................... 57

8.9.2 Approach .................................................................................................................... 57


Reference: C370-EP-01 Page vi of viii

Version: 2.1

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.3 Operational View Products................................................................................................. 70


Reference: C370-EP-01 Page vii of viii

Version: 2.1

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

9.7.2 Programme Timelines (AcV-2) .................................................................................... 82


Reference: C370-EP-01 Page viii of viii

Version: 2.1

Intentionally Blank


Reference: C370-EP-01 Page 9 of 84

Version: 2.1

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

Pro

jects

Re

qu

irem

ents

InfrastructureSystems

Data

Information

Activity

Trained

competence

Organisational

Unit

DeliverDrive

Go

vern

s

Go

vern

s

Conducts

Su

pp

ort

s

Governs Governs

Deployed

on

To use

De

plo

yed

at

Ha

s

Pro

du

ce

s/

co

ns

um

es

Maps

to

Depends on Decomposes

Produces/

consumes

Acquisition

Viewpoint

Articulates acquisition programme construct,

milestones, dependencies and LoDs status

Strategic

ViewpointArticulates the capability picture to support

capability management and equipment planning

Technical

ViewpointArticulates policy, standards, guidance and

constraints to specify and assure quality

expectations

Operational

ViewpointArticulates operational picture to support

operational analysis, requirements definition,

and solution acceptance

Systems

ViewpointArticulates system composition and

interconnectivity to support systems analysis

and through life management

All

ViewpointProvides summary information that specifies

the architecture product,pertinent to the entire

architecture

Services

ViewpointArticulates 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



Version: 2.1

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



Version: 2.1

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

The following diagram illustrates the relationship of MODAF Viewpoints.



Version: 2.1

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



Version: 2.1

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



Version: 2.1

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 2005200019951990

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)

Influenced

Influenced

Influenced

Influenced

References

References

Adopted by

Influenced

Influ

enced

References

References

Sup

porte

d by

Supported by

Influenced

Influenced

Influenced

Influenced

Influenced

(US Industry

response to DOD

EA initiative)Influenced

ISO/IEC

14252

2007

NAF

(NATO)

TOGAF

2006

(v8.1.1)

TOGAF

2007/8

(v9)

Influenced

Influencing

Influencing

Influencing

Figure 4: Evolutionary context for development of architecture frameworks



Version: 2.1

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 TOGAF

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

2

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 differences

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



Version: 2.1

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.



Version: 2.1

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.



Version: 2.1

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,



Version: 2.1

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

Pro

jects

Re

qu

irem

en

ts

Infrastructure

Data

Information

Activity

Trained

competence

Organisational

Unit

DeliverDrive

Go

ve

rns

Go

ve

rns

Conducts

Su

pp

ort

s

Governs Governs

Deployed

on

To use

De

plo

ye

d a

t

Ha

s

Pro

du

ce

s/

co

ns

um

es

Maps to

Depends on Decomposes

Produces consumes

Services

Systems

Uses Creates



Version: 2.1

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.



Version: 2.1

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.



Version: 2.1

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.



Version: 2.1

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.



Version: 2.1

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.



Version: 2.1

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-2AcV-1

StV-4

StV-2 StV-6

StV-3 StV-5

OV-3

OV-5OV-2

SV-3 SV-2SV-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-11OV-7

System

System Connection

System State

System Event

Entity

Relationship

Attribute

Datamodel

System

Constraint

Operational

Constraint

SV-6

Information Exchange

Figure 8: Relationships between MODAF Views



Version: 2.1

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.



Version: 2.1

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-1OV-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-2AcV-1

SV-1Oa

SV-10b

SV-10cSV-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



Version: 2.1

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.

The architecture‟s scope includes:



Version: 2.1

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

Analyses of business processes to determine possible non-materiel solutions



Version: 2.1

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-6cSV-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

1 2

3

4

4

3

5

5

6

6

7

8

8

8

9

9

10

11

3



Version: 2.1

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.



Version: 2.1

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

&


TOGAF



Version: 2.1

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.

6.6 MAPPING DODAF DEVELOPMENT PROCCES TO TOGAF ADM PHASES



Version: 2.1

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

Figure 14: Mapping of DODAF Development Process to the TOGAF ADM



Version: 2.1

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



Version: 2.1

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

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

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

8.2.3 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].

8.2.4 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



Version: 2.1

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 Architecture Building Blocks (ABBs) required to meet the business goals and objectives. The selected set of Architecture 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 Architecture Continuum – made up of Architecture Building Blocks (ABBs); and the Solutions Continuum – made up of Solution Building Blocks (SBBs).

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 Architecture Vision. In Phases B, C, and D, building blocks within the Business, Data, Applications, and Technology Architectures 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 Architecture 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 Architecture Building Blocks Specifically, Step 3 produces:

A high-level description and broad model of the target system in terms of Architecture Building Blocks;

Requirements

Architecture

Vision

Business

Architecture

Information

Systems

Architecture

Architecture

Change

Management

Implementati

on

Governance

Migration

Planning

Opportunitie

s & Solutions

Technology

Architecture

A. Architecture Vision

- High-level model of candidate building blocks

E. Opportunities and Solutions

- Building block architectures, in both ABB and SBB forms

B. Business Architecture

C. Data Architecture

D. Application Architecture

Step 1: Baseline Description

- Identify relevant Architecture Building Blocks (ABBs), drawing on the

Architecture Continuum.

Step 2: Reference Models, Viewpoints & Tools

- Select resources from Architecture Continuum

- Select viewpoints to address stakeholder concerns

- Identify appropriate tools to develop/manage products

Step 3: Target Architecture 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 Architecture

- Select standards for each ABB, reusing as much as possible from

reference models selected from the Architecture Continuum

- Fully document each ABB

- Document final mapping of the ABBs within the Architecture 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



Version: 2.1

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 Architecture 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 Architecture Building Blocks;

A fully-defined (by service) list of all the standards that make up the target architecture, and all the Architecture 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 implementation-specific 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.

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



Version: 2.1

Figure 16: Iteration between the Four Levels of Modelling

8.2.6 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 Architecture Framework and the US DOD Architecture 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

www.omg.org/techprocess/meetings/schedule/SPEM_2.0_RFP.html#Revised_Submission).

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

- ……...

http://www.omg.org/techprocess/meetings/schedule/SPEM_2.0_RFP.html#Revised_Submission).



Version: 2.1

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

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,

Activity

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

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

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



Version: 2.1

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.

8.4.4 Inputs

Inputs to this phase are:

TOGAF ADM;

MODAF v1.1;

Business Strategy, Business Principles, Business Goals, and Business Drivers (when pre-existing);

IT Governance Strategy (when pre-existing);

Architecture Principles (when pre-existing);

Principles that are being subscribed to, arising from other, federated architectures.

8.4.5 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

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



Version: 2.1

Framework & Principles

Scope the Architecture

Document Principles,

Goals & Drivers

Constraint – TOGAF ADM

Framework Definition

AV1: Architecture

Principles

AV-1, StV2, OV1:

Business Principles

StV-1, AV-1, OV-1

Business Goals

StV-1, AV-1,

Business Drivers

Business Strategy

Business Principles

Business Goals

Constraint: Other AFs

Business Drivers

IT Governance Strategy

Architecture Principles

Figure 17: ADM Workflow for the Preliminary Phase with MODAF Views

8.4.7 Outputs

The outputs of this phase are:

Framework Definition;

Architecture Principles;

Restatement of, or reference to, Business Principles, Business Goals, and Business Drivers;

Initial MODAF models StV-1, StV-2, AV-1, OV-1.

8.5 PHASE A: ARCHITECTURE VISION

8.5.1 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;



Version: 2.1

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

8.5.2 Inputs


Request for Architecture Work;

Business Strategy, Business Principles, Business Goals, and Business Drivers (when pre-existing);

Architecture Principles (when pre-existing);

Enterprise Continuum – existing architectural documentation (framework description, architectural descriptions, existing baseline descriptions, etc.).

8.5.3 Steps

Key steps in this phase include:

Project Establishment;

Business Principles, Business Goals, and Business Drivers;


Scope;

Constraints;

Stakeholders and Concerns, Business Requirements, and Architecture Vision;

Statement of Architecture Work and Approval.

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

The generic Business Scenario process is as follows:

1. Problem: Identify, document, and rank the objective that is driving the project.



Version: 2.1

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.


Obtain approval for Statement of Architecture 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 Architecture Principles and Architecture 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;

Architecture constraints;

Stakeholders and concerns;

Business Requirements;

Architecture Vision.

Complete Statement of Architecture Work and Approval process within MODAF AV-1.




Version: 2.1

Architecture Vision

Project Establishment

Statement of Archtiecture

Work & Approval

Enterprise Continuum

Refined StV-1 and OV-1:

Business Principles

Refined StV-1 & OV1

Business Goals

Refined StV-1 & OV1:

Business Drivers

OV-1, StV-2:

Architecture Vision

Approved Statement of

Architecture Work

Request for Architecture Work


Refined StV-1 & OV1:

Business Scenario

StV-2 and AV-1:


Approved Statement

of Architecture Work

Business Principles,

Goals & Drivers


Scope

Constraints

Stakeholders & Concerns, Business

Requirements & Architecture Vision

Figure 18: ADM Workflow for Phase A with MODAF Views

8.5.6 Outputs


Approved Statement of Architecture Work/Project Definition, including in particular:

Scope and constraints;

Plan for the architectural work;

Refined statements of Business Principles, Business Goals, and Strategic Drivers;

Architecture Principles (if not pre-existing);

Architecture Vision;

Business Scenario, including:



Version: 2.1

Baseline Business Architecture, Version 1;

Baseline Technology Architecture, Version 1;

Target Business Architecture, Version 1;

Target Technology Architecture, 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 Architecture Vision. In TOGAF terms, the Architecture Vision may also be referred to as a “conceptual-level architecture”.

8.6 PHASE B: BUSINESS ARCHITECTURE

8.6.1 Objective

The objectives of this TOGAF Phase are to:

Describe the Baseline Business Architecture;

Develop a target Business Architecture, 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 Architectures;

Select the relevant architecture Views that will enable the architect to demonstrate how the stakeholder concerns are addressed in the Business Architecture;

Select the relevant tools and techniques to be used in association with the elected viewpoints.

8.6.2 Inputs



Approved Statement of Architecture Work/Project Definition;

Refined statements of Business Principles, Business Goals, and Strategic Drivers;


Enterprise Continuum;

Architecture Vision/Business Scenario, including:

Baseline Business Architecture, Version 1;

Baseline Technology Architecture, Version 1;


Target Technology Architecture, Version 1.


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 Architecture context by creating OV-1 and StV-1 from the stated inputs to this Phase.



Version: 2.1

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.




Version: 2.1

Architecture Model(s)

Create Model for View

Note & Document Changes

Business Principles

Business Baseline Version 2

Technical Requirements


Application Principles

Gap Analysis Results

StV-5, StV-6: Business

Architecture Views

Assure all stakeholder concerns

are covered

Information Requirements

Perform Trade-Off Analysis

Validate Models

Develop a Business

Baseline Description

Reference Model, Viewpoints & Tools

Test Architecture Models

Approved Statement of Architecture Work

Architecture Vision

Request for Architecture

Work

Updated Statement of Architecture Work

Validated Business Principles

StV-1(Capability Vision), Target OV-1:

Business Architecture

AV2, SOAV-1: Taxonomy Description

---------------

OV-1: Use Case Model

---------------

OV-2, SOAV-2: Information & Service

Operational Node Relationships

Description

---------------

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

Updated StV-1 & OV-1:

Business Architecture Report

Business Requirements

---------------

Figure 19: ADM Workflow for Phase B with MODAF Views

8.6.4 Outputs


Statement of Architecture Work (updated if necessary);

Validated Business Principles, business goals, and strategic drivers;

Target Business Architecture, 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



Version: 2.1

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 Architecture 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 Architecture Report;

Updated business requirements;

8.7 PHASE C: INFORMATION SYSTEMS ARCHITECTURE

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



Version: 2.1

8.7.2 Approach

Development

This phase involves some combination of Data and Applications Architecture, in either order. Advocates exist for both sequences. For example, Spewak‟s Enterprise Architecture 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-the-box‟ 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 Architecture design;

Data (or Applications) Architecture design;

Applications (or Data) Architecture design;

Technology Architecture design.

Implementation:

Technology Architecture implementation;

Applications (or Data) Architecture implementation;

Data (or Applications) Architecture implementation;

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

8.7.3 Inputs


Applications Principles (if existing);

Data Principles (if existing);


Statement of Architecture Work;


Enterprise Continuum;




Version: 2.1

Target Business Architecture, Version 2 (detailed);

Relevant technical requirements that will apply to this phase;

Gap analysis (from Business Architecture);

Re-usable building blocks (from organization's Architecture Continuum, if available).

8.7.4 Steps

Detailed steps for this phase are given separately for each architecture domain:

Data Architecture.

Applications Architecture.


Data Architecture Models:

Develop the target architecture models by developing Data Architecture 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.




Version: 2.1

Information Systems

ArchitectureApplication Principles

OV7, SV11: Target Data

Architecture

SV-4, SV-10: Target

Applications Architecture

Use SV-5, SOAV-5: Gap

Analysis

Impact Analysis

StV-5,SOAV-2, Updated

Business Requirements

Data Principles

Request for

Architecture work

SV-5, SV13: Applications

Architecture Report

SOAV-1, SV-4, SV-10:


Views

Updated: Statement

of Architecture Work

Develop Apps (Services)

Architecture Models

Conduct Gap Analysis –

Use SV-5 & SOAV-5

Complete Applications

Architecture

Conduct formal check-

point review

Identify Candidate

Application Systems

Review the Qualitative

Criteria

Develop Data Architecture

Models

OV-7, SV-11: Data

Architecture Views

SV-6: Data Architecture

ReportStatement of

Architecture Work


Business Baseline

Version 2

Target Business

Architecture Version 2

Relevant Technical

Requirements

Gap Analysis

Architecture Vision

Figure 20: ADM Workflow for Phase C with MODAF Views

8.7.6 Outputs

The main outputs of this phase are:


OV-7, SV-11: Target Data Architecture;

SV-4, SV-10: Target Applications Architecture;

OV-7, SV-11: Data Architecture Views corresponding to the selected viewpoints addressing key stakeholder concerns;

SOAV-1, SV-4, SV-10: Applications Architecture Views corresponding to the selected viewpoints addressing key stakeholder concerns regarding required services;

SV-6: Data Architecture Report, summarizing what was done and the key findings;



Version: 2.1

SV-5 and SV-13: Applications Architecture Report, summarizing what was done and the key findings

SV-5 and SOAV-5: Gap analysis to show areas where the Business Architecture may need to change to cater for changes in the Data and/or Applications Architecture:

Impact Analysis;

StV-5 and SOAV-2: Updated business requirements (if appropriate).

8.8 PHASE D: TECHNOLOGY ARCHITECTURE

8.8.1 Objective

The objective of this phase is to develop a Technology Architecture that will form the basis of the following implementation work.

8.8.2 Approach

Detailed guidelines for this phase, including Inputs, Steps, and Outputs, are given under TOGAF‟s Target Technology Architecture – Detailed Description. This is the most comprehensive of the TOGAF descriptions and reflects the IT Architecture roots of the TOGAF concept.

Architecture Continuum

As part of this phase, the architecture team will need to consider what relevant Technology Architecture resources are available in the Architecture 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 Architecture Reference Models;

US Department of Defense NetCentric Operations & Warfare Reference Model;

UK MOD Architecture Framework (MODAF);

NATO C3 Technical Architecture Framework.

8.8.3 Inputs


Technology Principles (if existing);




Relevant technical requirements from previous phases



Version: 2.1

Gap analysis (from Data Architecture);

Gap analysis (from Applications Architecture);


Baseline Data Architecture, if appropriate;

Baseline Applications Architecture, if appropriate;

Target Business Architecture, Version 2 (detailed);

Re-usable building blocks (from organization's Enterprise Continuum, if available);

Target Data Architecture;

Target Applications Architecture.

8.8.4 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 Architecture, to the extent necessary to support the target Technology Architecture. 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 Architecture, 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 Architecture 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 Architecture

See detailed steps. Detailed activities for this step, including Inputs, Activities, and Outputs, are given under Target Technology Architecture – Detailed Description.



Version: 2.1


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 Architecture 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 Architecture meets business objectives;

Generate SV-3 report;

Document validated technology principles by refining SV-7 and TV-1 (if appropriate);

Develop the Target Technology Architecture 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).




Version: 2.1

Phase D – Technology

Architecture

Review Business Baseline, Data

Baseline, & Applications System Baselin

SOAV-2, SV1, SV-4, SV10:

Technology Baseline Description

Develop Technical Architecture Baseline

Identify and document candidate

Technology Building Blocks

Draft Technology Baseline Report

Develop Technical Architecture Baseline

Review Technical Architecture Baseline

Create Baseline

Select Building Blocks

Define Technology Architecture

Conduct Gap Analysis

Determine

Criteria

Confirm Business

Objectives

Select Services

Consider ViewsCreate

Architectural

Models

Technical Principles


Work

Statement of

Architecture Work

Relevant Technical

Requirements

Data Architecture – Gap

Analysis

Application Architecture –

Gap Analysis

Business Baseline

Version 2 (detailed)

Data Baseline

descriptoin

Application Baseline

description

Target Business Architecture

– Version 2 (detailed)

Target Data

Architecture

Target Application

Architecture

Architecture VisionUpdated Statement of

Architecture Work

SV-7, TV1: New

Technology Principles

---------------

SV-5: Confirm functionality

matches business need

StV-5, SV-1, SV-2, SV-4(refined),

SV-10(refined): Target Technology

Architecture Version 1

SV-3: Technology

Architecture Report

SV-7, TV1: Validated

Technology Principles

StV-3, StV-4, SV-5 (refined)

& SV-13: Technology

Deployment Plan

Figure 21: ADM Workflow for Phase D with MODAF Views

8.8.6 Outputs



Baseline Technology Architecture: SOAV-2, SV-1, SV-4, SV-1 0.

Validated Technology Principles, or new Technology Principles: SV-7, TV-1.



Version: 2.1

Technology Architecture Report: SV-3 (summarizing what was done and the key findings);

Target Technology Architecture, Version 1;

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

8.9.1 Objective


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 sub-options 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).

8.9.2 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 organization-specific 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.



Version: 2.1

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.

8.9.3 Inputs




Target Business Architecture;

Target Data Architecture;

Target Applications Architecture;

Target Technology Architecture;

Re-usable Architecture Building Blocks (from organization's Enterprise Continuum, if available);

Product information.

8.9.4 Steps


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;


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);



Version: 2.1

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


Opportunities &

Solutions

Identify Key Business Drivers

Identify Major

Work Packages

Request for

Architecture Work

StV-4, AcV-1, SV-9, TV-2, :High

Level Implementation PlanStatement of

Architecture Work

Baseline Architecture

Version 2

AcV-2, Project List: Impact

Analysis

StV3, SOAV-3, SV-8: Implementation

& Migration Strategy

Review Gap Analysis

Brainstorm Technical

Requirements

Brainstorm co-existence &

interoperability requirements

Perform Architecture

Assessment & Gap Analysis

Project List:

Impact Analysis

Technology Architecture

Figure 22: ADM Workflow for Phase E with MODAF Views

8.9.6 Outputs


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.

8.10 PHASE F: MIGRATION PLANNING

8.10.1 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



Version: 2.1

various migration projects. The prioritized list of projects will go on to form the basis of the detailed Implementation and Migration Plan.

8.10.2 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).



Version: 2.1

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 Architecture. Using the CRUD (Create/Read/Update/Delete) matrix developed as part of the Data Architecture, 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 Architecture with only a single time horizon.

8.10.3 Inputs





Target Technology Architecture;

Impact Analysis – acquisition programme and project list;

8.10.4 Steps


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;



Version: 2.1

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


Migration Planning

Prioritize Projects

Document the

Migration Plan

Request for

Architecture Work

AcV-1, AcV-2 Programme

Delivery Plan: Impact Analysis

SV-8 Detailed Implementation &

Migration Plan: Impact Analysis

Statement of

Architecture Work

Baseline Architecture

Version 2

SOAV-3, SOAV-4 Service

Delivery Plan: Impact Analysis

StV-5 Capability Delivery

Plan: Impact Analysis

Estimate Resource

Requirements

Perform Cost/Benefit

Assessment

Perform Risk

Assessment

Generate Implementation

Roadmap

Project List:

Impact Analysis

Technology Architecture

Figure 23: ADM Workflow for Phase F with MODAF Views

8.10.6 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 Architecture Implementation Contract, if appropriate).

8.11 PHASE G: IMPLEMENTATION GOVERNANCE

8.11.1 Objective



Version: 2.1


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.

8.11.2 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 organizational-specific development process, where the actual development happens.

This phase establishes the connection between architecture and implementation organization, through the Architecture 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 Architecture Governance, which is discussed in TOGAF Part IV, Architecture 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, Architecture Compliance.

8.11.3 Inputs




Re-usable Solutions Building Blocks (from organization's Solutions Continuum, if available);

Impact Analysis – Detailed Implementation and Migration Plan (including Architecture Implementation Contract, if appropriate).

8.11.4 Steps


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;



Version: 2.1

Document timeline requirements from roadmap in Impact Analysis.

Document Architecture Contract - Obtain signature from all developing organizations and sponsoring organization;

Ongoing implementation governance and architecture compliance review.


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


Implementation

Governance

Project Recommendation

Formulation

Request for

Architecture Work

Architecture Contract

based on full range of

Refined Outputs (below)

Detailed Implementation &

Migration Plan: Impact

Analysis

Refined AV-1:

Implementation

Recommendations &

Impact Analysis

Document Architecture

Contract

Ongoing Implementation

Governance

Statement of

Architecture Work

Refined OV-1: Architecture

compliant Implemented

System

Refined StV-1, StV-2, StV-3, StV4:

Strategic Implementation

Roadmap

Refined AV-1, AV-2:

Architecture 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

8.11.6 Outputs


Impact Analysis: AV-1 (refined) providing Implementation recommendations;



Version: 2.1

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

8.12 PHASE H: ARCHITECTURE CHANGE MANAGEMENT

8.12.1 Objective

The objective of this phase is to establish an Architecture 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.

8.12.2 Approach

The goal of an Architecture 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 Architecture 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 Architecture Change Management process is very closely related to the architecture governance processes of the enterprise, and to the management of the Architecture 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 Architecture Governance documents (e.g. Request for Architecture Work) and their relevance to the Architecture 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.

8.12.3 Inputs




Version: 2.1

Request for Architecture Change – technology changes:

New technology reports;

Asset management cost reduction initiatives;

Technology withdrawal reports;

Standards initiatives.

Request for Architecture Change – business changes:

Business developments;

Business exceptions;

Business innovations;

Business technology innovations;

Strategic change developments;

8.12.4 Steps


Ongoing monitoring of technology changes;

Ongoing monitoring of business changes;

Assessment of changes and development of position to act;

Meeting of Architecture Board (or other governing council) to decide on handling changes (technology and business).


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.




Version: 2.1

Architecture Change Management

Ongoing Monigtoring of

Technology Changes


Change – Technology Changes

New Request for

Architecture Work


Change – Business Changes

StV-1, SV-9, TV-2:

Architecture Updates

Ongoing Monitoring of

Business Changes

Assessment of Changes

Meeting of Architecture Board

Figure 25: ADM Workflow for Phase H with MODAF Views

8.12.6 Outputs


StV-1: The overall business context for MODAF products

SV-9, TV-2: Architecture updates;

Changes to Architecture Framework and Principles;

New Request for Architecture Work (to move to another cycle).



Version: 2.1

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

9.1.1 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 Architectures. AV-1 includes assumptions, constraints, and limitations that may affect high- level decisions relating to the Architecture. AV-1 contains sufficient textual information to enable a reader to select one Architecture from among many to read in more detail. AV-1 serves two additional purposes. In the initial phases of Architecture development, it serves as a planning guide. Upon completion of Architecture, AV-1 provides summary textual information about the Architecture.

TOGAF ADM Relationships: TOGAF ADM elements supporting the development of AV-1 include Architecture Vision, IT Governance Strategy, Architecture Principles, and Impact Analysis. AV-1 is initially populated during TOGAF‟s Preliminary Phase and Phase A: Architecture Vision. It is updated to reflect results during TOGAF Phase G: Implementation Governance.

9.1.2 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 Architecture and evolves across all remaining phases of TOGAF ADM.



Version: 2.1

9.2 CAPABILITY VIEW PRODUCTS

9.2.1 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 Architecture. It also provides a high-level scope for the Architecture 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: Architecture Vision and is further refined as part of Phase B: Business Architecture. Because of its strategic nature it is also relevant to Phase G: Implementation Governance and to Phase H: Architecture Change Management.

9.2.2 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: Architecture Vision (Scoping the Architecture) and again early in Phase B: Business Architecture. 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).

9.2.3 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 Architecture and Phase G: Implementation Governance.

9.2.4 Capability Dependencies (StV-4)



Version: 2.1

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 Architecture. 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 Architecture and Phase G: Implementation Governance.

9.2.5 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 Architecture, Phase C: Information Systems Architecture (Applications) and Phase D: Technology Architecture. Given the linkage to options assessment and implementation, StV-5 is also likely to be refined during Phase F: Migration Planning.

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

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);



Version: 2.1

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

9.3.1 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 Architecture Vision, IT Governance Strategy, Architecture 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: Architecture Vision (Scoping the Architecture) and again early in Phase B: Business Architecture. It is also updated to reflect results during TOGAF Phase G: Implementation Governance.

9.3.1.1 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 Architecture and its environment, and between the Architecture and external systems. A textual description accompanying the graphic is crucial. Graphics alone are not sufficient for capturing the necessary Architecture data. The purpose of OV-1a is to provide a quick, high-level description of what the Architecture 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.

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



Version: 2.1

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.

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

9.3.2 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 Architecture Elements of: Business Architecture, Business Baseline, Business View and Business Data.

9.3.3 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 Architecture 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 Architecture 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 Architecture (Business Modelling), where information exchanges are discussed within the context of what information is required to enable the activity model to be effective.

9.3.4 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 Architecture. An OV-4 Product clarifies the various relationships that can exist between organisations and sub-organisations within the Architecture and between internal and external organisations. An OV-4 Product illustrates the relationships between organisations in an Architecture. There can be many types of inter-organisational 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 Architecture. OV-4 maps directly to the TOGAF Business Architecture activities. TOGAF ADM requires the identification of the organisation structure and the business locations‟ relationships to organisational units.



Version: 2.1

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

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

OV Products discussed in previous sections model the static structure of the Architecture elements and their relationships. Many of the critical characteristics of Architecture are only discovered when the dynamic behaviour of these elements is modelled to incorporate sequencing and timing aspects of the Architecture. 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 Architecture‟s OV to adequately describe the dynamic behaviour and timing performance characteristics of an Architecture, 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).

9.3.6.1 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 Architecture. 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 Architecture 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 Architecture, as an annotation of that activity information.

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

9.3.6.3 Operational Event Trace Description (OV-6c)



Version: 2.1

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

9.3.7 Information Model (OV-7)

Product Description: The Information Model (OV-7) describes the structure of an Architecture domain‟s system data types and the structural business process rules (defined in the Architecture‟s Operational Viewpoint) that govern the system data. It provides a definition of Architecture 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 Architectures, 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 Architecture [Data Architecture].

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



Version: 2.1

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.

9.4.1 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 Architecture 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 Architecture (Application Architecture).

9.4.2 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 Architecture, Phase C: Information System Architecture (both Application and Information Architectures), Phase D: Technology Architecture and Phase G: Implementation Governance.

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

9.4.4 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 Architecture, Phase C: Information Systems Architecture and Phase G: Implementation Governance.

9.4.5 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 Architecture) with system functionality created in the Application Architecture. Therefore SOAV-5 is developed as part of TOGAF Phase B: Business Architecture and Phase C: Information Systems Architecture (Applications).

9.4.6 Service Provision Description (SV-13)



Version: 2.1

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 Architecture, Phase C: Information Systems Architecture and Phase D: Technology Architecture.

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

9.5.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 Architecture [Developing Architecture Views: Systems Engineering View].

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



Version: 2.1

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 Architecture [Developing Architecture Views: Communications Engineering View].

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

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



Version: 2.1

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 Architecture, 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 fault-tolerance 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 Architecture 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 Architecture [Developing Architecture Views: System Engineering View].

9.5.5 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 Architecture [Applications Architecture] and Phase D: Technology Architecture [Developing Architecture Views: Data Flow View] SV-4 is used to model supported system inter-dependencies, software services, applications, their structure and their dependencies.

9.5.6 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 Architecture and the set of system functions applicable to that Architecture. 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 Architecture.

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 Architecture) with Phases C (Information Systems Architecture) and D (Technology Architecture).



Version: 2.1

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

9.5.8 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 Architecture [Developing Architecture Views, System Engineering View].

9.5.9 Capability Configuration Management (SV-8)

Product Description: Capability Configuration Management (SV-8) captures evolution plans that describe how the resource, or the Architecture 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 Architecture and its resources are expected to evolve over time. In this manner, the Product can be used as an Architecture 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.

9.5.10 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 Architecture and its existing planned systems. The focus will be on the supporting technologies that may most affect the capabilities of the Architecture 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: Architecture Change Management.

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



Version: 2.1

9.5.11.1 Overview of Resource Sequence and Timing Descriptions (SV-10a, 10b, & 10c)

Many of the critical characteristics of an Architecture are only discovered when an Architecture‟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 Architecture description, because it is how the Architecture 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.

9.5.11.2 Resource Constraints Specification (SV-10a)

Product Description: Resource Constraints Specification (SV-10a) are constraints on an Architecture, 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 Architecture 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 Architecture, but SV-10a can be utilised as a supporting model within TOGAF ADM Phase C: Information Systems Architecture [Applications Architecture] and Phase D: Technology Architecture [Developing Architecture Views: Systems Engineering View].

9.5.11.3 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 Architecture 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 Architectures [Applications Architecture] and Phase D: Technology Architecture [Developing Architecture Views: Systems Engineering View].

9.5.11.4 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



Version: 2.1

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 Architectures [Applications Architecture and Phase D: Technology Architecture [Developing Architecture Views: Systems Engineering Views].

9.5.12 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 Architecture 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 Architecture [Data Architecture]

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.

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



Version: 2.1

TOGAF ADM Relationships: TV-1 can be utilised as a supporting model within TOGAF ADM Phase D: Technology Architecture [Developing Architecture Views: Systems Engineering View].

9.6.2 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 Architecture 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: Architecture 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).

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

9.7.2 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



Version: 2.1

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.



Version: 2.1

End of document