Introduction to Design Rules in NATO NISP

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. Future structure Transformation Previous vision New vision Platform-centric,service embedded,large conflict,well established C2 Network-centric,interoperable,joint, integrated,flexible Revolution Existing structure Evolution

6. DR reference of importance

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

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

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

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

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

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

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

14. NISP v4 --- ADatP34 (D) Vol. 1 Vol. 2 Vol. 3 Vol. 4 Vol. 5 Vol.6 Rationale NISP SOA & Design- Rules Rationale NISP Standards and Profiles MANAGEMENT NEAR TERM MID TERM LONG TERM 0-2 y 3-6 y 6+ y Standards & Profiles SOA & Design Rules

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

16. Design Rule Guidance & DR -International Mil

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

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

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

20. Walkthrough of the Design Rule for International Military Interoperability

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

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

23. Context

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

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

26. Problem

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

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

29. Solution

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

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

32. Key principles – some examples • 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 • 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

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

34. Thank you!