1. Overarching Architecture v2.5 Architecture Workshop 1 June 2006
Intro
In this briefing NC3A will present the results of the work on the Overarching Architecture as conducted in the OA project in The Executive Summary of the project results is available for you in print. For the demo I will be supported by Mr Martijn Faay, Capgemini consultant and member of the OA v2.5 development team. We will illustrate the results with a live demo of the Agency’s Federated Tool Environment that has been established as part of this project.
Please note that the OA v2.5 is a stepping-stone from the traditional line of thinking of tightly-coupled systems towards the NNEC line of thinking of loosely coupled federated services. This involves a paradigm-shift from stove-pipes (or “tubes of excellence”) to common and generic shared services. To arrive at that vision NATO needs a holistic approach to identifying the services and their collaborations, captured in an enterprise-wide architecture. The OA v2.5 is a first step towards that enterprise-wide architecture.
Olaf Kruidhof
NC3A Senior Systems Architect
Project manager OA v2.5
NATO / EAPC Unclassified

2. Lead-points supporting Transformation
Services as the unifying paradigm
Information as the central subject
Objectives as the common foundation for OA and CBP
Comprehensive and coherent set of architectures supported by
Systematic and logical causal reasoning
Flexible tool environment
The OA v2.5 aims at supporting the transformation towards NNEC by incorporating three foundational aspects:
In order to arrive at a modular and agile support by C3 CIS, the service paradigm is applied as the unifying paradigm through-out the architecture. All functionality of the mission space, information aspects, CIS and infrastructure are captured as service collaborations between the various parties, one delivering a service to the other. This allows for a componentised approach to capability development. The OA is focussing on C3 systems capabilities and offers anchor-points to broader C3 capability development.
The OA takes into account information as a first class citizen in order to support the development of architectures. Situational awareness is key in NNEC, therefore being able to handle all aspects of the information involved is crucial for success.
In the transformation to Effect-based operations and capability-based planning understanding the objectives of the organisation and its missions are foundational. The OA is founded on a broad understanding of NATO’s objectives.
The OA is constructed by applying a consistent line of reasoning, starting from NATO’s objectives leading to technical details of interfaces between systems and services.
The OA is captured in a repository of architecture data that can host follow-on architecture deliverables in order to arrive at a comprehensive knowledge base ranging from the enterprise architecture to the systems-level architectures.
NATO / EAPC Unclassified

3. Related to Defence Planning
Fellow Architects
REQUIREMENTS
C3 CAPABILITY
TO MATCH
NATO
NEEDS
C3 OVERARCHING ARCHITECTURE
RESOURCE PLANNING - SRB
(NATO FUNDED PROGRAMMES)
Baseline Architecture
Reference Architectures
Target Architectures
Resource & Capability Planners
ARMAMENTS PLANNING - CNAD
(MULTINATIONAL PROGRAMMES)
This view foil illustrates the current position of the OA. The OA should be used to identify RA’s for Resource Planning and support Armaments Planning and Force Planning. This position indicates that the nature of the OA is quite different from RA’s and TA’s. In fact it indicates why the OA is focusing much more on the Operational domain than on CIS technology.
This view foil also illustrates that there are many stakeholders for the OA. All of them should be able to use the OA. Clearly there can not be one size that fits all. The results from the OA can be taken and tailored to answer specific architectural questions. This is where the FTE plays an important role.
National parties
FORCE PLANNING – ACT/MC
(NATIONS’ CAPABILITIES)
Systems Developers
Operational Users
NATO / EAPC Unclassified

4. NATO Architecture Framework Architecture Engineering
Approach
NATO Architecture Framework
= User’s View
Doctrine
Operational Concept
Mission types
System characteristics on physical nodes
What people need to accomplish & how they collaborate
What information need be available & how to distribute
What systems need to do & under which conditions
Architecture Engineering
Methodology
= Builder’s View
Dealing with architectures can be visualised with the metaphor of an iceberg. The tip of the iceberg is what users of architectures are interested in: real world operations and real world tangible systems. We can call this the User’s View. The NATO Architecture Framework (NAF) provides the templates that are to be used to present the architecture to the users.
To keep this tip afloat there is a substantial amount of thinking and modelling involved. To the user this is conducted completely out of sight, subsurface as it were.
The NAF does not describe how to develop at the templates, nor does it specify inter-relationships between the various templates. Therefore the NC3 Agency uses the Architecture Engineering Methodology (AEM) as the way of working. The AEM is a methodology developed by the Agency as an amalgamation of several state of the art architecture approaches from industry, governmental organizations and academia, that each focus on a specific architectural aspect. The main characteristic of the AEM is that it pulls together a number of best practices, to arrive at a comprehensive, coherent and consistent methodology for use in the NATO environment. This effort is primarily of interest to fellow-architects: the Builder’s view.
NATO / EAPC Unclassified

5. Architecture Engineering Methodology: Supporting transformation to NNEC
Mission
Space
Information
Application
Technical
Infrastructure
Abstraction levels
Aspect Areas
Security and Governance
Architecture
viewpoint
Why?
Direction and impact from the environment
Why are we doing it?
The concepts and functionality
What do we want?
Logical solutions
How do we ideally want it to work?
Feasible solutions
With what can it actually work?
Migration path
When can we do what?
Contextual level
What?
Functioanlity level
How?
Construction
level
The Architecture Engineering Methodology provides a systematic and logical line of reasoning covering six essential aspects relevant for C3 CIS support:
Mission Space: the operational world where people, organisations execute operational services to deliver results that contribute to their objectives
Information: the services required for gathering and sharing of information required by the people and organisations in the mission space to execute their tasks and reach their objectives.
Application: the automated user services that provide information processing in order to deliver meaningful results to the users.
Technical Infrastructure: the technical services that are required to execute and run the user services.
And the integral aspects that apply to all the earlier aspects:
Security: the services to provide the information assurance required.
Governance: the services that allow for maintenance and configuration of other services.
For each of those aspects three fundamental architecture question need to be answered:
What does NATO want and need in terms of functionality for each of the aspects?
How do we ideally want to construct this functionality?
With what can we actually implement the ideal construction, i.e. to what extent can we reach the ideal solution yet?
The Why and When questions link the architecture work to the vision and strategy and to practical program execution respectively.
The reasoning expressed by the AEM is well suited for a top-down approach: first understand the mission space and then zoom in to the information that is required and how it needs to be handled down to identifying the required CIS functionality and its construction, including the common and generic infrastructure facilities.
However it also well suited for a more bottom-up approach. Choices for specific technology can be made to improve current operations. At a later stage the new technological opportunities can and will start influencing the way we use and depend on information and ultimately the way we conduct operations.
With what?
Implemenatio
level
When?
Transformation level
NATO / EAPC Unclassified

6. NATO C3 Interoperability Framework
Nato’s architectures
Execution
Responsibility of Interoperability Sub-Committee (AC/322-SC/2)
Policy
Responsibility of NC3 Board
NAF
Design
Implementation
Operational View
Systems View
Technical View
Overarching Architecture
Reference Architectures
Target Architectures
NC3TA –
Volume 4 NCSP
& 5 NCOE
NC3TA –
Volume 2
NATO deals with architectures for some time. The NATO Interoperability Framework describes the Policy and Directive for Interoperability and provides guidance for the development of architecture development through the NAF.
The NAF is a suitable framework for communicating architectural results. It does allow for a large degree of freedom on how to arrive at the architectural results.
The NATO Interoperability Directive prescribes three views (operational, Systems and Technical) that are to be used in three types of architectures: Overarching Architecture, Reference Architecture and Target Architecture.
As a companion to architecture work the NC3 Technical Architecture provides a catalogue of technologies and standards that are to be used for the implementation of systems and services. For the development of OA v2.5 version 6 of the NC3TA was used. In the meantime it has become clear that the traditional approach to the NC3TA needs to be updated to support NNEC.
The OA is presented using NAF compliant views. However there is more information available in the Federated Tool Environment that could be very worthwhile that can not be presented in a NAF compliant way. Or in other words, to support the transformation towards NNEC additional views are useful.
Products – NATO Interoperability Environment
Responsibility of Information Systems Sub-Committee (AC/322-SC/5)
NATO C3 Interoperability Framework
NATO / EAPC Unclassified

7. NATO / EAPC Unclassified
Key features OA v2.5
Top-down description of the requirements for the NATO enterprise-wide To-Be situation
Incorporating the NNEC paradigm
Based on a rigorous line of reasoning behind the diagrams
Mapped against As-Is systems and Reference Architectures
Allows for assessment of conformity of current situation to the envisioned situation
Allows for provision of guidance to future developments (NATO & nations)
Provide textual descriptions and graphical presentation of:
Which systems do we need: Envisioned functionality of CIS at strategic, tactical and operational nodes
How do they interface: Envisioned interfaces between system services as captured in CIS/Reference Architectures
What do they exchange: Unambiguous semantic definitions of the information elements exchanged
How well do they need to operate: Quality requirements for system services, e.g. security, availability and performance
NID and NAF v2.0 compliant views
Stored in an open (XML-based) repository that allows for:
Re-use of earlier results
Accumulation and inter-relation of architecture deliverables
Creation of tailored views and reports
Similar to its previous iteration OA v2.5 is a combination of a top-down capturing of requirements, firmly founded in operational world, and a bottom-up mapping of existing systems and Reference Architectures.
It is important to be aware of this combination, since the OA might appear to be somewhat of a hybrid architecture.
The OA contains a modelling of the mission space and derived from it the user’s information requirements. The information requirements lead to requirements for CIS, including its technical infrastructure.
These requirements have been mapped against existing CIS and Reference Architectures.
These results are presented in NAF compliant views focussing on the interfaces that, according to the captured requirements, need to exist between the systems. It is important to note that since the OA is forward looking it is to be expected that not all interfaces are implemented yet in today’s existing systems or even captured in the RA’s.
In fact it is one of the applications of the OA to identify requirements for further development.
The results of the OA v2.5 are stored on top of the material of OA v2.0 in the Agency’s FTE. This allows and promotes the future integration of all architecture work conducted by the NC3A. Furthermore is allows the development of tailored diagrams and reports to support answering specific architectural questions.
NATO / EAPC Unclassified

8. Example Application of OA - Operational Planning
Mission
Space
Information
Information Systems
Technical
Infrastructure
Aspect Areas
Abstraction levels
Why:
Context
Starting point Operational Planning
Planning situation (COP, SDP)
Real situation (OPLAN)
What:
Functionality
Desired effects
Requires
Operational Services
Information Services
User Services
TI Services 1 1 1
How:
Construction
Force
Structure
This view foil illustrates the line of reasoning that can be followed in support of an operational planner that is trying to determine which systems capabilities are required for this specific mission. This illustration uses the AEM framework as a backdrop and we will demonstrate the linkage between this strict methodology and the resulting NAF views.
Starting from the Operational objectives the mission needs to fulfil the operational services that need to be conducted can be identified. From there the roles and responsibilities (represented by an Actor) can be found and linked to the information services required, linked to the applications or CIS required. This trace can be followed in the AEM models and in the NAF models.
The Federated Tool Environment supports the application of the OA in a flexible manner. However these kind of tools are primarily focused at utilisation by architects. Users need to have a good understanding of what they want to view. Creating custom views requires thorough knowledge of the underpinning the meta-model and the mechanisms (like scripts) to access the data. 2 2
With what:
Implementation
Forces
Procedures
Information
systems
Technical Infra
Equipment 1
Derived from
NATO / EAPC Unclassified 2
Analysis current systems

9. NATO / EAPC Unclassified
Summary and Next steps
The Service paradigm is an integral and unifying paradigm in the OA  Brief Item 3
Information is the key subject
The OA can be queried and analysed to support NATO’s planning processes:
Capability development  Briefs Items 5 & 7
NNEC CMM  Brief Item 8
The OA is NAF compliant but more information is available and needed for NNEC  Brief Item 4
The OA provides a enterprise-wide starting-point with material to be reused an refined at Reference Architecture level  Brief Item 6
The OA provides the pointers to identification of new technologies and standards  Brief Item 9
NATO / EAPC Unclassified

10. NATO / EAPC Unclassified
Questions?
This concludes my brief and demo. If you have any comments or questions please send them to me.
NATO / EAPC Unclassified