Chapter 3. NISP Structure

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

  • Ease of use for the users of the NISP;

  • Nature of standards, profiles and design rules.

7. The NISP contains the four following main volumes:

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

9. Volume 2 - Agreed Standards: This volume lists agreed interoperability standards. These should support NATO and National systems today and new systems actually under procurement or specification.

10. Volume 3 - Profiles: This Volume provides guidance on the development of Interoperability Profiles and references or includes published profiles. Interoperability Profiles may aggregate references to the characteristics of other profiles categories 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 Systems or Capability Packages and may include descriptions of interfaces to National Systems where appropriate.

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

12. Technology standards will transition through a life-cycle. This life-cycle is used to refine the categorization of standards within volumes 2 and 3 and is 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 standards in the life-cycle shown below in Figure 3.1.

Standards Categories
Figure 3.1. Standards Categories

13. 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. Containment standards have been classified as either fading or retired.

14. 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. NATO STANAG's that are promulgated shall be considered mandatory.

  • Emerging: A standard is considered emerging if it is sufficiently mature to be used within the current or next planned systems. Some emerging standards may not be immediately suitable. For example, commercial companies may not support the standards or the underlying technology is not considered mature. NATO STANAG's that are not promulgated, superseded or cancelled shall be considered emerging.

  • 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. NATO STANAG's that are superseded or cancelled shall be considered retired.

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

3.1. NISP Structure Drivers

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

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

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

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

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