NATO Specific Architecture approach

Kinds of architecture

When NAF v3 is used, the NATO C3 community utilises four types of architectures: Overarching Architecture, Reference Architecture, Target Architecture, and Baseline Architecture.

Relationship between types of NATO architectures

(Overarching Architecture (OA),Reference Architecture (RA) and Target Architecture (TA). Baseline Architecture (BA) is not included in the figure.)

Depending on the issues and problems an architecture description is set to cover; it is relevant and appropriate to develop an architecture description that answers three basic questions: What is the required functionality? Logically, How can this functionality be met? Practically, what can be used, or With what can solutions be implemented?

This leads to a set of architectures commonly applied:

An enterprise-wide description of the future situation with limited detail, i.e. the What-question. In NATO this is the Overarching Architecture. In other frameworks these architectures are called “Entreprise Architecture”.
A more focused description of the construction with full detail to guide programme execution. Such a description, answering the How-question, can focus on a specific subject area or span the full enterprise. In NATO this type of architecture description is called a Reference Architecture. In other frameworks these architecture are called “Segment Architectures”.
A description limited to the scope of a single project addressing implementation decisions. Such a description builds on the previous type of architecture (Reference Architecture) and illustrates the implementation (With what-question) of the previously described construction. In NATO this type of architecture description is called a Target Architecture. In other frameworks these architecture are called “Implemented Architectures”.

The NATO C3 Overarching Architecture (OA) is a top-down description of the desired configuration of the NATO C3 System necessary to meet NATO’s medium to long-term (up to 15 years) capability requirements. It describes the relationships between the systems necessary to perform the functions of NATO Consultation,

Command and Control regardless of whether they are provided as a result of NATO common funding, multi-national co-operative efforts or by the use of National assets.

The description is rendered at a high level, but is detailed enough to identify, using standardised products, systems and system components within the User, Network, and Sensor domains, how they are interlinked, and how they interface with external C3 systems. The NHQC3S and the NC3A shall use the OA as the basis for providing recommendations to the NC3B for the development of future C3 systems policies and strategic plans.

The NATO C3 Board (NC3B) mandates Reference Architectures (RA) to support the development of Capability Packages under the NATO Security Investment Programme (NSIP). RAs reflect NATO strategic decisions regarding system technologies, stakeholder issues, and product lines. They render user requirements, processes, and concepts in a high-level solution from which individual projects can be identified and initially programmed. Their primary focus is on services, processes and component functionality, and they provide the basis for the development of Target Architectures (TA). RAs cover the entire planning cycle for a typical NATO system development, which is normally six years.

Target Architectures are mandated by the NC3B to support the preparation of NSIP Type B Cost Estimates (TBCE). Normally derived from the related RA, they specify a system design at a detail sufficient to direct the acquisition and integration of components to achieve a desired capability. TAs focus on specifications for systems and services. They are transitional of nature and are usually valid for the duration of the system acquisition and initial design. TAs modify the baseline architecture and can provide feedback to an RA.

NATO C3 System Baseline Architecture is a description of the fielded ‘as is’ state of the NATO C3 enterprise. Baselines (portions of the NATO architecture baseline) are used in NATO’s Mission Oriented Analysis (MOA) process to help assess potential solutions to evolving operational requirements. Baselines are tools necessary for the user, planner, manager, and system custodian to comprehensively establish, understand, and maintain the current enterprise or domain configuration. Baselines are rendered for NATO and National systems at a level of detail necessary for depiction of system components, their interconnectivity with each other, and any relevant external connectivity.

NATO Level and types as described by the NATO EA Policy

In order to manage the complexity of the NATO Enterprise, the NATO Enterprise Architecture Policy identifies three levels of architecture and four different domains/types of architecture The levels and types of architecture are as defined below.

Architectures at the NATO Enterprise Level

They provide the architecture content that forms the foundation for architectural coherence across the entire NATO Enterprise, and beyond. Architectures at this level will span many change programmes (e.g. capability packages). Key components of architectures at the NATO Enterprise-level are:

The C3 Taxonomy and the Technical Services Framework that provide a common language for the description of C3 Capabilities and ICT Services;
The C3 Integrated Master Plan (IMP) which provides an overview of the status of key C3 Capabilities; and
The NISP which provides the most current baseline of interoperability profiles and technical standards.

Architectures at the Capability Level

Architectures at this level are used to support the delivery of large, multi-phased and multi-project change initiatives (e.g. capability packages). They are used to:

Facilitate the definition of resource proposals to address existing shortfalls between the available (as-is) capability and the required (to-be) capability;
Support the scoping and phasing of projects to resolve these shortfalls;
Identify synergies between the projects; and
Direct, monitor and evaluate the execution of a set of related projects.

Architectures at the Project Level

Architectures at this level are describing the envisioned solution that the project aims to implement. They are used to:

Articulate the high-level design for a project in order to govern its execution;
Assure compliance with architectural governance;
Support the integration and alignment between projects;
Inform budget and acquisition decisions (e.g. in a Type B Cost Estimate (TBCE));
Provide the basis for more detailed specifications during contract preparation (e.g. in an Invitation for Bids (IFB));
Support contractor selection;
Govern the delivery of contracted products and services; and
Provide the basis for service transition and service operation activities.

Types of Architectures

Architecture on each level shall cover the following architecture types:

Business Architecture – describing the business strategy, governance, organisation, and key business processes (including process ownership and key decisions) of the organisation;
Information Architecture – describing the structure of an organisation’s logical and physical information assets and the associated data management resources and linking the information required to the key business processes and decisions;
Application Architecture – providing a blueprint for the individual application systems to be deployed, the information which they provide, the interactions between the application systems and their relationships to the core business processes of the organisation with the frameworks for services to be exposed as business functions for integration; and
Technology Architecture – describing the hardware, software and network infrastructure needed to support the deployment of the application systems.

Capability Planning within NATO

NATO Defence Planning Process (NDPP) is a continuous five step process, which NATO uses to utilize the combined resources of the alliance and of all the members of the alliance in order to accomplish its political goals commonly know as NATO’s Level of Ambition (LOA).

The NDPP process harmonises and integrates thirteen different planning domains. Among those domain are:

Armaments Planning - focusing on capability procurement processes and harmonization of the various R&T initiatives
Command, Control & Consultation (C3) Planning - which evaluates the tasks essential to NATO’s missions and determines those that require C3-related capabilities for their execution (NDPP STEP 2). These capabilities are identified, taking into account lessons identified and any enduring implications of urgent procurements in support of operations. Current C3 concepts and doctrine (for instance NNEC) shape C3 capability requirements, and certain aspects are captured using architecture frameworks (specifically the NATO Architecture Framework) and represented in the NATO Overarching Architecture. This helps to ensure that solutions developed in one area are compatible and interoperable with those developed in others. Typically targets are set (NDPP Step 3) as a result of identification of capability requirements both to individual nations (especially regarding standards and interoperability) and to NATO itself for the procurement of capabilities not suited to national provision.
Standardisation - This domain ensures that the identified capabilities will comply with standards to achieve interoperability. The Standardisation domain will participate mainly in NDPP Step 2and NDPP Step 3.

For all planning domains the NDPP process focus on providing the necessary capabilities necessary for NATO to accomplish it political goals. The necessary set of capabilities for medium and long terms use is called the Minimum Capabilities Requirements (MCR).

The process consists of the following five steps:

Establish Political Guidance.
Determine requirements.
Apportion requirements.
Facilitate implementation.
Review Result.

In step 2, NDPP compares existing capabilities with the MCR and thereby identify what is called Priority Shortfall Areas (PSA).. In step 3 the MCR and PSA are used to identify targets (capabilities), which much implemented by NATO- and/or nations.

Capability Package Management within NATO

NATO implements these targets though the capability packages management process, thereby ensuring that NATO will be able to deliver the minimum capability requirements necessary to fulfil its political goals.

The capability management process is strictly aligned with the NDDP process and describes at a very high level how and by whom capabilities are identified, developed and implemented. Here a capability will consist of one or more functional components: Doctrine, Organization, Training, Materiel, Leadership development, Personnel, Facilities and Interoperability (DOTMLPFI).

The capabilities development process steps are:

Analysis of Strategic Environment.
Identify Capability Needs.
Derive Requirements.
Conduct Gap Analysis and Fulfilment.
Identify Possible Solutions.
Conduct Implementation.

There are many similarities between this process and the architecting for the enterprise methodology defined by NAF. However, the description of the Capability Management process is currently at such a high level, that it will require further analysis, before the benefits of using a NAF based approach can be described in detail.

Reference Architectures within NATO

When developing capabilities, NC3B mandates that all capability packages developed for the C3 planning domain must create a reference architecture before initiating the development of the capability package. This reference architecture facilitates the requirement definition and should focus on services, processes and component functionality.

According to ACT: “The Reference Architecture will be used to:

Provide the tools that support Capabilities Development process including support for requirements capture, definition and implementation.
Provide communication means between operational analysts, architects and operational users.
Fulfil the ACT role of RA provider as mandated by NATO C3 System Interoperability Directive (NID) and NATO Networked C3 Interoperability Policy (NIP).”

The process employed by ACT follows the following steps:

Identify User Requirements (SCs).
Analyse Business processes (SCs, NCIA).
Capture requirements (SCs, NCIA).
Identify services (ACT, NCIA).
Create architecture models (ACT, NCIA).

Most process steps involves multiple types of actors from multiple organisations, which is seem the reason, why NAF 3 have been used a common language. However, ACT does not describe the process in detail, only the products in the form of NAF v3 views. They are:

NAV-1 Overview and Summary Information
NAV-3a Architecture Compliance Statement
NOV-5 Operational Activity Model
NSOV-1 Service Taxonomy
NSOV-2 Service Definition
NSV-1 System Interface Description
NSV-4 System Functionality Description
NSV-5 Systems Function to Operational Activity Traceability Matrix
NSV-7 System Quality Requirements Description
NSV-10a Systems Rule Model
NSV-11a Logical Data Model
NSV-12 Service Provision
NTV-1 Technical Standards profile

Recommendations for NATO

As long as reference architecture is considered, it shall guide and constrain building multiple architectures. It seem strange that that the set above lacks viewpoints that describe the purpose of the architecture in the form of context, scope, stakeholders and what should be described. A capability taxonomy would also be very useful.

Although an architectural approach is used for reference architecture which is a requirement for capability development in the C3 domain, it is not a natural part of a the capability development process and therefore not part of the NDPP process, where a different language is used.

Use of architecture assists in handling information from multiple sources and detect and eliminate redundant information and evaluate requirements. Architecture help trace requirement to the solution and back, thereby ensuring that a solution is based on a specific requirement.

The iterative approach introduced with the NAF v4 methodology enables us to continuously revisit the stages in the process and re-orient the architecture when necessary.