This paper reports on experiences from defining the architectural design method related to the definition of a maritime Command and Control Information System (C2IS). The adopted design strategy has chosen TOGAF as architecture development methodology (ADM) and NATO Architecture Framework (NAF) for metamodel and content organization. In order to make TOGAF and NAF work together and address the particular requirements of C2IS, adaptation and tailoring was required. Starting from related works that have been identified applicable mappings between NAF views and TOGAF ADM phases, it is presented here a possible way to adopt the NAF subviews as TOGAF ADM products in regards to C2IS architectural design method. The presented approach takes into account the system development life cycle identified by quality standard adopted for the software development and documentation. The results of this study are reported also in terms of Work Breakdown Structure (WBS) that presents a deliverables oriented decomposition of the products of the architectural design and acts as a correspondence matrix between deliverables and activities.
Copyright © held by the authors.
Keywords—Architecture Framework, TOGAF Views/Subviews.
The methodologies and the supporting tools for the design of C2IS architecture are specified starting from the identification of:
A framework to adopt in order to document the different elements/meta-elements that define or affect the C2IS architecture. This framework must specify which aspects of the architecture have to be described and in which way, taking into account the interaction with external actors; A design activity method. This method must define the phases of the architectural project specifying the relation between the activities identified in each phase;
A standard modelling language to employ that allows immediate communication between the actors involved in the design and development phases of a C2IS (UML and SysML).
The next section describes the background of the work, and introduces NAF and TOGAF. Section III outlines the integration and adaptation that went into designing a customized architecture framework. Section IV reports on maritime C2IS High Level (HL) architecture and main building blocks according to TOGAF Architecture Development Methodology (ADM). Section V proposes the Work Breakdown Structure (WBS) related to the C2IS architectural design activities. The WBS is based on the TOGAF ADM phases and the related deliverables are aligned with the NAF products.
The NATO Architectural Framework (NAF) provides the rules, guidance, and products for developing and presenting architecture descriptions that ensure a common denominator for understanding, comparing, and integrating architectures. The application of the Framework enables architectures to contribute most effectively to the acquiring and fielding of cost-effective and interoperable military capabilities. In the following of this document NAF V3 version is considered [3].
In NAF, NATO defines four kinds of architectures: the overarching architecture should look several years into the future and answer the questions of what the enterprise is doing, and why; a reference architecture typically covers a span of a few years, describing how the enterprise functions; 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)
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; NATO Operational View (NOV): it is a description of the tasks and activities, operational elements, and information exchanges required to accomplish the missions. The NOV contains graphical and textual products that comprise an identification of the operational nodes and elements, assigned tasks and activities, and information flows required between nodes; NATO Service-Oriented View (NSOV): it was lately added to NAF to support building architectures based on the concept of a Service-Oriented Architecture (SOA). The NSOV is a description of services needed to directly support the operational domain as described in the NOV; NATO Systems View (NSV): it is a set of graphical and textual products that describes systems and system interconnections providing for, or supporting, organization functions. The NSV associates systems resources to the NOV that support the operational activities and facilitate the exchange of information among operational nodes; NATO Technical View (NTV): It is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements. Its purpose is to ensure that a system satisfies a specified set of operational requirements. The NTV provides the technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed; NATO Program View (NPV): It describes the relationships between capability requirements and the various programs and projects being implemented.
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 information to be managed (see next figure):
NCV and NOV are typically defined at enterprise level but considering the features of the Maritime C2IS an update of these views must be considered during the architecture design development.
Each of these seven views is further decomposed into subviews, which are diagram types for the enterprise architecture models. NAF derives this core structure of views and subviews from the US Department of Defense Architecture Framework (DoDAF) V2.00 [1]. The NAF core structure however it is aligned also with the last release of DoDAF (V2.02) [2].
2)
The NAF Meta Model (NMM) is the information model for NAF, defining the structure of the underlying architectural information that is presented in the Views. NMM makes NAF architectures “modeldriven” (i.e. the views that are presented to the user are snapshots of underlying architectural data that can be stored in the architecture or in a Repository).
The NMM: • • • •
Contains the definitions of all architectural elements identified in NAF; Contains all the allowable relationships between those elements; Provides the specification for XMI (1) file interchange between NAF architecture tools; Is used as specification for configuring the architecture repositories; 1 The XML Metadata Interchange (XMI) is an Object Management Group (OMG) 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 (metamodels).
Is defined as an extension to the UML 2.0 meta-model so that it may also act as a specification for UML profiles (2).
The NMM elements will be used to define the Work Package (WP) output within the proposed Work Breakdown Structure (see Section V).
TOGAF (The Open Group Architecture Framework) is an architecture framework and a tool for assisting in the acceptance, production, use, and maintenance of enterprise architectures. TOGAF is developed and maintained by The Open Group Architecture Forum. It is based on an iterative process model supported by best practices and a re-usable set of existing architectural assets. TOGAF complements, and can be used in conjunction with, other frameworks that are more focused on specific deliverables for particular vertical sectors such as Defense.
The TOGAF Architecture Development Method (ADM) is the result of continuous contributions from a large number of architecture practitioners. It describes a method for developing and managing the lifecycle of enterprise architecture, and forms the core of TOGAF. It integrates elements of TOGAF as well as other available architectural assets, to meet the business and IT needs of an organization.
In the following of this document TOGAF 9.1 version [4] is considered.
1)
TOGAF ADM has matured over more than a decade of industrial experience. Until version 9, it was agnostic of architecture framework and metamodels. It has been widely used with frameworks from Zachman and various modeling tool vendors, and with customized frameworks developed by different industries and organizations.
The following are the key points about the ADM: •
The ADM is iterative, over the whole process, between phases, and within phases. For each iteration of the ADM, a fresh decision must be taken as to: o o o o o o
The breadth of coverage of the enterprise to be defined,
The extent of the time period aimed at, including the number and extent of any intermediate time periods, The architectural assets to be leveraged, including: Assets created in previous iterations of the ADM cycle within the enterprise, Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.); 2 An UML profile provides a generic extension mechanism for customizing UML models for particular domains and platforms
These decisions must be based on a practical assessment of resource and competence availability, and the value that can realistically be expected to accrue to the enterprise from the chosen scope of the architecture work; 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 needs. For example, it may be used in conjunction with the set of deliverables of another framework, where these have been deemed to be more appropriate for a specific organization. 2)
TOGAF 9 covers the development of four architecture domains: Business Architecture: business strategy, organization, and key business processes; governance, Data Architecture: structure of an organization's logical and physical data assets and data management resources; Application Architecture: blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization; Technology Architecture: The software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.
These are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF is designed to support.
The TOGAF ADM defines a recommended sequence for the various phases and steps involved in developing architecture, but it cannot recommend a scope. This has to be determined by the organization itself, bearing in mind that the recommended sequence of development in the ADM process is an iterative one, with the depth and breadth of scope and deliverables increasing with each iteration (see Figure III-2).
Within the ADM are envisioned the follows phases: The Preliminary Phase: describes the preparation and initiation activities required to create an Architecture Capability, including the customization of TOGAF, and the definition of Architecture Principles; Phase A: Architecture Vision describes the initial phase of an Architecture Development Cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals; Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision; Phase C: Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures; Phase D: Technology Architecture describes the development of the Technology Architecture for an architecture project; Preliminary Phase: This is the starting point for adopting SOA and service orientation as architecture principles; • • • • • •
Phase E: Opportunities and Solutions describes the process of identifying major implementation projects and grouping them into work packages that deliver the Target Architecture defined in the previous phases; Phase F: Migration Planning describes the development of a detailed Implementation and Migration Plan that addresses how to move from the Baseline to the Target Architecture; Phase G: Implementation Governance provides an architectural oversight of the implementation; Phase H: Architecture Change Management establishes procedures for managing change to the new architecture; Requirements Management examines the process of managing architecture Requirements throughout the ADM.
The results of these activities, taking into account the goal of this technical proposal and the TOGAF configurability, must be managed within the NAF views products.
TOGAF ADM phases will be used to define the Work Package (WP) within the proposed Work Breakdown Structure (see Section V).
As stated in the previous paragraphs TOGAF is a generic Enterprise Architecture framework.
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.
The objectives of TOGAF and SOA are quite similar. However TOGAF is an architecture framework and SOA is an architectural strategy. Following picture shows as SOA phases can be managed within the TOGAF ADM Phase introduced below:
Phase A: The SOA vision in the architecture is defined highlighting the type of services, its composition and contract, how they support the business processes and its business benefits; Phase B: The information that is central to the business operations which is crucial for SOA is described identifying and defining the portfolio services; Phase C: The application architecture for SOA means groups of loosely-coupled services, the definition of these services and the interaction between them based on the previously defined data models; Phase D: The Technology Architecture for enterprise SOA includes: o o o catalog of SOA run-time infrastructure, SOA development environment, service components technology, and service interface technology, Service/Physical System Matrix that shows which physical systems host the services, Service/Technology Matrix – shows which items in the technology portfolio are used in the performance of which services.
The models provide a view to demonstrate to stakeholders how SOA specific concerns relating to Technology Architecture are addressed.
III. ADOPTING TOGAF ADM AND NAF CONCURRENTLY
As commonly done by a number of NATO Agencies and Nations, the proposed approach adopts TOGAF ADM as the architecture development methodology and the NAF to develop meta-models and the architectural contents organization.
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; NAF is a derivative frameworks based on DoDAF.
Following picture shows the relationships between the NAF views and the TOGAF ADM phases [5]:
According to the highlighted correspondences, the NAF views related to the Maritime C2IS architecture are defined during the related TOGAF ADM phase/phases.
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 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 standards, selected products and services from suppliers, or shared services already deployed; The References repository provides guidelines, templates, 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. • • • • • • •
IV. C2IS HIGH LEVEL ARCHITECTURE AND BUILDING BLOCKS
This section identifies a possible schema for the C2IS High Level (HL) architecture. The proposed HL architecture is based on the most common C2IS functional and non-functional identified features.
The main aim of a C2IS is to gives Command and Control (C2) capability to the specific organization through improving situational awareness, decision support, interoperability, force readiness assessment and collaboration.
Fundamental Maritime (and Navy) C2 capabilities need to be satisfied are listed below:
Support to mission execution, direction and coordination;
Battleship awareness support (only for Navy C2IS).
These capabilities are achieved starting from on a network organization approach that provides network management functionalities, the information exchange (through wired and radio communication) and enterprise services.
This paragraph identifies the main C2IS service starting from the assumption that the C2 functions must be supported by an information technology services organization web oriented (e.g. SOA). The C2IS services can be classified in the following services groups (see next figure):
Picture management functions: 2D and/or 3D georeferenced visualization of information including vector and raster maps, overlays, terrain elevation data, georeferenced imagery, georeferenced multimedia files, georeferenced object (battlespace object for Navy C2IS). The system enables the user to display and elaborate the geographic information according to different geographic projections and coordinate systems; Symbology (APP6A, NTDS, Custom) management functions: display of appropriate standard symbology associated to system data (APP6/MIL-STD 2525) The system enables the user to edit, display and manage custom symbology; Track management functions (association, correlation, etc.): the system enables the user to (manually or automatically) group, correlate and simulate track information received by the different sensors; Formatted messages (ADatP-3, OTH-Gold, VMF) management functions: the system supports the user in order to receive, visualize, store and edit fix format messages according to standard Message Text Format (MTF); Unformatted messages management functions: the system provides message handling capabilities based on standard technology (e.g. email exchange according to X.400 Recommendations) and taking into account standards (STANAG 4406/ACP126, ACP 133) and implementation guide (ACP 145); Battlespace information management functions (only for Navy C2IS): the system manages the following information coming from all system sources: track data coming from system sources in near-real-time, personnel data ; military unit data, facility infrastructure data, etc.; •
System management services that includes the following functionalities: monitor all services usage and performance, Database management functions: the system shall log any change occurred on a database, System web portal management functions including Multilanguage service, System time management function: the system shall receive automatic time inputs from a Global Positioning System (GPS) and allows the user to manually set the time; Access Services: the system shall be able to control the access to information managed within (e.g. SingleSign-On mechanisms), Data security functions (e.g. encryption functions), Data integrity functions: the system shall ensure data integrity through monitoring services against improper information modification or destruction of data.
Mission plan and order management functions: the system supports the user in managing the operation plans and orders based and on custom or standard (STANAG 2014) template; Alerts and warning management functions: the system enables the user to manage the configuration of alerts and warnings for the system that must to raise in audible and graphical way; Support to collaboration functions: the system shall provide users with the following capabilities: chat (according to XMPP), whiteboard, planner, document management, report and briefing services web portal access; Planning functions: the system provides Decision Aid services to support the user during the decision making process; Operations functions: the system shall be able to: manage operational fleet/navy forces, manage Search information, readiness of
the and
Rescue (SAR) support the assessment of progress of operations and tasks.
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; 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.); Spectrum management functions: the system shall be able to monitor and manage the availability of the electromagnetic spectrum in regard to connected sensors; Training functions: The system shall provide training readiness capability; •
Functional services: it includes services related to:
Information assurance management services that include:
This paragraph reports the HL identification of the possible external interfaces (see next figure) that can characterize a Maritime/Navy C2IS:
Organizations information systems interface: interfaces with the information systems of the organizations in regards to the exchange of administrative information, logistic information, etc.; Symbology libraries interface: the system shall interface with existing symbology libraries in order to provide specific representation of system data; Planning systems interface: interfaces with (already existing) planning systems; 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);
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.;
Geographic Information System (GIS) Interfaces: according to main standard and commercial format e.g. Open Geospatial Consortium (OGC), Keyhole Markup Language (KML), etc. Sensor interfaces: interface with radars, surveillance systems (e.g. camera), weather systems, GPS, etc.;
Combat Management System (CMS) interface: interfaces with the on board CMS(s).
V. THE WORK BREAKDOWN STRUCTURE
The Work Breakdown Structure (WBS) is the focal management tool to plan, monitor, and control the work required for the successful performance of all the identified activities.
The WBS specifies the deliverables oriented decomposition of the products of the architectural design and identifies the correspondence matrix between: • the NAF oriented deliverables;
The level of the WBS reflects the logical breakdown of the work and takes into account:
The architectural development steps according to TOGAF ADM (see paragraph II.B.2); The logical architectural building block identified in regards to the C2IS logical model (see Section IV); The adopted architectural framework (NAF) products (see paragraph II.A.1).
The previous figure introduces the Work Breakdown Structure (WBS) defined for the execution of the activities and identifies the identified Work Packages (WPs). The WP1, WP2 and WP3 apply the TOGAF ADM phases (A, B, C, D and E) in regards to the definition of the C2IS architecture.
The architectural output of each of this WP is based on the NMM (see paragraph II.A.2) according to the correspondences between TOGAF ADM and NAF (see Section III). Moreover, in regards to the NSOV definition, the relationships between TOGAF ADM and SOA (see paragraph II.B.3) must to be used as guideline.
Starting from the needs defined by the Maritime/Navy organization in regards to C2IS HL capabilities and taking into account the TOGAF ADM phases organization, this WP is focused on the reviewing of the C2IS capabilities and operational concept (TOGAF ADM phase A: Architecture Vision). • • • • • • • •
According to NAF, the main outcomes of this WP is the updating of the HL NCV, NOV, NSOV and, consequently, of the NAV (see paragraph II.A.1)
The collection of C2IS NAV, HL NOV, HL NCV and HL NSOV specifies the Statement Of Work (SOW) related to the C2IS architectural definition.
The list of activities related to each task identified within WP1 is reported hereafter 1)
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:
Main objective of this task is the support to the updating of the C2IS HL NOV (C2IS operational concept).
During this task the following NOV sub views will be specified starting from Maritime/Navy organization doctrines, CONOPS and specifications:
NOV-2; Operational Node Connectivity Description; NOV-3: Operational Information Requirements;
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:
According to TOGAF ADM phase B (Business Architecture) and phase C (Information System Architecture), the WP activities will contribute to the finalization of the C2IS NCV, NOV and NSOV.
Moreover, it will produce the preliminary architectural design of the C2IS (HL NSV).
The main outcome of this WP is the finalization of the C2IS NCV, NOV, NSOV.
The list of activities related to each task identified within WP2 is reported hereafter. • • • 1)
Taking into account the WP2 outcomes, and according to TOGAF ADM, this task will complete the definition of the C2IS NCV and NOV specifying the:
NCV-5: Capability to Organizational Deployment Mapping; NCV-6: Capability to Operational Activities Mapping;
NOV-6: Operational Activity Sequence & Timing Description;
2)
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;
3)
Main objective of this task is to contribute to the definition of the preliminary C2IS SOA infrastructure architecture (see paragraphs 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).
NSV-2: Systems Communications Description (identification of the communication links between the systems); NSV-3: System to System Matrix (identification of the functional resources and interactions).
The WP2 tasks will contribute to the finalization the C2IS Concept of Operation – CONOPS. Moreover, the system requirements documentation is issued according to adopted quality standard (e.g. System/Segment Specification SSS, MIL-STD 498).
Starting from TOGAF ADM phase D (Target Architecture) and phase E (Opportunities and Solutions), this WP will finalize the association between the systems resources the operational activities to be supported. According to NAF, the WP3 will complete the definition of the C2IS NSV according to the NOV.
Moreover, within WP3 will be established the guideline for the physical implementation.
The list of activities related to each task identified within WP3 is reported in the following.
1)
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. • • • • • • • • •
The system architectural design documentation is produced according to adopted quality standard (e.g. System/Segment Design Document - SSDD and Interface Requirement Specifications - IRS MIL-STD 498).
Figure V-4: WP3 - ADM and NAF correspondence 2)
Main objective of this task is to define the C2IS services and infrastructures implementation plan that provides a schedule of the projects that will realize the target architecture.
The implementation plan will report also the guideline for the prioritization of the services implementation according to the C2IS architecture identified in Section IV and consolidated in the WP2.
United States of America Department of Defense, Department of Defense Architecture Framework (DoDAF) version 2.00 (2009); United States of America Department of Defense, Department of Defense Architecture Framework (DoDAF) version 2.02 (2010); NATO NC3 Board: NATO Architecture Framework (NAF) v.3, appendix 1 to annex 1 to AC/322-D (2007) 0048 (2009); The Open Group: TOGAF Version 9.1, standard (2011); Håvard D. Jørgensen, Tore Liland, and Stein Skogvold: Aligning TOGAF and NAF – Experiences from the Norwegian Armed Forces (2011); The Open Group: The Open Group Architecture Framework (TOGAF 9) and the US Department of Defense Architecture Framework (DoDAF), white paper (2010).