15. For system to system interoperability the NISP should standardize only those services that are relevant to an achievable level of interoperability between NCF systems and between NCF systems and the systems or NII of Coalition partners.

16. There are many NNEC services that are or could be routinely provided within a national NII or an individual system, but which are not relevant to NATO or to a nation's interoperability. An example of the latter might be a distributed print service (i.e. the ability of one computer to issue a print job to a networked printer or to another computer for spooling). This principle states that services not relevant to NCF interoperability or System to system's interoperability should be excluded from the scope of the NISP.

17. For NCF systems or NII the NISP should only standardize those services for which there is clear requirement and that would deliver significant benefit when balanced against the reduction in diversity that such standardization would promote.

18. The standardization of services within NCF systems or NII should only be applied when there is a clear need for a particular service. For a service to be standardized, the potential benefits of standardization such as avoidance of vendor lock-in must outweigh the risks of a possible limited market support.

19. The NISP should only standardize services when there is evidence of a present or near term requirement for such standardization.

20. The scope of the NISP, in terms of the services it specifies, will inevitably change over time. There is a temptation to standardize services just in case a future requirement for their use should arise. Although there may be instances where such pre-emptive action is beneficial, the main effect of such a policy is to foster unnecessary standardization.

21. The NISP should standardize services only where there is sufficient scale of benefit to be gained.

22. There are many standard services that could be potentially beneficial to NCF systems, NII, or in achieving system to system interoperability but their applicability is limited to particular functional niches or the services are needed only by small groups of systems. Unless there is clear benefit from widespread standardization across the NII (with the potential cost and risk penalties of enforcement), the NISP should be silent and the specification of standard services left to a more local level.

23. The NISP should use only open^[1] standards wherever possible when attempting to standardize a service.

24. Products exist that allow IT systems to exchange a wide range of services to achieve a high degree of interoperability; however, some open standards include vendor specific extensions. Therefore it is essential that products be validated against the open standards.

25. Ideally, standardization of a service should only be undertaken where there is an effective open solution. However, there will remain circumstances where effective open solutions do not exist, yet the business benefits of standardization would be significant^[2].

26. The following criteria are suggested to determine whether or not a solution qualifies as being acceptably open from a NISP perspective:

27. Existing standards and profiles implemented in legacy systems should be preferred if they are equal to other candidate standards.

28. There are two reasons why standards already implemented in legacy systems might be preferred: first, they are demonstrated to work and have an experience base; second, and more importantly, migration of legacy systems to a new standard could be infeasible or prohibitively expensive. Standards that are already implemented should form a starting point, unless these are judged no longer appropriate. Subject to their continuing validity, this will lead to a preference for standards implemented in legacy systems. This principle ensures that change is not made purely for the sake of change: however, the NISP is in essence a forward-looking document that should also indicate the (non-legacy) target standard for migration (embodied later in the system evolution principle) to a more current standard and level of capability.

29. For interoperability services, national procurement agencies are encouraged to use the NISP standards, however this should not unacceptably interfere with legitimate national project management or procurement freedoms.

30. The objectives of the NISP require that certain services be standardized across NCF systems and the NII and facilitate interoperability with national NII. However, national projects will need to be individually responsible for specifying national requirements and managing the risks associated with their implementation. NISP standardization aspirations for national systems must therefore be moderated by genuine needs for national project management and control.

31. For NCF systems and the NII the NISP should not standardize services that would interfere with competitive open bidding.