NATO Architecture Framework Version 3 ANNEX A Architecture ... · NATO/EAPC UNCLASSIFIED APPENDIX 8...

NATO/EAPC UNCLASSIFIED

APPENDIX 8 TO ANNEX 3 TO

AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page i

NATO Architecture Framework

Version 3

ANNEX A Architecture Frameworks



AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page ii

This page is left blank intentionally.



AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page iii

Conditions of Release

With reference to NATO Documents C-M(2002)49 and AC/322-D/1, this document is released to all parties concerned at the direction of the NATO Consultation, Command and Control Board (NC3B) subject to the following conditions:

1. The recipient party agrees to use its best endeavours to ensure that the information herein disclosed, whether or not it bears a security classification, is not dealt with in any manner (a) contrary to the intent of the provisions of the Charter of the NATO C3 Organisation, or (b) prejudicial to the rights of the owner thereof to obtain patent, copyright or other likely statutory protection thereof.

2. If the technical information was originally released to NATO by a NATO or Partner Government subject to restrictions clearly marked on this document, the recipient party agrees to abide by the terms of the restrictions so imposed by the releasing Government.

3. This material may be reproduced free of charge in any format or medium provided it is reproduced accurately and not used in a misleading context. Where this material is being republished or copied to others, the source of the material must be identified and the copyright status acknowledged. For further information, contact NATO at http://www.nato.int.



AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page iv




AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page v

Reader’s Guide

Background

An architecture is the fundamental organisation of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. An Architecture can be captured in a formal description of an instance, or configuration of people, processes, systems and organisations, connected by their inter-relationships. An architecture description includes views showing various aspects of the architecture. The views include architectural elements and the relations between elements as governed by a Metamodel.

Architectures can be represented by models. These support operational processes by providing an explicit representation of the operational domain that can be used in analysis, for articulation of issues and requirements, as support to planning, and as a means of solution design and validation, amongst other things. Architectures can be developed for the smallest subsystem up to and culminating in an architecture that covers the whole enterprise.

The role of an enterprise architecture is to provide decision support, in the context of the enterprise strategy, for the use of resources (including processes and procedures) in the enterprise. In other words, the architecture is responsible for defining how resources will be used to support enterprise strategy and benefit the NATO goals and objectives. Enterprise architecture touches every part of the organisation.

Architectures are to be used as analysis tools to develop new capabilities, structure organisations and to optimize processes and spending. There is an increase in the need for international coalition operations (NATO Response Force) and a growing need to deliver end-to-end capability, whilst delivering more for less and ensuring interoperability. NATO Network Enabled Capability (NNEC) is a key part of meeting this changing need, and enables us to federate systems, sensors, effectors and hence improve military effectiveness.

There is a need for a more structured approach to manage the complexity whilst balancing all appropriate user perspectives. Architectural frameworks support this goal, and the most mature and widely adopted architectural frameworks in the defence sector are the US DoD Architecture Framework (DoDAF), and the UK MOD Architecture Framework (MODAF). NATO is using its own NATO Architecture Framework (NAF) to support this goal. The previous version of NAF was tightly coupled to DoDAF. The current version has been updated in several areas, and has incorporated not only US and UK experiences, but also views and experiences from other nations, from industry and from academia.



AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page vi

New features include:

initial support for NNEC architectures

support to the NATO capability development process;

support to programme management;

integration of Service-Oriented Architecture (SOA) concepts;

support to spectrum and bandwidth planning;

provision and integration of the NATO Architecture Framework Metamodel (NMM) and the NATO Architecture Repository (NAR);

a running example.

The NAF is not an architecture itself, but it provides the rules, guidance, and product descriptions for developing, presenting and communicating architectures. The NAF is also the common denominator for understanding, comparing, and integrating architectures. The application of the framework will enable architectures to contribute most effectively to the acquisition and fielding of cost-effective and interoperable military capabilities. The framework ensures that the architectures developed by NATO and the Nations can be compared and related across NATO and National boundaries. NATO common funded programmes are to comply with the NAF to promote systems interoperability.

NAF Document Suite Structure

The NATO Architecture Framework is composed of ten volumes, covering NAF-chapters 1 through 7, and NAF-annexes A through C (see Figure A-1). Each NAF-chapter and each NAF-annex is contained within a separate volume, and each volume is published as one electronic file. Each electronic file is intended to be readable as a stand-alone document. For that purpose, each volume contains common introductory sections that provide enough context to understand the contents of the NAF as a whole, as well as that particular volume. This approach enables us to disseminate concise portions of information to the intended audience. The NAF will also be published in HTML format.

Executive Summary In addition to the ten volumes, an executive summary exists. This is a concise summary of NAF version 3. The document is intended to give the reader a quick — but nonetheless comprehensive — understanding of NAF, its use and benefits. The summary is sufficient to understand why the NAF is relevant and where and how the NAF can be used. The details can then be found in the NAF-volumes themselves.



AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page vii

Figure A-1, NAF v3 Document Suite Structure

CHAPTER 1 Introduction to NATO Architecture Framework NAF-chapter 1 is the introduction to the NAF. This chapter essentially presents the business case for NATO architectures. Chapter 1 defines what an architecture is, what the benefits are, and why architectures are relevant to NATO in the light of current and future developments, such as NNEC, NRF and Comprehensive Approach. This chapter contains the following paragraphs:

1.1 Introduction to Chapter 1

1.2 What is an Enterprise Architecture?

1.3 Purpose and Scope of the NAF

1.4 Imperative Documents

1.5 Why use NAF?

1.6 The NATO Architecture Framework (NAF)

1.7 New Features and Important Changes in NAF

1.8 Architecture Tools

1.9 Types of NATO Architectures

1.10 NATO Architecture Views

1.11 Management of NAF and architectures

1.12 Guidelines for Architects



AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page viii

CHAPTER 2 Architecture Stakeholders NAF-chapter 2 addresses the stakeholders and communities of interest that may benefit from the use of the NAF. It is one of the principles of this version of the NAF to align the architecture framework with the objectives and interests of those who use it, providing for as much added value as possible, without being sidetracked by issues that do not directly contribute to the stakeholder’s cause. This chapter contains the following paragraphs:


2.2 Identification and Description of Stakeholders and Communities of Interest (CoIs)

2.3 Requirements Analysis of Communities of Interest (CoIs)

CHAPTER 3 NNEC Architecture Concepts and Elements NAF-chapter 3 provides a description of the NNEC architecture concepts and elements that are essential for developing a complete and coherent architecture, capable of specifying seamlessly interoperable network enabled systems. This chapter contains the following paragraphs:


3.2 NNEC Architecture Concepts

3.3 NNEC Architecture Elements and Descriptions

CHAPTER 4 Architecture Views and Subviews Chapter 4 defines a toolbox of architecture views and subviews, where each subview comprises of specific diagrams and specifications, intended to support a specific purpose, and intended to be communicated to specific stakeholders and specific Communities of Interest. This chapter contains the following paragraphs:


4.2 NATO Architecture Views

4.3 NAV, NATO All View

4.4 NCV, NATO Capability View

4.5 NOV, NATO Operational View

4.6 NSOV, NATO Service-Oriented View

4.7 NSV, NATO Systems View

4.8 NTV, NATO Technical View

4.9 NPV, NATO Programme View

4.A Mapping Subviews to Communities of Interest

4.B Running Example

4.C Mapping Subviews to NNEC Elements



AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page ix

CHAPTER 5 NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES) NAF-chapter 5 contains the NAF Metamodel (NMM). In essence, an architecture is delivered as a set of design models, specifications and guidelines, which are indispensable for subsequent system development within NATO’s highly complex, dispersed and heterogeneous automated information system. In practice, the result of an architecture effort is an architecture core data repository. The NAF Metamodel is the engine of this repository. The NAF Metamodel is also intended to facilitate exchange of architecture design information. This chapter contains the following paragraphs:


5.2 NATO Architecture Framework Metamodel (NMM)

5.3 NATO Architecture Data Exchange Specification (ADES)

CHAPTER 6 Management of Architectures in NATO NAF-chapter 6 provides guidelines on how to manage NATO-architectures. Merely developing an architecture does not provide or ensure the full benefits. Architectures must also be maintained, communicated, and enforced. These aspects of the architecture life-cycle are the subject of NAF-chapter 6. This chapter contains the following paragraphs:


6.2 The Management and Use of NAF v3

6.A General Guidelines for the Management of NAF v3 Architectures in Nations

6.B NAF v3 Request For Change Proposal (RFCP) Procedure

6.C Standardization of the NATO Architecture Framework Metamodel (NMM) and the Architecture Information Exchange Mechanism (ADEM)

CHAPTER 7 Architecture Definitions, Terminology and Ontology NAF-chapter 7 contains a comprehensive glossary of terms. All essential terms used in the NAF are defined in a precise and unambiguous way to optimize consistency, and increase readability of each NAF-volume, and the entire framework, across the different volumes. This chapter contains the following paragraphs:


7.2 Definitions

7.3 Acronyms and Abbreviations

7.4 Taxonomy (not yet included in NAF version 3)

7.5 Ontology (not yet included in NAF version 3)



AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page x

ANNEX A Architecture Frameworks NAF-annex A presents an overview of some architecture frameworks. This chapter presents brief introductions to other architecture frameworks for ease of reference and for comparison. This chapter contains the following paragraphs:

A.1 Introduction to Annex A

A.2 The Open Group Architecture Framework (TOGAF)

A.3 Gartner’s Enterprise Architecture Framework

A.4 Zachman Framework

A.5 Department of Defense Architecture Framework (DoDAF)

A.6 Ministry of Defence Architecture Framework (MODAF)

A.7 AGATE v3

A.8 Defence Architecture Framework (DAF)

A.9 Model-based Architecture for Command and Control Information Systems (MACCIS)

ANNEX B Architecture Methodologies NAF-annex B contains an overview of some architecture methodologies. This chapter presents brief introductions to other architecture methodologies for ease of reference and for comparison. NC3A’s Architecture Engineering Methodology (AEM) is included in full. This particular methodology serves as information for those Partner- and NATO-Nations that want to know more about NATO architecture projects where NC3A is host Nation or provider, and where the AEM is used. This chapter contains the following paragraphs:

B.1 Introduction to Annex B

B.2 TOGAF ADM

B.3 Boeing/Openwings

B.4 META Group and Gartner process model

B.5 DoDAF’s 6 step model

B.6 NC3A/AEM

ANNEX C Transition Guidance NAF v2 to NAF v3 NAF-annex C provides for guidance on how to migrate existing architectures, based upon NAF version 2, to architectures that are compliant with NAF version 3. This chapter contains the following paragraphs:

C.1 Introduction to Annex C

C.2 Considering Transition Feasibility

C.3 Implementation of Transition

C.4 View, Subview and Metamodel Transition



AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page xi

Intended Audience

This document is intended for all people who want to have a brief oversight of architecture frameworks.

Structure of sections in this chapter

Section A.1 contains an introduction to this annex followed by separate sections describing some well known frameworks as follows:

Section A.2 The Open Group Architecture Framework (TOGAF)

Section A.3 Gartner’s Enterprise Architecture Framework

Section A.4 The Zachman Framework

Section A.5 The Department of Defense Architecture Framework (DoDAF)

Section A.6 The Ministry of Defence Architecture Framework (MODAF)

Section A.7 AGATE v3

Section A.8 The Defence Architecture Framework (DAF)

Section A.9 Model-based Architecture for Command and Control Information Systems (MACCIS)



AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page xii




AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page xiii

Table of Contents

ANNEX A Architecture Frameworks ........................................................................ i

Conditions of Release ............................................................................................. iii

Reader’s Guide ........................................................................................................ v

Background .......................................................................................................... v

NAF Document Suite Structure ........................................................................... vi

Intended Audience .............................................................................................. xi

Structure of sections in this chapter .................................................................... xi

Table of Contents ..................................................................................................xiii

A.1 Introduction to ANNEX A ....................................................................... 1

A.1.1 Objectives .............................................................................................. 1

A.1.2 Scope ..................................................................................................... 1

A.1.3 Approach ............................................................................................... 1

A.2 The Open Group Architecture Framework (TOGAF) ............................. 3

A.3 Gartner’s Enterprise Architecture Framework ........................................ 5

A.4 Zachman Framework ............................................................................. 9

A.5 Department of Defense Architecture Framework (DoDAF) .................. 11

A.6 Ministry of Defence Architecture Framework (MODAF) ....................... 13

A.7 AGATE v3 ............................................................................................ 15

A.8 Defence Architecture Framework (DAF) .............................................. 19

A.8.1 The Defence Architecture Framework explained ................................. 19

A.8.1.1 Framework Elements.......................................................................... 21

A.8.1.2 The Influences on the Architecture ..................................................... 21

A.9 Model-based Architecture for Command and Control Information Systems (MACCIS) ................................................................................................ 23



AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page xiv




AC/322(SC/1-WG/1)N(2007)0004


NATO Architecture Framework v3, ANNEX A – Page 1

A.1 Introduction to ANNEX A

What is an Architecture Framework? An Architecture Framework (AF) defines the standard set of key business and technical information that provides for the development of architectures. An architecture developed in line with that set of information is then compliant to that architecture framework. It is also then interoperable with other architectures developed in line with the same architecture framework, ensuring that the overall Enterprise Architecture (EA) is coherent.

An architecture framework specifies an organising structure for architecture information and provides a common tool for describing enterprises through complex models. To manage this complexity, an AF defines a standard set of model categories which each have a specific purpose and are often categorized in aspects or view groups.

An AF defines a standard set of business and technical information about an enterprise. The purpose of the AF may be to identify elements of this information that will be mandatory to produce within the enterprise or to act as a guide to which types of information may be of most value in analyzing aspects of the enterprise. An AF usually describes a standard set of representations on the enterprise.

A.1.1 Objectives

The objective is to give oversight over the most known and used architecture frameworks, which have been used by organisations, industry and governments to describe their enterprises.

A.1.2 Scope

The most known and used architecture frameworks will be described in a condensed form in order to give an insight and background into architecting concepts and usage.

A.1.3 Approach

The information in this annex is captured from original documents or web-based information and reflects the respective copyright owners’ view of characteristics or capabilities of their frameworks.



AC/322(SC/1-WG/1)N(2007)0004






AC/322(SC/1-WG/1)N(2007)0004



A.2 The Open Group Architecture Framework (TOGAF)

TOGAF recognizes four kinds of ’architecture’ that are commonly accepted as subsets of an overall Enterprise Architecture (EA):

Business Architecture;

Data Architecture;

Application Architecture; and

Technology Architecture.

The combination of Data Architecture and Application Architecture is also referred to as the Information System Architecture.

TOGAF was originally designed to support the last of these - the Technology Architecture. Over its years of evolution, however, it has acquired many of the facets of a framework and method for Enterprise Architecture. As of TOGAF Version 8, these different facets have been integrated, and TOGAF has undergone a major redevelopment, with the result that it is now a fully-fledged enterprise architecture framework.

Two of the key elements of any enterprise architecture framework are:

a definition of the deliverables that the architecting activity should produce; and

a description of the method by which this should be done.

With some exceptions, the majority of enterprise architecture frameworks focus on the first of these - the specific set of deliverables - and are relatively silent about the methods to be used to generate them (intentionally so, in some cases.)

Because TOGAF is a generic framework, as mentioned above, and intended to be used in a wide variety of environments, it does not prescribe a specific set of deliverables; rather it talks in general terms about the types of deliverable that need to be produced, and focuses instead on the methods by which these should be developed.

As a result, TOGAF may be used either in its own right, with the generic deliverables that it describes; or else these deliverables may be replaced by a more specific set, defined in any other framework that the user architect considers relevant.

In the latter case, the user architect will adapt and build on the TOGAF Architecture Development Method (ADM) in order to define a tailored method and process for developing these more specific deliverables. Refer to Annex B for more information on TOGAF ADM.

As a generic framework and method for Enterprise Architecture, TOGAF also complements other frameworks that are aimed at specific vertical business domains,



AC/322(SC/1-WG/1)N(2007)0004



specific horizontal technology areas such as Security or Manageability, or specific application areas such as e-Commerce. The concept of leveraging other relevant architectural assets in this way is known within TOGAF as the Enterprise Architecture Continuum.

The Role of TOGAF

TOGAF in its Enterprise edition remains what it has always been, namely an architectural framework - a set of methods and tools for developing a broad range of different IT architectures. The key to TOGAF remains a reliable, practical method - the TOGAF ADM)- for defining business needs and developing an architecture that meets those needs, utilizing the elements of TOGAF and other architectural assets available to the organisation.

The TOGAF ADM 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. That may be the set of deliverables described in TOGAF itself; or it may be the set associated with another framework, such as Zachman Framework, FEAF, etc. TOGAF describes an example taxonomy of the kinds of views that an architect might consider developing, and why; and it provides guidelines for making the choice, and for developing particular views, if chosen.

With the migration of TOGAF to an enterprise architecture framework, this flexibility becomes even more important. TOGAF is not intended to compete with these other frameworks: rather, it is intended to perform a unique role, in distilling what these other frameworks have to offer, and providing a generic Architecture Development Method that can be adapted for use with any of these other frameworks.



AC/322(SC/1-WG/1)N(2007)0004



A.3 Gartner’s Enterprise Architecture Framework

Enterprise architecture is an iterative process that produces four major deliverables:

a future-state architecture that supports the requirements of the business strategy and external environmental factors;

documentation of the current-state architecture (to the minimal level of detail required);

a gap analysis that identifies the shortfalls of the current state in terms of its ability to support the strategies of the enterprise;

a ‘road map’ defining the steps that should be taken to transform the current state into the future state.

Control of the execution of the road map, decisions with respect to the allocation of funds and resources, are not made within the architecture itself, but are the function of other management disciplines that are related to, but not part of, the architecture.

The development of the business context begins during the initial ‘organise the architecture effort’ step, since business strategy analysis is a key component of the Enterprise Architecture (EA) value proposition, which should be articulated as early as possible. Further analysis and the expression of the business strategy in terms of foundational enterprise architecture principles are done as the business context is developed.

The future-state vision is usually expressed in three types of artefacts: the requirements, which define what the architecture is trying to achieve; the principles, which guide decision making; and finally the models, which illustrate what the future vision of the architecture looks like. The business context is a critical component of the architecture that is required before the future-state architecture vision can be developed. It provides the necessary insight into the business strategy that architecture requires in order to be relevant to and supportive of the needs of the business. In addition, the business context provides the foundation for subsequent architectural work, so it is helpful if the business context can be expressed in the same type of artefacts - requirements, principles and models.

Another way to look at this is by levels of abstraction. Enterprise architecture (EA) is a process of progressive decomposition. You start with a very generalized vision and develop increasing levels of detail as you get further into the process. Typically, EA efforts encompass at least three levels of abstraction:

a conceptual level, where the general concepts of the architecture are laid out;

a logical level, where more specific architectural components are identified;

an implementation level, where the specific tools, products and implementation standards are determined.



AC/322(SC/1-WG/1)N(2007)0004



The business context can be thought of as a ‘contextual’ level of abstraction, where the highest-level requirements and business drivers are articulated to provide a foundation for a business-aligned architecture.

As we indicated previously, the enterprise architecture is overlaid by the business context, which is derived from the business strategy and the external factors that affect the enterprise. Within the EA, Gartner has adopted an ‘aspect-oriented’ approach, similar to the approach espoused in the IEEE's ‘Recommended Practice for Architectural Description of Software-Intensive Systems’ (IEEE 1471-2000), which proposes that the architecture is a collection of ‘viewpoints’ - architectural descriptions that satisfy the perspectives of each individual stakeholder.

In Gartner's approach, an EA has a minimum of three viewpoints:

a business viewpoint, which is concerned with functional, process and organisational views of the enterprise;

an information viewpoint, which is concerned with the information required to run the enterprise, the logic that manipulates the information and the mechanisms that allow for integration of that information across diverse processes;

a technology viewpoint, which is concerned with the infrastructural components, both hardware and software, that support the enterprise.

These viewpoints are derived from the business context and should demonstrate clear traceability of architectural decisions to the elements of the business strategy.

The crux of the framework is the ‘solution architecture,’ which represents the intersection of the business, information and technology viewpoints. It is here that we find the architectural guidance required to build solutions, where the relationships between components in different viewpoints are needed (for example, application partition model, which shows how the business functions of the enterprise are supported by the application portfolio).

This is another view of Gartner's EA framework, showing the different levels of abstraction. The business context is a foundation for the work in each of the architectural viewpoints; business, information and technology - as well as at the intersection of those three viewpoints, where the solution architecture is developed. Following the development of the business context, conceptual, logical and implementation levels of detail can be developed in any or all of the viewpoints as required.



AC/322(SC/1-WG/1)N(2007)0004



Figure A-2, Gartner's Enterprise Architecture Framework

In a business-driven architecture, the business context provides the foundational assumptions for the entire future-state architecture. The strategic requirements of the enterprise are analyzed, and a set of architecture principles is articulated. These principles are derived from the elements of the business strategy and analysis of environmental trends so that there is a direct linkage between the architectural decisions and the business imperatives they support. These architecture principles will be further decomposed into the conceptual, logical and implementation-level principles that guide architectural and design decisions as the architecture moves farther away from strategy and closer to implementation. An additional element of the business context is an analysis of the business functions that the enterprise requires in order to fulfil the business strategy. This analysis includes an articulation of the high-level requirements of each business function. As these requirements are articulated, it is possible to identify the information and technology services that support the business functions and the business processes that discharge the business strategy.



AC/322(SC/1-WG/1)N(2007)0004






AC/322(SC/1-WG/1)N(2007)0004



A.4 Zachman Framework

The Zachman framework is a logical structure intended to provide a comprehensive representation of an information technology enterprise. It allows for multiple perspectives and categorization of business artefacts. The brainchild of John Zachman who conceived the idea in 1987, the full technical name is Zachman Framework for Enterprise Architecture and Information Systems Architecture.

The Zachman framework gathers and refines principles from older methods. It has a structure (or framework) independent of the tools and methods used in any particular IT business. The framework defines how perspectives are related according to certain rules or abstractions. A framework takes the form of a 36-cell table with six rows (scope, business model, system model, technology model, components, and working system) and six columns (who, what, when, where, why, and how).

The Zachman framework is seen by some business managers as an ideal set of rules for the management of complex and evolving IT enterprises.

Figure A-3, Zachman framework



AC/322(SC/1-WG/1)N(2007)0004






AC/322(SC/1-WG/1)N(2007)0004



A.5 Department of Defense Architecture Framework (DoDAF)

Architectures within the Department of Defense (DoD) are created for a number of reasons. From a compliance perspective, the DoD’s development of architectures is compelled by law and policy (i.e., Clinger-Cohen Act, Office of Management and Budget (OMB) Circular A-130). The DoD Architecture Framework (DoDAF) was established as a guide for the development of architectures.

DoDAF explained

The DoDAF provides the guidance and rules for developing, representing, and understanding architectures based on a common denominator across DoD, Joint, and multi-national boundaries. It provides insight for external stakeholders into how the DoD develops architectures. The DoDAF is intended to ensure that architecture descriptions can be compared and related across programmes, mission areas, and, ultimately, the enterprise, thus, establishing the foundation for analyses that supports decision-making processes throughout the DoD.

DoDAF v1.5 is a transitional version that responds to the DoD’s migration towards Netcentric Warfare (NCW). It applies essential net-centric concepts1 in transforming the DoDAF and acknowledges that the advances in enabling technologies – such as services within a Service-Oriented Architecture (SOA) are fundamental to realizing the Department’s Net-Centric Vision. Version 1.5 addresses the immediate net-centric architecture development needs of the Department while maintaining backward compatibility with DoDAF v1.0.

In addition to net-centric guidance, DoDAF v1.5 places more emphasis on architecture data rather than the products, introduces the concept of federated architectures, and incorporates the Core Architecture Data Model (CADM) as an integral component of the DoDAF.

Figure A-4, Evolution of the DoDAF



AC/322(SC/1-WG/1)N(2007)0004



The DoDAF is a three-volume set that inclusively covers the concept of the architecture framework, development of architecture descriptions, and management of architecture data.

Volume I introduces the DoDAF framework and address the development, use, governance, and maintenance of architecture data.

Volume II outlines the essential aspects of architecture development and applies the net-centric concepts to the DoDAF products.

Volume III introduces the architecture data management strategy and describes the pre-release CADM v1.5, which includes the data elements and business rules for the relationships that enable consistent data representation across architectures.



AC/322(SC/1-WG/1)N(2007)0004



A.6 Ministry of Defence Architecture Framework (MODAF)

The UK Ministry of Defense Architectural Framework (MODAF) defines a standardized way of conducting Enterprise Architecture and provides a means to model, understand, analyze and specify Capabilities, Systems, Systems of Systems, and Business Processes. The purpose of MODAF is to provide a rigorous system of systems definition when procuring and integrating defense systems. As of 10th April 2007, MODAF version 1.1 was released.

MODAF explained

MODAF is methodology independent, but has been developed to provide an Enterprise Architecture approach in support of a wide number of communities across MOD and assist them in conducting their day-to-day business. Although there is strong support for operational processes and acquisition of capability to support these, MODAF is equally applicable to the business space, operational analysis, planning and all other aspects of the MOD enterprise and other organisations that interface with it, such as coalition partners and its supply chain.

MODAF architectures are an essential source for processes to deliver benefits from:

Structured analysis and articulation of business issues

Enhanced requirements specifications

Improved efficiency, effectiveness and standardization of MOD-wide processes and ways of working

Improved validation and assurance of solutions

A coherent portfolio of military capability and better integrated systems

Avoidance of unnecessary costs in the overall investment programme

In addition, MODAF has Through Life relevance, addressing;

Capability deployment and delivery through operational and system views

Business transformation and capability planning through strategic views

Programme synchronization through acquisition views

Defense Lines of Development (DLODs), which are inherent across all of the views.



AC/322(SC/1-WG/1)N(2007)0004






AC/322(SC/1-WG/1)N(2007)0004



A.7 AGATE v3

AGATE (Atelier de Gestion de l'ArchiTecturE des systèmes d'information et de communication) is a framework for modelling computer or communication systems architecture.

It is promoted by the Délégation Générale pour l'Armement (DGA), the French government agency which conducts development and evaluation programmes for weapon systems for the French military. All major DGA weapons and information technology system procurements are required to document their proposed system architecture using the set of views prescribed in AGATE.

AGATE is similar to DoDAF, promoted by U.S. Department of Defense (DoD) or MODAF, promoted by UK Ministry of Defence (MOD).

Figure A-5, Agate v3 logo

AGATE v3 explained

AGATE, CIS Architecture Management Framework, is a methodology intended to improve:

the accessibility of systems and their architectures;

the management of architecture data;

the sharing of knowledge;

the control and the coherence;

the efficiency of the parties contributing to the definition, the realisation and the implementation of CIS.

AGATE provides the means to describe Communication and Information Systems in a synthetic and homogeneous way thanks to a formalism and a set of federating rules.



AC/322(SC/1-WG/1)N(2007)0004



AGATE provides an environment for valorisation of information and sharing between the different parties of the Ministry of Defence. AGATE covers the following architecture aspects:

system goals and objectives;

description of organizations;

operational procedures, information exchange;

security requirements and management, conform with the Ministry’s methods;

system services and the link to the operational requirements;

logical organization of the system;

typical assembly of technical components, fielded products;

system life-cycle and its architecture element life-cycle follow-up.

AGATE can be used to describe systems of any size as well as systems of systems.

Process modelling has to be in conformance with MADIOS (Méthode d’ADministration de l’Interopérabilité Opérationnelle des Systèmes d’Information et de Communication) and made with the tools recommended by the CIADIOS (Centre Interarmées d’ADministration de l’Interopérabilité Opérationnelle des SIC).

The AGATE V3 reference manual is composed of HTML1 pages gathered inside ‘S-CAT n°10002 guide’. It consists of the following parts:

architecture views and their selection;

the modelling objects and options;

the objects modelling baselines;

the glossary;

interoperability with other methodologies and tools;

the AGATE charter for use;

standard contractual clauses;

changes from the previous version

the AGATE metamodel;

downloadable documents (additional application user guide for VISIO, MADIOS V2, etc.).

1 see http://www.achats.defense.gouv.fr/article33349; 40 MB files only available in French

http://www.achats.defense.gouv.fr/article33349



AC/322(SC/1-WG/1)N(2007)0004



Figure A-6, Principles of AGATE Views



AC/322(SC/1-WG/1)N(2007)0004






AC/322(SC/1-WG/1)N(2007)0004



A.8 Defence Architecture Framework (DAF)

In the context of the Australian Defence Information Environment (DIE), architecture is a disciplined approach to the planning and implementation of information capability for the Australian Defence Organisation.

As in the building industry context of architecture, the DIE architecture is a high level-planning tool providing a ‘top-down’ visualisation of the DIE structure and activity. The architectural approach produces a design that enables the optimisation of the DIE as a system of systems.

The purpose of architecture is to inform investment decision-makers how individual capabilities relate and interact with each other and provide an integrated development path. Architecture allows capabilities to interact across the enterprise. That is the DIE interacts with all of the other capabilities in the Enterprise to produce the effects based outcomes sought by government.

The Defence architecture methodology that has been adopted by the ADO for the development of the DIE architecture is the Defence Architecture Framework (DAF). The DAF has been developed from the United States Department of Defence Architecture Framework (DoDAF) and the METAGroup Enterprise Architecture Strategies.

A.8.1 The Defence Architecture Framework explained

The DAF is an integrated framework that has been developed as a means to improve the design and coherency of the DIE. Drawing on the US DoD Architecture Framework and the META Group Enterprise structure, the DAF has been developed as shown below in Figure A-7.

A key concept to understanding the DAF is that there are five ways of viewing a capability.

There are four Common to All views (CV) providing an overview, controlled language and architecture governance mechanisms for the capability.

There are nine operational views (OV) which together describe the components of the capability, the relationship between those components and the information needs.

There are 13 systems views (SV) which relate the capabilities and characteristics to the system requirements,

There are two technical standards views (TV) which document the current and emerging technologies required to build the capability and

There are seven Data Views (DV). The relationship between these sets of views is depicted in the following diagram.



AC/322(SC/1-WG/1)N(2007)0004



Research and Technology Influences

Opera

tional and B

usin

ess C

onte

xt

Defence Architecture Framework (v9.0)

Com

mon V

iew

Enterprise Architecture

Library

Governance, Compliance and Co-ordination

Fu

nd

am

en

tal In

pu

ts t

o C

apa

bili

tySpecific Architecture

Descriptions

Systems View

Technical View

Data

Vie

w

Operational View

Defence Enterprise Architecture Library

Defence Architecture Information Model

ToolsRepository

Enterprise Architecture

Business

Information

SystemsSta

ndard

s

Infrastructure

Security

Defines

Influences

Determines

Represented

by

Supported

by

Populated by

Figure A-7, Major components of the Australian Defence Architecture Framework

The Outside boxes, marked as are the external influences upon the Architecture. These encompass the Directions from Government, the internal directions within the department and the external governance regimes in place that direct, guide and constrain the department, the fundamental inputs to the development and maintenance of capability within the Department, and the research and technology base that supports all aspects of the work the department does.

The ‘Enterprise Architecture’ component is also an essential component providing the organisation with the methods, processes, discipline, and organisational structure to create, manage, organise, and use models for managing the impact of change.

The ‘Specific Operational & Business Architecture Descriptions’ component of the DAF provides a mechanism for standardising the documents that define the architecture of an enterprise.

By using the architecture descriptions lodged in the enterprise repository and the tools contained within the Defence Enterprise Architecture Library, the Enterprise Architecture framework can be accurately defined.

7

4

2 1

3

5

6

1 2

5

3

4

6

7



AC/322(SC/1-WG/1)N(2007)0004



A.8.1.1 Framework Elements

The Australian Defence Architecture Framework (DAF) is made up of four major elements. These are:

The Influences on the Architecture

The Enterprise Architecture

The specific instances of the Architecture, and

The Repository

A.8.1.2 The Influences on the Architecture

The Influences on the architecture are the four boxes on the outside of the Framework. The information contained in these boxes is the influences and environmental considerations, which shape and inform the actual Enterprise Architecture.

Information held in this area is not ‘doing’ information, that is operational or information required to drive and action or event, and should not included specific information, which is pivotal or essential to the operation of any part of the Enterprise Architecture. However, the information is granular and when moving between the various layers of an architecture, issues and influences will move or disappear.



AC/322(SC/1-WG/1)N(2007)0004






AC/322(SC/1-WG/1)N(2007)0004



A.9 Model-based Architecture for Command and Control Information Systems (MACCIS)

MACCIS is an architecture framework based on elements from C4ISR-AF (now DoDAF) and Reference Model for Open Distributed Computing (RM-ODP). The framework was developed by Sintef for the Norwegian and Swedish material commands. It has greatly influenced the architecture work in the Norwegian Defence, and has also been used as a basis for the architectural work in Multilateral Interoperability Programme (MIP), which is an international programme where the agenda is to achieve interoperability between different Nations’ land tactical C2IS.

MACCIS is an architectural description framework targeted towards software systems. In addition to identifying architectural artefacts, MACCIS also contains guidelines for how to produce the architectural artefacts.

MACCIS defines a generic framework for system architecture that can be applied in any domain. Figure A-8 shows both the generic and a specific C2IS version of the framework.

MACCIS Generic Framework

Co

mp

on

en

t T

ech

no

log

y

Mo

dellin

g L

an

gu

ag

e Model Assets

System

Architecture

Model

Baseline Development Process

System Scope

MACCIS Specific Framework

UM

L 1

.4

Core Models

C2IS

MACCIS Development Process

So

ftw

are

Co

mp

on

en

t

Refe

ren

ce A

rch

ute

ctu

reDictionary Patterns

Sta

nd

ard

s

Asset

descri

pti

on

Asset usage

Context Model

Requirements Model

Component Model

Distribution Model

Realisation Model

Figure A-8, MACCIS Framework

The generic framework focuses on system architecture models. The system architecture models are specified in a modelling language following a baseline development process. The system has a domain as specified in its scope and a set of target deployment technologies. In order to support system architecture modelling, a number of model assets are available, adapted to the language, process, scope and technologies. The specific architecture shows the refined framework for the C2IS scope.

MACCIS defines system architecture in terms of five architecture model views:



AC/322(SC/1-WG/1)N(2007)0004



Context Model: The purpose of the context model is to describe the operation of the target system within a given context. This model also defines the dependencies of the specified elements of the target system to the specified elements of the context system.

Requirements Model: The purpose of this model is to capture the requirements of the target system.

Component Model: The purpose of this model is to describe the services, information, components and interactions of the target system.

Distribution Model: The purpose of this model is to describe the distribution concerns of the target system.

Realisation Model: The purpose of the realisation model is to describe the realisation of the target system in terms of technology and realised subsystems.

NATO Architecture Framework Version 3 ANNEX A Architecture ... · NATO/EAPC UNCLASSIFIED APPENDIX 8...

Documents

Transcript of NATO Architecture Framework Version 3 ANNEX A Architecture ... · NATO/EAPC UNCLASSIFIED APPENDIX 8...