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.