The elements of NGOSS fit together to provide an end-to-end system for OSS/BSS development, integration and operations.  The elements of NGOSS may be used as an end to end system to undertake large scale development and integration projects, or may be used separately to solve specific problems.  The elements of NGOSS are as follows:

1) enhanced Telecom Operations Map (eTOM):  The eTOM provides the map and common language of business processes that are used in Telecom Operations.  In addition, process flows are provided for an ever expanding list of key processes.  The eTOM can be used to inventory existing processes at a Service Provider, act as a framework for defining scope of a software-based solution, or simply enable better lines of communication between a service provider and their system integrator.

2) Shared Information/Data Model (SID):  The shared information and data model provides a “common language” for software providers and integrators to use in describing management information, which will in turn allows easier and more effective integration across OSS/BSS software applications provided by multiple vendors.  The SID provides the concepts and principles needed to defined a shared information model, the elements or entities of the model, the business oriented UML class models, as well as design oriented UML class models and sequence diagrams to provide a system view of the information and data.

3)Technology Neutral Architecture and Contract Interface:  These two components make up the heart of the NGOSS integration framework.  In order to successfully integrate applications provided by multiple software vendors, the “plumbing” of the system must be common.  The Technology Neutral Architecture defines architectural principles to guide OSS developers to create OSS components that operate successfully in a distributed environment; and the Contract Interface defines the “API” for interfacing those elements to each other across the architecture.  This architecture is specifically called “Technology Neutral” as it does not define how to implement the architecture, rather what principles must be applied for a particular technology specific architecture to be NGOSS compliant.

4) NGOSS Compliance:  In order to improve the probability that OSS components will truly integrate with each other, NGOSS provides a suite of tests for compliance to the eTOM, SID, architecture, and contract interface components.  NGOSS compliance can be achieved any or all of these components either singly, or in combination with other components.