The NGOSS tools – the business process framework (eTOM), the informtion framework (SID), and the systems integration framework (TNA) form the basis for the NGOSS Lifecycle -- a holistic business driven OSS development approach that covers process definition, system design, solution implementation and solution deployment.

Key to the understanding of the Lifecycle is that the processes of analyzing business requirements, identifying system requirements, modeling a solution, implementing a solution and the deployment of an application themselves make up a lifecycle - this lifecycle may start with a business objective/business requirement and finish with a deployed solution to support and automate the stated requirement. Although the progress through the phases, termed views, of the lifecycle is broadly sequential, it is important to appreciate that an organization may move through the lifecycle in other ways. Project phases may also overlap for example, with some system requirements work taking place at the same time as business analysis. An organization may start by working on implementation view concerns and proceed to represent these as a technology neutral system view so as to develop broader visibility of the potential impacts a pending deployment change may have across the organization. It may also be necessary to iterate within a particular view as the requirements are being further clarified. The important point is that, for any particular solution, the business and technology processes will make up a lifecycle which will pass through various views with clearly identifiable entry and exit criteria.

One of the distinguishing factors of the NGOSS program is its use of a methodology to govern the development of NGOSS styled solutions. The NGOSS Lifecycle is a formalized specification for defining the characteristics and behavior of NGOSS components. It also enables the interests of various stakeholders to be protected by representing the evolution of their interests as the solution progresses from the definition of its business concerns, through a mapping to a particular architecture and implementation, through to deployment. Specifically, the NGOSS Lifecycle contains two planes of interest, the Logical, or Technology Neutral, plane and the Physical, or Technology Specific, plane. These planes intersect with the two perspectives of influence, the Service Provider Perspective and the Service Developers Perspective to yield the four NGOSS Lifecycle Views, as depicted in Figure 1 below.

Thus, NGOSS is not just for developers or business analysts. NGOSS, rather, caters to a wide range of stakeholders that are concerned with different aspects of the problem throughout the entire lifecycle of an NGOSS solution. These stakeholders may be assigned specific responsibilities within the Lifecycle Views that represent the aspects of analyzing, designing, implementing and operating an NGOSS Solution. The NGOSS Lifecycle identifies the four Views as the Business, System, Implementation, and Deployment Views.

In the NGOSS Business View, the eTOM and the SID are used to focus on the concerns of the business: processes, policies, entities and interactions. The eTOM and SID work together to aid in identifying business processes and information entities that support those business processes, which are guided by the governing business policies. The business view represents the goals, obligations, and policies that describe the managed environment and the services that it provides in high-level, technology-independent terms. These various tasks and functions are modeled as interactions in which contracts are used to specify the behavior for how information is exchanged between collaborating entities. Significantly, these models and additional supporting artifacts are collected and carried inside the contract (see TMF053B for more details).

In the NGOSS System View, the SID, the eTOM, and the TNA are used to focus on the system concerns: managed objects, behavior and computational interactions. The system view is primarily concerned with the modeling of system processes and information in a technology neutral manner. Additionally, interactions are used as above; the difference is that in the system view, contracts also specify the behavior (in a technology-neutral manner) for how the functionality can be used to exchange information between the collaborating entities.

The NGOSS Implementation View focuses on how to build hardware, software, and firmware to implement the system being designed. This view uses the NGOSS architectural style to map the technology neutral specification of the solution to a particular target architecture. This mapping may include the use of available off-the-shelf solutions. Again, interactions are used as before; the difference being that contracts will now also contain the implementation artifacts, such as code, technology specific interface definitions, APIs, or Web Service invocations.

Finally, the NGOSS Deployment View is concerned with operating and actively monitoring the system to ensure that the observed behavior is what is expected – if not, then that behavior is adjusted appropriately using the NGOSS behavior and control mechanisms: process and policy based management. Once again, interactions are used to specify the details of the desired behavior. Thus, deployment contracts can contain a wide range of data (e.g., statistical performance data to evaluate the performance of the solution, policies to define specific behavior in response to particular stimuli, and so forth).
The advantage of this approach is that it provides traceability from the business definition and understanding of the solution (represented by the Business View) through the architecture, implementation and deployment definition stages. This NGOSS-styled approach also enables the information and data entities to be refined and extended through further development as each part of the development process is being worked.

One of the fundamental building blocks in any NGOSS-based solution is the Contract. Using the vehicle of the NGOSS Contract (with representation in each NGOSS Lifecycle View) NGOSS moves beyond the traditional focus on Application Programming Interfaces (API) in order to provide an interface definition mechanism that offers end-to-end Lifecycle visibility, traceability and linkage.

The functionality specified by a Contract presents a different view depending on the particular constituency (e.g., the business analyst vs. the programmer) being addressed. This means that a Contract has its own lifecycle, enabling the description, specification and implementation of its functionality to evolve during each phase of the solution. Specifically:

• The Business View of a Contract specifies the high-level goals and obligations that a resource and/or service must supply. This is done using concepts and terminology appropriate for communication and understanding by business personnel.
• The System View of a Contract specifies the computational requirements necessary to design the Contract, as defined by the Business View. This is done in a technical, though technology-neutral, manner appropriate for communication and understanding by the technical staff.
• The Implementation View of a Contract specifies the configuration, programming, and other implementation factors of the components necessary in order to provide the functionality specified by the Contract. This is done using one or more technology-specific mechanisms, including vendor-specific products, devices, protocols, languages, and other artifacts as necessary.
• The Deployment View of a Contract specifies mechanisms for monitoring the performance, cost, and other aspects of the functionality delivered by the Component and for administering the Contract to enable the Contract Instance’s activation and deactivation. This view contains artifacts to monitor the contractual obligations of the solution and to ensure that if those contractual obligations are violated, appropriate corrective action can and will be taken.

In creating a contract, the eTOM is used to establish the proper business context for defining and using the service. The eTOM’s industry vetted descriptions of business processes as well as its hierarchical classification scheme for storing and retrieving descriptions provides a means for ‘sketching out’ the desired sequence of activities that describe the new service. All the data that will be used and exchanged in a Contract invocation are defined using the SID, thereby enabling the common information to be shared and reused.

Taken collectively, the deliverables packaged as NGOSS provide a Lifecycle Framework supported by an Architecture that provides the necessary constructs for the Methodology to be used to assemble reference artifacts extracted from the eTOM and SID in order to express a specific View on the concerns of the key stakeholder constituents by capturing their requirements as Use Cases and a specification of points of solution interoperability as Contracts. Adherence to this NGOSS-styled approach for OSS/BSS solution creation is gauged using the Compliance test criteria.

The NGOSS Lifecycle and Methodology approach provides traceability, from Business needs through the System, Implementation and Deployment Views of the solution, as well as traceability describing how policies, processes, information processing entities and other NGOSS artifacts, interacting through Contracts, are formed into a Component based solution (see
Figure 2).

By balancing the implementation and deployment views against the business and system views, through use and application of the NGOSS Lifecycle and Methodology, it becomes possible to re-use and refine existing specifications, models and designs in a controlled manner. By making use of these abstractions, you can avoid having to make technology decisions too early; rather, the focus can be put on refining and evolving businesses processes, policies and models. By moving work into this logical realm, it becomes possible to map decisions onto more than just one implementation solution. In fact, the solution decisions documented in the logical realm become ‘blueprints’ ready for re-use and application in other areas of the business, which may be governed by different implementation choices but can still re-use the solution blueprint.