Presentation is loading. Please wait.

Presentation is loading. Please wait.

Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010.

Similar presentations


Presentation on theme: "Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010."— Presentation transcript:

1 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010

2 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 Integrated EA conference London March 09-10 2010

3 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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 Presentation content

4 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 What Design Rules are and why they are useful

5 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Transformation Revolution Evolution Previous vision Platform-centric, service embedded, large conflict, well established C2 New vision Network-centric, interoperable, joint, integrated, flexible Existing structureFuture structure

6 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 DR reference of importance

7 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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 Design Rules 1200, The holy Franciscus

8 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Design Rule Model What is a Formal Design Rule? Problem domain THE design rule Referred DR is mandatory or recommended Problem 1..n Context 1 Solution 1..n 1 0..n Meta data 1 1 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 Analysis DR 1 1 Consequence 0..n DRP Product VDD Domain DR and DRP references Status Identifier 0..n 1 +Owner 1 0..1 0..n Each association between DR:s configured in different DRP:s must also have a corresponding dependency between the involved DRP:s. Requirements 0..n 1 1 Verification Method Result

9 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 A design rule is a solution to a problem in a specific context with the following characteristics: Definition of a Design Rule Belongs to a problem domain Packages knowledge in a reusable form Standardize solutions to design problems within NNEC Gives value to the re-user

10 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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)) What is a Design Rule?

11 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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! Are not standards enough?

12 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Design RulesDesign 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 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 OASIS SOA Reference model v1.0 adopted by NATO Service Oriented Architecture Design Rules Framework

14 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Interoperability Design Rule Focus Areas FlexibilityMobilityScalabilityInteroperabilitySecurity Interoperability Legacy Integration International Mil Interop. Civil Interoperability Produced and used in the Swedish NEC program NISP v4 development phase

15 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 NATO Interoperability Standards & Profiles development NOSWG - NATO Open System Working Group

16 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 NISP v4 --- ADatP34 (D) Rationale NISP Standards and Profiles Vol. 1Vol. 2Vol. 3Vol. 4Vol. 5 MANAGEMENT NEAR TERM 0-2 y Rationale NISP SOA & Design- Rules Vol.6 MID TERM 3-6 y6+ y LONG TERM Standards & Profiles SOA & Design Rules

17 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 How Design Rules are to be incorporated into the NISP Outline - 3

19 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Design Rule Guidance & DR -International Mil

20 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Profile configuration support NISP-NAF Relations Profile NISP v4 Architecture NAF v3 Standards Design Rules how what Mission Objectives Capabilities Actor Profile description support

21 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Strategic views Services views Systems views Operational views NISP Profile - NAF relation

22 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Architecting Phase

23 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Design phase

24 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 NISP Standards & Profiles guidance/mandate Architecture Repository Target Architectures: Implementation Reference Architectures: Solution Patterns Overarching Architecture: Services Framework NAF v3.1 Architectures & NISP guidance requirements

25 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Walkthrough of the Design Rule for International Military Interoperability

26 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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 Introduction

27 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 The Design Rule elements Context Problem Requirements Challenges / Issues Solution Principles Solution description NISP Standards

28 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Context

29 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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

30 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 The international military federation Federation agreement Actor domain Federation domain

31 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Scope of the design rule Community of Interest Information Integration Communication Information Assurance Service Management

32 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Problem

33 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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 Requirements and challenges are identified

34 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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 Example - Challenges based on technical issues

35 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Solution

36 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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 Outline for the solution chapter

37 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 The international military federation architecture Actor internal network Federation network Information Exchange Gateway

38 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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 Key principles – some examples

39 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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 Information aspect - overview

40 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 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. The security aspect – IEGs and Information zones IEG Federation info zone Actor info zone

41 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Technologies summary Service discovery CollaborationInformation discovery Service Management Directory Information Assurance Protocol Switch TransformEnrichRouteDistributeCorrelate Provider Consumer Registry Messaging Authenticate Authorize Translation

42 Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010 Thank you!


Download ppt "Introduction to Design Rules in NATO NISP. Integrated EA conference London March 09-10 2010."

Similar presentations


Ads by Google