Chapter 3. NISP Structure

6. The structure of the NISP is determined by several factors:

  • Ease of use for the users of the NISP;

  • Implementation strategy of the NNEC vision;

  • Nature of standards, profiles and design rules.

7. Partitioning the NISP into timeframes of near and mid-term was influenced by the NNEC FS, national NEC development and industry best practices. One common thread through all these efforts is the need to partition NATO CIS implementations and transition to NNEC into well defined time periods which are:

  • Near-term: 0 to 2 years;

  • Mid-term: 2 plus years;

8. To provide consistency between volumes and improve the tracking of technology trends and influences, each of the volumes has similar structures containing major sections dealing with:

  • Technology

  • Standards

  • Transition

9. These similar structures enable one to focus in on a stakeholders area of interest and to track this area of interest as it transforms towards the NNEC paradigm.

10. The NISP contains the five following main volumes:

11. Volume 1 - Introduction and Management: This volume provides the management framework for the development and configuration control of the NISP and includes the general management procedures for the application of the NISP in NATO C3 systems development and the process for handling Request for Change Proposals (RFCP).

12. Volume 2 - Near Term: This volume provides the interoperability standards and profiles in the near-term period. This is the short term step describing the state of-the-art of NATO and National systems today and the framework for new systems actually under procurement or specification. For new systems, it contains near-term standards, profiles, and technologies to support the initial steps towards Networking and Information Infrastructure (NII).

13. Volume 3 - Mid Term: The focus of Volume 3 is to provide a mid-term perspective having a time frame of 2 to 10 years into the future from the publication of this version of the NISP. The Volume is being held in abeyance as directed by the C3 Board.

14. Volume 4 - Profiles: This Volume provides guidance on the development of Interoperability Profiles and references to published profiles. Interoperability Profiles aggregate references to the characteristics of other profiles types to provide a consolidated perspective. Interoperability Profiles identify essential profile elements including Capability Requirements and other NAF architectural views, characteristic protocols, implementation options, technical standards, Service Interoperability Points, and the relationship with other profiles such as the system profile to which an application belongs. Interoperability profiles will be referenced in the NISP for specified NATO Common Funded System or Capability Package to include descriptions of interfaces to National Systems where appropriate.

15. Volume 5 - Design Rules: This volume provides Guidance on the development of Design Rules and references to published design rules.

16. Technology standards will transition through a life-cycle. This life-cycle is used to refine the categorisation of standards within volumes 2 and 3 and is also a key to providing guidance on the use of standards in the development and transition of NATO CIS. The NISP has adopted the five categories of in the life-cycle of standards shown below in Figure 3.1.

Standards Categories
Figure 3.1. Standards Categories

17. Proposed standards can be accepted as emerging standards in order to follow their developments and decide if they can be promoted to mandatory standards. In some cases proposed standards can be readily accepted as mandatory standards. Emerging standards have been partitioned into specific categories of emerging near-term, and emerging mid-term to better support the transition to NNEC. Similarly, containment standards have been classified as either fading or retired.

18. A short description of each category is described below:

  • Mandatory: A standard is considered mandatory if it is mature enough to be used immediately. This means that it may both be applied within existing systems and in future(mid-term) planned systems.

  • Emerging near-term: A standard is considered emerging near-term if it is mature enough to be used within the 0 - 2 year time frame.

  • 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. This means that it may be applied within future mid-term planned systems; however, they may not be immediately suitable. For example, the standards may not be supported by commercial companies or the underlying technology is not considered mature. In these cases they could be categorized as Emerging far-term.

  • Fading: A standard is considered fading if the standard is still applicable for existing systems; however, it is becoming obsolete, or will be replaced by a newer version, or another standard is being proposed. Except for legacy systems or interoperability with legacy systems, the standard may not be used.

  • Retired: A standard is considered retired if the standard has been used in the past and is not applicable to existing CIS systems.

  • Rejected: A standard is considered rejected if, while it was still emerging, it is considered unsuitable for use within NATO.

19. Each standard in the NISP has categories assigned to it based on the timeframe:

  • Volume 2 - Near-term: Category can be “Mandatory”, “Emerging near-term”, “Fading” or “Retired”

  • Volume 3 - Mid-term: Category can be “Emerging mid-term”; and “rejected”;

  • Volume 3 - Far-term: Category can be “Emerging far-term” and “rejected”.

3.1. NISP Structure Drivers

20. In general, systems development approaches suggest a clean line of reasoning from requirements capturing to architecture, to design and build via testing to implementation and utilization and finally to retirement. In practice, there is not always an opportunity (time or money) for such a "clean" approach and compromises must be made - from requirements identification to implementation. In recognition of this fact, NATO has developed a parallel track approach, which allows some degree of freedom in the systems development approach. Although variations in sequence and speed of the different steps in the approach are possible, some elements need to be present. Architecture, including the selection of appropriate standards and technologies, is a mandatory step.

21. In a top-down execution of the systems development approach, architecture will provide guidance and overview to the required functionality and the solution patterns, based on longstanding and visionary operational requirements. In a bottom-up execution of the approach, which may be required when addressing urgent requirements and operational imperatives, architecture will be used to assess and validate chosen solution in order to align with the longer term vision.

22. The NISP is a major tool supported by architecture work and must be suitable for use in the different variations of the systems development approach. The NISP will be aligned with the Architectural efforts of the C3 Board led by the Architecture Capability Team (Architecture CaT).

3.1.1. NATO Interoperability Standards and Profiles Application to Architectures

23. The relationship of the NISP and the C3 Board Architecture effort is of a reciprocal nature. The architecture products provide inputs to the NISP by identifying the technology areas that in the future will require standards. The architecture products also provide guidance on the coherence of standards by indicating in which timeframe certain standards and profiles are required.

24. The work on RA's and TA's will benefit from the NISP by selecting coherent sets of standards for profiles and design rules.