372. SIPs were introduced in the NNEC Feasibility Study [NNEC FS] and further defined in subsequent NATO documents. In essence:
373. SIP describes the stack-of-standards that need to be implemented at an interface, as described in the [NNEC FS]
374. SIPs are technology dependent and are subject to change - provisions need to be made to allow SIPs to evolve over time (based on [NNEC FS])
375. SIP represents the technical properties of a key interface used to achieve interoperability within a federation of systems (see [NAF 3.0])
376. SIP reference documents to be provided by NATO in concert with the Nations (see [CESF 1.2])
377. The SIP will not be an isolated document, but will have relationships with many other external and NATO resources, as depicted in the picture Document relationships:
[C3 Taxonomy] – the C3 Taxonomy captures concepts from various communities and maps them for item classification, integration and harmonization purposes. It provides a tool to synchronize all capability activities for Consultation, Command and Control (C3) in the NATO Alliance. The C3 Taxonomy level 1 replaces the Overarching Architecture.
Reference Architectures – defined for specific subject areas to guide programme execution.
[NISP] – provides a minimum profile [9] of services and standards that are sufficient to provide a useful level of interoperability.
[SOA Baseline] – recommends a set of standards to fulfil an initial subset of the Core Enterprise Service requirements by providing a SOA baseline infrastructure. As such, it is intended to be incorporated into the NISP as a dedicated CES set of standards.
SIPs - will provide a normative profile of standards used to implement a given service. As such it provides further clarification to standards as provided in the NISP/SOA Baseline. The SIP may also contain NATO specific and agreed extensions to given standards.
There will be multiple national/NATO implementations of a given SIP. These implementations must implement all mandatory elements of a SIP and in addition can provide own extensions, which can be documented in a Nationally defined document, e.g. in a form of a Service Description Sheet.
378. The process, governance and the responsible bodies for the SIPs need to be urgently determined. This includes the implementation of a repository to store the different artefacts.
[9] Please note that word “profile” can be used at different levels of abstraction and slightly different meanings. In the NISP context, “profile” means a minimal set of standards identified for a given subject area (e.g. AMN Profile, CES/SOA Baseline Profile). In the context of SIP, “profile” means more detailed technical properties of an interface specified with a given standard(s).