2. 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

3. 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

4. What Design Rules are and why they are useful

5. 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

6. DR reference of importance

7. Design Rules 1200, The holy Franciscus
The holy Franciscus, Il Poverollo,
“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”

8. 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

9. 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

10. 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))

11. 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!

12. 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

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

14. 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

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

16. Rationale NISP Standards and Profiles
NISP v 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

17. 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.

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

19. Design Rule Guidance & DR -International Mil

20. 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

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

22. Architecting Phase

23. Design phase

24. 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

25. Walkthrough of the Design Rule for International Military Interoperability

26. 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

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

28. Context

29. 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

30. The international military federation
Federation domain
Federation agreement
Actor domain

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

32. Problem

33. 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

34. 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

35. Solution

36. 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

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

38. 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

39. 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

40. 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

41. 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

42. Thank you!