It is anticipated that service providers, testing houses and testing tool vendors will use the NGOSS Compliance documentation to help understand and validate the real level of product and solution compliance with the various aspects of the NGOSS program, in a more rigorous and scientific manner than simple text in RFx responses.

The NGOSS Compliance documents highlight business benefits associated with various aspects of NGOSS, and these benefits could be used to help guide OSS component purchase by determining the most important NGOSS principles to achieve his/her requirements. This decision in turn will guide the choice of NGOSS compliance tests with regard to the business-critical aspects of NGOSS that must be adhered to.

OSS components designed in compliance to the NGOSS principles allow for more flexible solutions and a simplification of component integration.  Integration is further eased by the detailed identification of the functions covered by each OSS component.

The NGOSS Compliance activities aim to define how components and solutions may ultimately qualify as being compliant with all the various aspects of NGOSS. The NGOSS Compliance documentation describe the overall testing strategy and approach used, as well as identifying specific tests able to be performed for this NGOSS release.

The goal of the NGOSS Compliance documents is to define a comprehensive suite of tests, which can be used by the industry to validate conformance of individual products and solutions to specific aspects of NGOSS.

The documents define an approach that tests for compliance to most of the core architectural principles, specifically those at the foundation layer. They also highlight the business process and information areas covered by the solution as per the Enhanced Telecom Operations Map® (eTOM) and the Shared Information/Data Model (SID). 

The eTOM, SID and core architectural principles focus primarily on the NGOSS Framework Business and System View activities, with plans to expand into the Implementation and Deployment Views in future releases. 

Additionally, the NGOSS Compliance documentation describes the concept of recording compliance test results using a matrix approach with embedded levels of compliance for some specific matrix elements.  This means that NGOSS testing records whether a solution has been tested against specified core NGOSS principles and when tested, whether it abides to them.  NGOSS testing is also about identifying the business process and informational scope, and in future releases the functional scope that the solution is covering in order to help identify the target point of integration. 

The currently available matrix elements of interest are:

• Core NGOSS principles:
  • Architecture is inherently distributed,
  • Architecture uses interfaces to communicate, also described as Contract Defined Interfaces,
  • Architecture is component-based,
  • Business processes are separated from Component Implementation, also described as Externalized Process Control,
  • Architecture uses shared information and data, also known as the Shared Information/Data Model (SID),
  • Architecture uses a common repository, that encompasses the use of Contract Registration and Trading and a Common Communications Vehicle;
• OSS coverage
  • Business process domain with regard to eTOM,
  • Information domains with regard to the Shared Information/Data Model (SID).