Integrated EA conference London March 09-10 2010 Introduction to Design Rules in NATO NISP Mr Peder Blomqvist CIO Strategist, Swedish Armed Forces (SWAF) CIO Department at the Supreme Commanders Staff CIO strategic and directive program C4I architect Member of NATO Open Systems Working Group since 2005 Mr Niklas Häggström Senior IT-Architect , Centric Labs

Presentation content What Design Rules are and why they are useful NATO Open System Working Group and NISP development How Design Rules are to be incorporated into NATO NISP A walkthrough of the Design Rule for International Military Interoperability

What Design Rules are and why they are useful

Transformation Previous vision New vision Platform-centric, service embedded, large conflict, well established C2 Network-centric, interoperable, joint, integrated, flexible Revolution Existing structure Future structure Evolution

DR reference of importance

Design Rules 1200, The holy Franciscus The holy Franciscus, Il Poverollo, 1182-1226 “A rule excludes permanent wiggling between different alternatives. It makes it possible to follow a defined line. It is not the amount of details, but abeyance to a few directives that is of importance. The directives shall be so short and clear that you immediately can recall them in your memory “The rule should be practical, addressed directly to the sense and shall be personal. Not until you thoroughly have considered the rule, elaborated it carefully, have allowed it to mature and hardened it you should train yourself in being fateful to it”

What is a Formal Design Rule? Design Rule Model 0..n DRP Product VDD Domain DR and DRP references Status Identifier 1 +Owner 0..1 Problem domain Requirements 0..n 1 Verification Method Result Each association between DR:s configured in different DRP:s must also have a corresponding dependency between the involved DRP:s. DR product Version Date Status Identifier Development Status: [Identified, Draft, Proposal, Verified, Rejected, Obsolete] DR Association Validity = Descriptive Validity for each referenced DR: [Normative, Descriptive, Emerging] 0..n 1 +Refers Meta data 1 Analysis THE design rule DR 1 Consequence Problem 1..n Context 1 Solution 1..n 1 0..n Referred DR is mandatory or recommended

Definition of a Design Rule A design rule is a solution to a problem in a specific context with the following characteristics: Belongs to a problem domain Packages knowledge in a reusable form Gives value to the re-user Standardize solutions to design problems within NNEC

What is a Design Rule? A proposed, recommended or mandatory solution on a frequent problem, providing the wanted properties A means to define how architecture concepts or architecture principles shall be implemented May be a generic design pattern, a list of valid standards or a prescribed design or function. (A Design Rule may also describe impropriate or forbidden solutions (antipatterns))

Are not standards enough? Standards – often WHAT but not always HOW How to apply the standard on a specific problem Relations between different standards Applicability in different domains A vast number of standards are applicable for NEC does not mean that complex system work!

Design Rules & Design Design Rules Design Generic generally applicable Mostly non functional Long-lived When following design rules the design work will be ”NNEC compliant” Capability independent What will be realizable in order to meet the functional requirements How will it be practicable Will be used to support the purchasing Some parts will be long-lived and reusable in design work to come when adding new functional requirements Capability dependent

Service Oriented Architecture OASIS SOA Reference model v1.0 adopted by NATO Design Rules Framework

Interoperability Design Rule Focus Areas Flexibility Mobility Scalability Interoperability Security Interoperability Civil Interoperability Legacy Integration International Mil Interop. Produced and used in the Swedish NEC program NISP v4 development phase

NATO Interoperability Standards & Profiles development NOSWG - NATO Open System Working Group NATO Interoperability Standards & Profiles development

Rationale NISP Standards and Profiles NISP v4 --- ADatP34 (D) Vol. 1 Vol. 2 Vol. 3 Vol. 4 Vol. 5 Vol.6 SOA & Design- Rationale NISP Rules Rationale NISP Standards and Profiles MANAGEMENT NEAR TERM MID TERM LONG TERM 0-2 y 3-6 y 6+ y The ISSC, on behalf of the NC3B, was the approval authority for the 5 volume NC3TA The NATO C3 System Interoperability Policy mandate that NATO Common Funded Systems use the mandatory standards in the NATO Common Standards Profile (NISP) and products in the NATO Common Operating Environment (NCOE). Nations indicate their use of the mandatory standards by ratifying STANAG 5524 Standards & Profiles SOA & Design Rules

Categories of Standards Emerging long term - A standard is considered emerging long term if it deals with technology that is expected to be useful in the long term to NATO 6+ years. Emerging mid term - A standard is considered Emerging mid term if it is sufficiently mature to be used within the current or next planned systems 3-6 years. Emerging near term – A standard is considered Emerging near term if it is mature enough to be used within 0- 2 years. Mandatory - A standard is considered mandatory if it is mature to be used immediately. This means that it may both be applied within existing systems and in within future mid term planned systems. Fading - A standard is considered fading if the standard is still applicable for existing systems. The standard however is becoming obsolete or will be replaced by a newer version or another standard. Except for legacy systems or interoperability with legacy systems, the standard may not be used any more. Retired - A standard is considered retired if the standard, that has been used in the past, but is not applicable any more for existing systems. Rejected - A standard is considered rejected if, while it was still emerging, it is considered unsuitable for use within NATO.

How Design Rules are to be incorporated into the NISP Outline - 3 How Design Rules are to be incorporated into the NISP

Design Rule Guidance & DR -International Mil

NISP-NAF Relations Profile description support Actor Profile description support Profile configuration support Profile NISP v4 Architecture NAF v3 what how Standards Design Rules Mission Objectives Capabilities

NISP Profile - NAF relation Strategic views Operational views Services views Systems views

Architecting Phase

Design phase

Architectures & NISP NAF v3.1 NISP Architecture Repository requirements NISP Standards & Profiles Overarching Architecture: Services Framework guidance Reference Architectures: Solution Patterns guidance/mandate Target Architectures: Implementation Architecture Repository

Walkthrough of the Design Rule for International Military Interoperability

Introduction The design rule describes how military organizations can develop and implement the ability to exchange information  with each other to support interoperability issues Much of this design rule can also be applied when exchanging information with other actors than military organizations Definition of interoperability in this context: The ability of technical systems and/or organizations using technical systems to operate together by making (necessary) data & information and/or services produced by one system or organization available to the others, in an agreed format

The Design Rule elements Context Problem Solution Challenges / Issues Principles Solution description Requirements NISP Standards

Context

The International Military Federation To become interoperable and exchange information, actors need to meet somewhere to collaborate, in this design rule, this is referred to as the “federation” In the federation, actors provide services which other actors can use to enable information exchange To create a federation, the actors need to agree upon the rules of the arena, such as which data & information formats and classifications should be used This design rule mainly addresses the technical aspects of the establishment of the federation Organizational, process and legislation aspects must be covered to some extent since all of these needs to harmonize in order to make the collaboration happen

The international military federation Federation domain Federation agreement Actor domain

Scope of the design rule Community of Interest Information Assurance Information Integration Service Management Communication

Problem

Requirements and challenges are identified Basic requirements for information exchange People from the different organisational actors SHALL be able to communicate with each other using voice or text communication. It SHALL be possible to discover and retrieve information (i.e. search) provided to the federation by different actors. Challenges Challenges based on international agreements and regulations Challenges based on national law, national integrity and regulations Challenges based on interpretation of information content Challenges based on technical issues Challenges based on culture, lack of trust and organizational issues Each challenge has a set of related issues

Example - Challenges based on technical issues Architecture and technical implementations of information systems differ The complete technical system will probably not be homogenous, rather a federation of heterogeneous systems Maturity of using architecture and design as governing tools is likely to vary greatly among collaborating parties Agreeing on standards for information exchange is a critical success factor Sovereignty of the parties will increase the complexity of this task There is no governing organ that can make the decisions Without security mechanisms, no information can be exchanged There is a need to have the means to organize and prioritize what to share

Solution

Outline for the solution chapter Architecture for interoperability Key principles The information aspect The security aspect The Information Exchange Gateway Concept Information zones Technology and profiles Discovery services Repository Services Collaboration Services Messaging Services Mediation Services Information Assurance Services Service Management Services Summary

The international military federation architecture Actor internal network Federation network Information Exchange Gateway

Key principles – some examples Sovereignty of collaborating parties Each collaborating party decides which information to publish into the federation View on information Information published into the arena is available to all parties, if no restrictions have been agreed Agreements for Information Exchange Requirements, models, translations and format for information exchange in the arena are regulated by agreements Architecture The technical architecture for information exchange follows the tenets of the Service Oriented Architecture concept Technology Technical services for information exchange uses open standards whenever possible Security Service consumers and service providers use a common methods for authentication and authorization of users and services

The Information aspect - overview A number of areas are addressed for the information aspect: Information Exchange Requirement specifications Information Exchange Models within collaboration areas and their relation to international standards, domain Community Of Interest (COI) models, semantic structures etc Translation specifications and translation mechanisms Specification of information exchange mechanisms in the federation e.g. common data management services, mediation services and bridges to external systems

The security aspect – IEGs and Information zones Information exchange Gateways (IEGs) are used to protect information assets of the participants in the federation. NATO has described an IEG concept which the Design rule reuses Information Zones is a concept identified and defined to achieve confidentiality with high assurance The concept gives the advantage to separate assurance on security mechanisms to meet external and internal threats. Actor info zone IEG Federation info zone

Information discovery Information Assurance Technologies summary Collaboration Information discovery Authorize Authenticate Information Assurance Service Management Route Distribute Protocol Switch Correlate Enrich Transform Messaging Translation Registry Consumer Provider Directory Service discovery

Thank you!