=Paper=
{{Paper
|id=Vol-1728/paper11
|storemode=property
|title=How to Adopt NAF and TOGAF Concurrently: Experiences in C2IS Architecture Design. Description of a Possible Way to Adopt NAF Subviews as TOGAF ADM Products in Regards to Maritime C2IS Architecture Design
|pdfUrl=https://ceur-ws.org/Vol-1728/paper11.pdf
|volume=Vol-1728
|authors=Sergio Funtò
|dblpUrl=https://dblp.org/rec/conf/ciise/Funto16
}}
==How to Adopt NAF and TOGAF Concurrently: Experiences in C2IS Architecture Design. Description of a Possible Way to Adopt NAF Subviews as TOGAF ADM Products in Regards to Maritime C2IS Architecture Design==
https://ceur-ws.org/Vol-1728/paper11.pdf
How to adopt NAF and TOGAF concurrently:
experiences in C2IS architecture design.
Description of a possible way to adopt NAF subviews as TOGAF ADM products in regards
to Maritime C2IS architecture design.
Sergio Funtò
Engineering Ingegneria Informatica S.p.A.
Via S. Martino della Battaglia 56 Rome, Italy
sergio.funto@eng.it
Copyright © held by the authors.
Abstract • A standard modelling language to employ that allows immediate
communication between the actors involved in the design and
This paper reports on experiences from defining the architectural development phases of a C2IS (UML and SysML).
design method related to the definition of a maritime Command and
Control Information System (C2IS). The adopted design strategy has The resulting approach takes into account the system
chosen TOGAF as architecture development methodology (ADM) development life cycle identified by quality standard adopted for the
and NATO Architecture Framework (NAF) for metamodel and software development and documentation.
content organization. In order to make TOGAF and NAF work
together and address the particular requirements of C2IS, adaptation The next section describes the background of the work, and
and tailoring was required. Starting from related works that have introduces NAF and TOGAF. Section III outlines the integration and
been identified applicable mappings between NAF views and adaptation that went into designing a customized architecture
TOGAF ADM phases, it is presented here a possible way to adopt the framework. Section IV reports on maritime C2IS High Level (HL)
NAF subviews as TOGAF ADM products in regards to C2IS architecture and main building blocks according to TOGAF
architectural design method. The presented approach takes into Architecture Development Methodology (ADM). Section V proposes
account the system development life cycle identified by quality the Work Breakdown Structure (WBS) related to the C2IS
standard adopted for the software development and documentation. architectural design activities. The WBS is based on the TOGAF
The results of this study are reported also in terms of Work ADM phases and the related deliverables are aligned with the NAF
Breakdown Structure (WBS) that presents a deliverables oriented products.
decomposition of the products of the architectural design and acts as
a correspondence matrix between deliverables and activities.
II. BACKGROUND
Keywords—Architecture Framework, TOGAF ADM, NAF
Views/Subviews. A. The NATO Architectural Framework (NAF)
The NATO Architectural Framework (NAF) provides the rules,
I. INTRODUCTION
guidance, and products for developing and presenting architecture
This paper presents experiences from defining the architectural descriptions that ensure a common denominator for understanding,
design method related to the definition of a maritime (and navy) comparing, and integrating architectures. The application of the
Command and Control Information System (C2IS). Framework enables architectures to contribute most effectively to the
acquiring and fielding of cost-effective and interoperable military
The methodologies and the supporting tools for the design of capabilities. In the following of this document NAF V3 version is
C2IS architecture are specified starting from the identification of: considered [3].
• A framework to adopt in order to document the different • In NAF, NATO defines four kinds of architectures:
elements/meta-elements that define or affect the C2IS
architecture. This framework must specify which aspects of the • the overarching architecture should look several years into the
architecture have to be described and in which way, taking into future and answer the questions of what the enterprise is doing,
account the interaction with external actors; and why;
• A design activity method. This method must define the phases • a reference architecture typically covers a span of a few years,
of the architectural project specifying the relation between the describing how the enterprise functions;
activities identified in each phase;
• a set of different target architectures for solutions development,
which covers the technical aspects;
• a baseline architecture describes the technical aspects of the
current enterprise.
1) The NAFArchitecture views
Within the NAF there are seven major “views” that can be
logically combined to describe architecture:
• NATO All View (NAV): it captures overarching aspects of
architecture that relate to all seven views. NAV products provide
information pertinent to the entire architecture, but do not
represent a distinct view of the architecture. NAV products set
the scope and context of the architecture;
• NATO Capability View (NCV): it supports the process of
analyzing and optimizing the delivery of military capabilities in
line with the strategic intent. The NCV captures essential
elements of the strategic vision and concepts and decomposes
this data into capability taxonomy. The taxonomy is augmented
with schedule data and measures of effectiveness to enable the
analysis of capability gaps and overlaps; Figure II-1: NAF views relationships
• NATO Operational View (NOV): it is a description of the tasks NCV and NOV are typically defined at enterprise level but
and activities, operational elements, and information exchanges considering the features of the Maritime C2IS an update of these
required to accomplish the missions. The NOV contains views must be considered during the architecture design
graphical and textual products that comprise an identification of development.
the operational nodes and elements, assigned tasks and
activities, and information flows required between nodes; Each of these seven views is further decomposed into subviews,
which are diagram types for the enterprise architecture models. NAF
• NATO Service-Oriented View (NSOV): it was lately added to derives this core structure of views and subviews from the US
NAF to support building architectures based on the concept of a Department of Defense Architecture Framework (DoDAF) V2.00 [1].
Service-Oriented Architecture (SOA). The NSOV is a The NAF core structure however it is aligned also with the last
description of services needed to directly support the operational release of DoDAF (V2.02) [2].
domain as described in the NOV;
2) The NAFMeta Model (NMM)
• NATO Systems View (NSV): it is a set of graphical and textual
products that describes systems and system interconnections
The NAF Meta Model (NMM) is the information model for NAF,
providing for, or supporting, organization functions. The NSV
defining the structure of the underlying architectural information that
associates systems resources to the NOV that support the
is presented in the Views. NMM makes NAF architectures “model-
operational activities and facilitate the exchange of information
driven” (i.e. the views that are presented to the user are snapshots of
among operational nodes;
underlying architectural data that can be stored in the architecture or
in a Repository).
• NATO Technical View (NTV): It is the minimal set of rules
governing the arrangement, interaction, and interdependence of The NMM:
system parts or elements. Its purpose is to ensure that a system
satisfies a specified set of operational requirements. The NTV • Contains the definitions of all architectural elements identified
provides the technical systems implementation guidelines upon
in NAF;
which engineering specifications are based, common building
blocks are established, and product lines are developed;
• Contains all the allowable relationships between those elements;
• NATO Program View (NPV): It describes the relationships
• Provides the specification for XMI (1) file interchange between
between capability requirements and the various programs and
NAF architecture tools;
projects being implemented.
• Is used as specification for configuring the architecture
repositories;
Each view describes a specific meta-element of the architecture
(capability description, operational activities identification, system
and technology design), that must be described and taken into
account during the design, by defining a set of elements and 1
The XML Metadata Interchange (XMI) is an Object Management Group (OMG)
information to be managed (see next figure): standard and it is not a file format. It is a way of producing a file format for a modelling
language. The XMI specification defines how a meta-model can be translated into an
XML specification. The most common use of XMI is as an interchange format for UML
models, although it can also be used for serialization of models of other languages (meta-
models).
• Is defined as an extension to the UML 2.0 meta-model so that it • These decisions must be based on a practical assessment of
may also act as a specification for UML profiles (2). resource and competence availability, and the value that can
realistically be expected to accrue to the enterprise from the
The NMM elements will be used to define the Work Package chosen scope of the architecture work;
(WP) output within the proposed Work Breakdown Structure (see
Section V). • As a generic method, the ADM is intended to be used by
enterprises in a wide variety of different geographies and
applied in different vertical sectors/industry types. As such, it
may be, but does not necessarily have to be, tailored to specific
B. TOGAF ADM needs. For example, it may be used in conjunction with the set
of deliverables of another framework, where these have been
TOGAF (The Open Group Architecture Framework) is an deemed to be more appropriate for a specific organization.
architecture framework and a tool for assisting in the acceptance,
production, use, and maintenance of enterprise architectures. TOGAF 2) TOGAF ADM phases
is developed and maintained by The Open Group Architecture
Forum. It is based on an iterative process model supported by best TOGAF 9 covers the development of four architecture domains:
practices and a re-usable set of existing architectural assets. TOGAF
complements, and can be used in conjunction with, other frameworks • Business Architecture: business strategy, governance,
that are more focused on specific deliverables for particular vertical organization, and key business processes;
sectors such as Defense.
• Data Architecture: structure of an organization's logical and
The TOGAF Architecture Development Method (ADM) is the physical data assets and data management resources;
result of continuous contributions from a large number of architecture
practitioners. It describes a method for developing and managing the • Application Architecture: blueprint for the individual
lifecycle of enterprise architecture, and forms the core of TOGAF. It application systems to be deployed, their interactions, and their
integrates elements of TOGAF as well as other available architectural relationships to the core business processes of the organization;
assets, to meet the business and IT needs of an organization.
• Technology Architecture: The software and hardware
In the following of this document TOGAF 9.1 version [4] is capabilities that are required to support the deployment of
considered. business, data, and application services. This includes IT
infrastructure, middleware, networks, communications,
1) TOGAF ADM keypoints processing, and standards.
TOGAF ADM has matured over more than a decade of industrial These are commonly accepted as subsets of an overall enterprise
experience. Until version 9, it was agnostic of architecture framework architecture, all of which TOGAF is designed to support.
and metamodels. It has been widely used with frameworks from
Zachman and various modeling tool vendors, and with customized The TOGAF ADM defines a recommended sequence for the
frameworks developed by different industries and organizations. various phases and steps involved in developing architecture, but it
cannot recommend a scope. This has to be determined by the
The following are the key points about the ADM: organization itself, bearing in mind that the recommended sequence
of development in the ADM process is an iterative one, with the
• The ADM is iterative, over the whole process, between phases, depth and breadth of scope and deliverables increasing with each
and within phases. For each iteration of the ADM, a fresh iteration (see Figure III-2).
decision must be taken as to:
Within the ADM are envisioned the follows phases:
o The breadth of coverage of the enterprise to be
defined, • The Preliminary Phase: describes the preparation and initiation
activities required to create an Architecture Capability, including
o The level of detail to be defined, the customization of TOGAF, and the definition of Architecture
Principles;
o The extent of the time period aimed at, including the
number and extent of any intermediate time periods, • Phase A: Architecture Vision describes the initial phase of an
Architecture Development Cycle. It includes information about
o The architectural assets to be leveraged, including: defining the scope, identifying the stakeholders, creating the
Architecture Vision, and obtaining approvals;
o Assets created in previous iterations of the ADM cycle
within the enterprise, • Phase B: Business Architecture describes the development of a
Business Architecture to support an agreed Architecture Vision;
o Assets available elsewhere in the industry (other
frameworks, systems models, vertical industry models, • Phase C: Information Systems Architectures describes the
etc.); development of Information Systems Architectures for an
architecture project, including the development of Data and
2
An UML profile provides a generic extension mechanism for customizing UML Application Architectures;
models for particular domains and platforms
• Phase D: Technology Architecture describes the development of • Preliminary Phase: This is the starting point for adopting SOA
the Technology Architecture for an architecture project; and service orientation as architecture principles;
• Phase E: Opportunities and Solutions describes the process of • Phase A: The SOA vision in the architecture is defined
identifying major implementation projects and grouping them highlighting the type of services, its composition and contract,
into work packages that deliver the Target Architecture defined how they support the business processes and its business
in the previous phases; benefits;
• Phase F: Migration Planning describes the development of a • Phase B: The information that is central to the business
detailed Implementation and Migration Plan that addresses how operations which is crucial for SOA is described identifying and
to move from the Baseline to the Target Architecture; defining the portfolio services;
• Phase G: Implementation Governance provides an architectural • Phase C: The application architecture for SOA means groups of
oversight of the implementation; loosely-coupled services, the definition of these services and the
interaction between them based on the previously defined data
• Phase H: Architecture Change Management establishes models;
procedures for managing change to the new architecture;
• Phase D: The Technology Architecture for enterprise SOA
• Requirements Management examines the process of managing includes:
architecture Requirements throughout the ADM.
o catalog of SOA run-time infrastructure, SOA
The results of these activities, taking into account the goal of this development environment, service components
technical proposal and the TOGAF configurability, must be managed technology, and service interface technology,
within the NAF views products.
o Service/Physical System Matrix that shows which
TOGAF ADM phases will be used to define the Work Package physical systems host the services,
(WP) within the proposed Work Breakdown Structure (see Section
V). o Service/Technology Matrix – shows which items in
the technology portfolio are used in the performance
3) TOGAF ADM and SOA of which services.
As stated in the previous paragraphs TOGAF is a generic The models provide a view to demonstrate to stakeholders how
Enterprise Architecture framework. SOA specific concerns relating to Technology Architecture are
addressed.
SOA (Service Oriented Architecture) is an industry standard
architectural style that re-structures applications as loosely coupled,
modular services to deliver boundary less information flow.
III. ADOPTING TOGAF ADM AND NAF CONCURRENTLY
As commonly done by a number of NATO Agencies and Nations,
The objectives of TOGAF and SOA are quite similar. However the proposed approach adopts TOGAF ADM as the architecture
TOGAF is an architecture framework and SOA is an architectural development methodology and the NAF to develop meta-models and
strategy. Following picture shows as SOA phases can be managed the architectural contents organization.
within the TOGAF ADM Phase introduced below:
In order to have TOGAF and NAF working together with the
purpose of addressing the specific needs, a number of adaptations
will be needed. The resulting framework is implemented as a set of
UML profiles / content structures for the architecture repository.
Following figures depict the NAF vs. TOGAF ADM architecture
landscape and immediate correspondences between the two
architectures are highlighted [5].
This is due to the common link between NAF and TOGAF: the
Department of Defence Architectural Framework (DoDAF) model
[1], [6]:
• first version of TOGAF is mainly based on TAFIM (Technical
Architecture Framework for Information Management)
developed by the US Department of Defence. TAFIM was the
reference model for the DoDAF definition;
Figure II-2: TOGAF ADM Phases vs SOA phases
• NAF is a derivative frameworks based on DoDAF.
More in details (considering only the ADM architectural design
phases):
According to the highlighted correspondences, the NAF views
related to the Maritime C2IS architecture are defined during the
related TOGAF ADM phase/phases.
A. The architecture repository
Operating an architecture capability within a complex enterprise
creates a volume of architectural output. Effective management and
leverage of these architectural work products require a formal
taxonomy for different types of architectural asset alongside
dedicated processes and tools for architectural content storage.
Both NAF and TOGAF foresee an architectural repository and
the management of this is one of the main activities to execute during
the architecture design. This repository will allow the stakeholder to
distinguish between different types of architectural assets that exist at
Figure III-1: NAF architecture landscape
different levels of abstraction in the organization. This Architecture
Repository which provides the capability to link architectural assets
to components of the Detailed Design, Deployment, and Service
Management Repositories.
At a high level, six classes of architectural information should be
held within the Architecture Repository:
• The Architecture Meta-model that describes the organizationally
tailored application of the architecture framework, including the
NMM for architecture content (see paragraph II.A);
• The Architecture Capability: defines the parameters, structures,
and processes that support governance of the Architecture
Repository;
• The Architecture Landscape that presents an architectural
representation of assets in use, or planned, at particular points in
time;
• The Standards repository captures the standards with which the
new architecture must comply, which may include industry
Figure III-2: TOGAF ADM architectures landscape standards, selected products and services from suppliers, or
shared services already deployed;
Following picture shows the relationships between the NAF
• The References repository provides guidelines, templates,
views and the TOGAF ADM phases [5]:
patterns, and other forms of reference material that can be
leveraged in order to accelerate the creation of the new
architecture.
The links between these areas of the Architecture Repository, in
regards to Maritime C2IS, are shown in the following figure
including the relationship with the information coming from
Maritime organization (sponsor of the project/activities) processes
and adopted standard.
Figure III-3: NAF views vs TOGAF ADM phases
Figure IV-1: C2IS HL services organization
• Basic services: this services group includes:
o Picture management functions: 2D and/or 3D
georeferenced visualization of information including
vector and raster maps, overlays, terrain elevation
Figure III-4: C2IS Architectural Repository organization
data, georeferenced imagery, georeferenced
IV. C2IS HIGH LEVEL ARCHITECTURE AND BUILDING BLOCKS multimedia files, georeferenced object (battlespace
object for Navy C2IS). The system enables the user to
display and elaborate the geographic information
This section identifies a possible schema for the C2IS High Level according to different geographic projections and
(HL) architecture. The proposed HL architecture is based on the most coordinate systems;
common C2IS functional and non-functional identified features.
o Symbology (APP6A, NTDS, Custom) management
functions: display of appropriate standard symbology
A. C2IS main capabilities associated to system data (APP6/MIL-STD 2525) The
system enables the user to edit, display and manage
The main aim of a C2IS is to gives Command and Control (C2) custom symbology;
capability to the specific organization through improving situational
awareness, decision support, interoperability, force readiness o Track management functions (association, correlation,
assessment and collaboration. etc.): the system enables the user to (manually or
automatically) group, correlate and simulate track
Fundamental Maritime (and Navy) C2 capabilities need to be information received by the different sensors;
satisfied are listed below:
o Formatted messages (ADatP-3, OTH-Gold, VMF)
• Monitoring; management functions: the system supports the user in
order to receive, visualize, store and edit fix format
• Data collection and analysis; messages according to standard Message Text Format
(MTF);
• Situational analysis support;
o Unformatted messages management functions: the
• Missions planning; system provides message handling capabilities based
on standard technology (e.g. email exchange
• Support to mission execution, direction and coordination; according to X.400 Recommendations) and taking into
account standards (STANAG 4406/ACP126, ACP
• Decision process support; 133) and implementation guide (ACP 145);
• Battleship awareness support (only for Navy C2IS). o Battlespace information management functions (only
for Navy C2IS): the system manages the following
These capabilities are achieved starting from on a network information coming from all system sources:
organization approach that provides network management
functionalities, the information exchange (through wired and radio track data coming from system sources in
communication) and enterprise services. near-real-time,
personnel data ;
B. C2IS HL services architecture
military unit data,
This paragraph identifies the main C2IS service starting from the
facility infrastructure data,
assumption that the C2 functions must be supported by an
information technology services organization web oriented (e.g.
etc.;
SOA). The C2IS services can be classified in the following services
groups (see next figure):
o Mission plan and order management functions: the • System management services that includes the following
system supports the user in managing the operation functionalities:
plans and orders based and on custom or standard
(STANAG 2014) template; o Systems management functions:
o Alerts and warning management functions: the system monitor all services usage and performance,
enables the user to manage the configuration of alerts
and warnings for the system that must to raise in manage the configuration of system
audible and graphical way; network,
o Support to collaboration functions: the system shall monitor the status of the system nodes of
provide users with the following capabilities: elaboration,
chat (according to XMPP), o Database management functions: the system shall log
any change occurred on a database,
whiteboard,
o System web portal management functions including
planner, Multilanguage service,
document management, o System time management function: the system shall
receive automatic time inputs from a Global
report and briefing services Positioning System (GPS) and allows the user to
manually set the time;
web portal access;
• Information assurance management services that include:
• Functional services: it includes services related to:
o Access Services: the system shall be able to control
o Planning functions: the system provides Decision Aid the access to information managed within (e.g. Single-
services to support the user during the decision Sign-On mechanisms),
making process;
o Data security functions (e.g. encryption functions),
o Operations functions: the system shall be able to:
o Data integrity functions: the system shall ensure data
manage operational readiness of the integrity through monitoring services against improper
fleet/navy forces, information modification or destruction of data.
manage Search and Rescue (SAR)
information, C. C2IS HL external interfaces
support the assessment of progress of This paragraph reports the HL identification of the possible
operations and tasks. external interfaces (see next figure) that can characterize a
Maritime/Navy C2IS:
o Logistic functions: the system shall be able to display
logistics readiness of the fleet/navy force. Moreover,
the system enables the user to identify the most
expeditious route of transit for all classes of supply
displaying current passenger movement;
o Intelligence functions (Navy C2IS): the system shall
enable the user to plan intelligence, reconnaissance
and surveillance operations. The user can exchange
intelligence information according to dissemination
standard (STANAG 4545-digital imagery, STANAG
4609-motion imagery, etc.);
o Spectrum management functions: the system shall be
able to monitor and manage the availability of the
electromagnetic spectrum in regard to connected
sensors;
o Training functions: The system shall provide training
readiness capability;
Figure IV-2: C2IS HL external interfaces
• Military Wide Area Network (MWAN) Interface (Navy C2IS); • TOGAF ADM oriented activities.
• Organizations information systems interface: interfaces with the The level of the WBS reflects the logical breakdown of the work
information systems of the organizations in regards to the and takes into account:
exchange of administrative information, logistic information,
etc.; • The architectural development steps according to TOGAF ADM
(see paragraph II.B.2);
• Symbology libraries interface: the system shall interface with
existing symbology libraries in order to provide specific • The logical architectural building block identified in regards to
representation of system data; the C2IS logical model (see Section IV);
• Planning systems interface: interfaces with (already existing) • The adopted architectural framework (NAF) products (see
planning systems; paragraph II.A.1).
• Administrative and Logistic system interface: the system
provides interface with Administrative System (e.g. to receive
information regarding personnel data) and Logistic System (e.g.
to receive information regarding logistic data);
• Tactical Data Links (TDL) interfaces (e.g. Link11, Link16, Link
22);
• AIS/Warship AIS (WAIS) interfaces (Navy);
• Global Maritime Distress and Safety System (GMDSS)
interface;
• Distributed Interactive Simulation (DIS) interface for training
purposes;
• Interfaces with the system of friendly organization and
coalitions: e.g. NATO Friendly Force Information (NFFI)
interface protocol, Multilateral Interoperability Program (MIP)
interface, NATO Coalition Shared Database (CSD) interface,
etc.; Figure V-1: Work Breakdown Structure
• Vessel Tracking System (VTS) Interface;
The previous figure introduces the Work Breakdown Structure
• Geographic Information System (GIS) Interfaces: according to (WBS) defined for the execution of the activities and identifies the
main standard and commercial format e.g. Open Geospatial identified Work Packages (WPs). The WP1, WP2 and WP3 apply the
Consortium (OGC), Keyhole Markup Language (KML), etc. TOGAF ADM phases (A, B, C, D and E) in regards to the definition
of the C2IS architecture.
• Sensor interfaces: interface with radars, surveillance systems
(e.g. camera), weather systems, GPS, etc.; The architectural output of each of this WP is based on the NMM
(see paragraph II.A.2) according to the correspondences between
• Human Machine Interface; TOGAF ADM and NAF (see Section III). Moreover, in regards to the
NSOV definition, the relationships between TOGAF ADM and SOA
• Combat Management System (CMS) interface: interfaces with (see paragraph II.B.3) must to be used as guideline.
the on board CMS(s).
A. Work Package 1 - C2IS NAV, NCV and NOV updating
V. THE WORK BREAKDOWN STRUCTURE
Starting from the needs defined by the Maritime/Navy
The Work Breakdown Structure (WBS) is the focal management organization in regards to C2IS HL capabilities and taking into
tool to plan, monitor, and control the work required for the successful account the TOGAF ADM phases organization, this WP is focused
performance of all the identified activities. on the reviewing of the C2IS capabilities and operational concept
(TOGAF ADM phase A: Architecture Vision).
The WBS specifies the deliverables oriented decomposition of
the products of the architectural design and identifies the
correspondence matrix between:
• the NAF oriented deliverables;
3) Task 2.3 C2IS preliminary NSOV definition (NAV/HL
NSOV).
This task will provide the assessment of the C2IS SOA (process,
services, roles and rules) according to the HL NCV e NOV identified
in the previous tasks.
The following NSOV sub views will be specified:
• NSOV-1: Service Taxonomy;
• NSOV-2: Service Definitions.
The updating of the C2IS HL NOV, NCV and NSOV will proceed
according to the C2IS HL architecture reported in the Section IV.
The C2IS NAV (NATO All View) will be specified/updated
during the WP1 tasks execution (see Section III).
Figure V-2: WP1 - ADM and NAF correspondence
According to NAF, the main outcomes of this WP is the updating
of the HL NCV, NOV, NSOV and, consequently, of the NAV (see
B. Work Package 2 - C2IS Architecture definition
paragraph II.A.1)
According to TOGAF ADM phase B (Business Architecture) and
The collection of C2IS NAV, HL NOV, HL NCV and HL NSOV phase C (Information System Architecture), the WP activities will
specifies the Statement Of Work (SOW) related to the C2IS contribute to the finalization of the C2IS NCV, NOV and NSOV.
architectural definition. Moreover, it will produce the preliminary architectural design of
the C2IS (HL NSV).
The list of activities related to each task identified within WP1 is
reported hereafter
1) Task 1.1 Update of the C2IS HL capabilities (NAV/HL NCV)
This task is focused on the support to the updating of the C2IS HL
capabilities (C2IS HL NCV). During this task the following NCV sub
views will be specified starting from Maritime/Navy doctrines,
CONOPS and specifications:
• NCV-1: Capabilities Vision;
• NCV-2: Capability Taxonomy;
• NCV-3: Capability Phasing;
• NCV-4: Capability Dependency.
Figure V-3: WP2 - ADM and NAF correspondence
2) Task 1.2 Update of the C2IS HL operational concepts
(NAV/HL NOV)
The main outcome of this WP is the finalization of the C2IS NCV,
Main objective of this task is the support to the updating of the NOV, NSOV.
C2IS HL NOV (C2IS operational concept). The list of activities related to each task identified within WP2 is
During this task the following NOV sub views will be specified reported hereafter.
starting from Maritime/Navy organization doctrines, CONOPS and
specifications:
1) Task 2.1 C2IS NCV/NOV finalization
• NOV-1: HL Operation Concept Description;
Taking into account the WP2 outcomes, and according to TOGAF
• NOV-2; Operational Node Connectivity Description; ADM, this task will complete the definition of the C2IS NCV and
NOV specifying the:
• NOV-3: Operational Information Requirements;
• NCV-5: Capability to Organizational Deployment Mapping;
• NOV-4: Organizational Relationship Chart.
• NCV-6: Capability to Operational Activities Mapping;
• NCV-7: Capability to Services Mapping,
and the: The system architectural design documentation is produced
according to adopted quality standard (e.g. System/Segment Design
• NOV-5: Operational Activity Model; Document - SSDD and Interface Requirement Specifications - IRS
MIL-STD 498).
• NOV-6: Operational Activity Sequence & Timing Description;
• NOV-7: Information Model.
2) Task 2.2 C2IS NSOV finalization
Starting from the WP1 output and according to TOGAF ADM,
this task will contribute to the finalization of the service architecture
within the C2IS NSOV by specifying:
• NSOV-3: Services to Operational Activities Mapping;
• NSOV-4: Service Orchestration;
• NSOV-5: Service Behavior.
3) Task 2.3 C2IS preliminary NSV definition
Main objective of this task is to contribute to the definition of the
preliminary C2IS SOA infrastructure architecture (see paragraphs Figure V-4: WP3 - ADM and NAF correspondence
II.B.3 and Section III) according to the C2IS building blocks and
interfaces identified in Section IV (consolidated in the previous tasks
of this WP). 2) Task 4.2 C2IS services implementation planning
Specifically will be defined the:
Main objective of this task is to define the C2IS services and
• NSV-1: System Interfaces Description; infrastructures implementation plan that provides a schedule of the
projects that will realize the target architecture.
• NSV-2: Systems Communications Description (identification of
The implementation plan will report also the guideline for the
the communication links between the systems);
prioritization of the services implementation according to the C2IS
architecture identified in Section IV and consolidated in the WP2.
• NSV-3: System to System Matrix (identification of the
functional resources and interactions).
VI. REFERENCES
The WP2 tasks will contribute to the finalization the C2IS 1. United States of America Department of Defense, Department
Concept of Operation – CONOPS. Moreover, the system requirements of Defense Architecture Framework (DoDAF) version 2.00
documentation is issued according to adopted quality standard (e.g. (2009);
System/Segment Specification SSS, MIL-STD 498).
2. United States of America Department of Defense, Department
C. Work Package 3 - C2IS Implementation planning of Defense Architecture Framework (DoDAF) version 2.02
(2010);
Starting from TOGAF ADM phase D (Target Architecture) and
phase E (Opportunities and Solutions), this WP will finalize the 3. NATO NC3 Board: NATO Architecture Framework (NAF) v.3,
association between the systems resources the operational activities to appendix 1 to annex 1 to AC/322-D (2007) 0048 (2009);
be supported. According to NAF, the WP3 will complete the
definition of the C2IS NSV according to the NOV. 4. The Open Group: TOGAF Version 9.1, standard (2011);
Moreover, within WP3 will be established the guideline for the 5. Håvard D. Jørgensen, Tore Liland, and Stein Skogvold:
physical implementation. Aligning TOGAF and NAF – Experiences from the Norwegian
The list of activities related to each task identified within WP3 is Armed Forces (2011);
reported in the following.
6. The Open Group: The Open Group Architecture Framework
1) Task 3.1 C2IS NSV finalization (TOGAF 9) and the US Department of Defense Architecture
Framework (DoDAF), white paper (2010).
Starting from the WP2 output and according to TOGAF ADM,
this task will contribute to the finalization of the C2IS SOA
infrastructure architecture by completing the definition of the NSV
sub views.