The NGOSS Lifecycle and

Methodology
Release 4.5

GB927

Member Evaluation November, 2004

TeleManagement Forum 2004
The NGOSS Lifecycle Methodology Page ii

Notice

The TeleManagement Forum (“TM Forum”) has made

every effort to ensure that the contents of this
document are accurate. However, no liability is
accepted for any errors or omissions or for
consequences of any use made of this document.

This document is a draft working document of TM

Forum and is provided to its members solely for formal
comments and evaluation. It is not a Forum Approved
Document and is solely circulated for the purposes of
assisting TM Forum in the preparation of a final
document in furtherance of the aims and mission of
TM Forum. Any use of this document by the recipient
is at its own risk. Under no circumstances will TM
Forum be liable for direct or indirect damages or any
costs or losses resulting from the use of this document
by the recipient.

Members of TM Forum are granted limited copyright

waiver to distribute this document within their
companies. They may not make paper or electronic
copies for distribution outside their companies. The
only purpose of the provision of this draft document to
members is for making formal comments thereon to
TM Forum.

This document may involve a claim of patent rights by

one or more TM Forum members, pursuant to the
agreement on Intellectual Property Rights between
TM Forum and its members, and by non-members of
TM Forum.

Direct inquiries to the TM Forum office:

89 Headquarters Plaza North – Suite 350
Morristown, NJ 07960 USA
Tel No. +1 973 292 1901
Fax No. +1 973 993 3131
TM Forum Web Page: www.tmforum.org

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page iii

EXECUTIVE SUMMARY

Today’s players in the Information, Communications and Technology (ICT) industry -

including service providers and network operators - are facing unprecedented
challenges to simultaneously:

• Lower network operations costs;

• Introduce new generation networking equipment faster and with reduced
integration tax;
• Introduce new communication services more rapidly and adjust their
functionality in response to changing market needs; and,
• Improve customer satisfaction.

Each of these challenges are in and of themselves daunting; however, taken

collectively, they require that service providers and network operators address not
only the technology that they use for Operations Support Systems but also the way
that they specify, develop and deploy those systems. To use a manufacturing
analogy, they need to focus not solely on the product, but also the production line
and how it is organized and operated.

There is growing consensus that the industry needs to move towards a service-
oriented and component based solution allowing for re-use and a lowered integration
tax. However many of the published methods assume a green field situation and a
single technology base.

For established operators, and even new operators, integrating multiple Commercial
off the Shelf packages using existing methods are not easily realizable.

The TMF has developed a technology neutral architecture NGOSS™ (Next

Generation Operations Systems and Services) that is distributed, service-oriented
and supports component based implementations. This architecture can be
specialized to use a variety of base technologies (e.g., Java, XML, CORBA). Much of
the published material to date has focused on defining what NGOSS is.

The NGOSS Lifecycle and Methodology project was established to provide the
industry with a common framework on ‘How to use and deploy NGOSS within an
organization’. It covers the identifying and describing a business problem and
expressing the specification that will be used to direct the development and
deployment of practical solutions that:

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page iv

• Conform to the NGOSS style of problem solving;

• Make use of NGOSS elements contributed from NGOSS projects;
• Use the eTOM, the SID, and the NGOSS technology-neutral architecture.

This document describes the business drivers behind the concept of an NGOSS Lifecycle
and Methodology and how they can be realized:

• Incrementally by organizations with high levels of legacy investment;

• To provide underpinnings for those integrating COTS solutions to meet a new
business need.

After reading this document you will:

• Know how NGOSS can be applied to solving real world problems

• Know the boundary between what the TMF provides and what must be done by
the organisation itself
• Understand how the NGOSS Lifecycle and Methodology processes can be
supported by a toolset and its relation to existing business analysis, design and
development approaches

How to Use This Document

The approach described is focused on ‘How to apply and use’ the TMF NGOSS
elements in the context of an organization leveraging its investment on the back of
industry best practice.

Essentially this document describes how an organization needs to set up its internal
solution development lifecycle processes to take advantage of the NGOSS elements
and results.

Conceptually the NGOSS Lifecycle and Methodologies processes are similar to ISO
9001/2 where the standards describe what processes must be in place and what the
requirements are on those processes at a high level. However the exact way those
processes are realized can vary.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page v

Acknowledgments

This document was prepared by the members of the TeleManagement Forum

NGOSS Lifecycle and Methodology Team:

The NGOSS Lifecycle and Methodology is a genuinely collaborative effort. The TM

Forum would like to thank the following people for contributing their time and
expertise to the production of this document. It is just not possible to recognize all the
organizations and individuals that have contributed or influenced the NGOSS
Lifecycle and Methodology. We apologize to any person or organization we
inadvertently missed in these acknowledgments.

Key individuals that reviewed, provided input, managed, and determined how to
utilize inputs coming from all over the world, and really made this document happen
were:

Name Affiliation
Cliff Faurer TeleManagement Forum
Joel Fleck Hewlett-Packard
Jenny Huang AT&T
Martin Huddleston QinetiQ
David Milham BT
John Strassner Intelliden
Philip Williams BT
Ralph Thompson Popkin

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page vi

About TeleManagement Forum

TeleManagement Forum is an international consortium of communications service

providers and their suppliers. Its mission is to help service providers and network
operators automate their business processes in a cost- and time-effective way.
Specifically, the work of the TM Forum includes:

• Establishing operational guidance on the shape of business processes.

• Agreeing on information that needs to flow from one process activity to

another.

• Identifying a realistic systems environment to support the interconnection

of operational support systems.

• Enabling the development of a market and real products for integrating

and automating telecom operations processes.

The members of TM Forum include service providers, network operators and

suppliers of equipment and software to the communications industry. With that
combination of buyers and suppliers of operational support systems, TM Forum is
able to achieve results in a pragmatic way that leads to product offerings (from
member companies) as well as paper specifications.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page vii

About this document

Document Life Cycle

The NGOSS Lifecycle and Methodology is being issued as Member Evaluation

Version 1.3. It can be considered valid until further notice. The purpose of an
Evaluation Version is to encourage input based on experience of members and the
public as they begin to use the document. Following the Evaluation Period,
documents that are seen to deliver value are candidates for formal approval by the
TM Forum. All documents approved by the TM Forum undergo a formal review and
approval process.

This document will continue under formal change control. Supporting work will be
issued as companions to this document. A document of this type is a “living
document,” capturing and communicating current knowledge and practices. Further
inputs will be made because of detailed work ongoing in the TM Forum and the
industry.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page viii

Document History

Version Date Who Purpose

0.1 2003.12.04 J. Fleck Outline of proposed GB for comment
by Lifecycle Team
0.2 2003.12.09 J. Fleck First draft including comments and text
from Dave Milham, Philip Williams,
Martin Huddleston and Cliff Faurer
0.3 2003.12.11 J. Fleck Updates to include comments and
suggestions from 11 December Team
Meeting and to include new design and
figure for Knowledge Base
0.4 2003.12.15 J. Fleck Included outline sections for
Frameworks and Methodologies
analysis and for SANNR approach.
Moved detailed view of NGOSS
Lifecycle Methodology to end of
Lifecycle section
0.5 2003.12.17 J. Fleck Added Contracts section from John
Strassner, Lifecycle buildup, and
Lifecycle Introduction from Philip
Williams and Jenny Huang. Moved
Encyclopedia section to Next Steps.
0.6 2003.12.18 J. Fleck Added text for most sections on
Framework and Methodologies and
text for build-up of Lifecycle.
0.7 2003.12.18 J. Fleck Added notes for Next Steps and
Conclusions from Lifecycle Team Call,
completed text for Framework and
Methodologies overview and added
text for NGOSS SANRR methodology.
Resolved lots of formatting issues.
0.8 2003.12.19 J. Fleck Added section on Use Cases from
John Strassner, and general
comments from Team.
0.9 2003.12.22 C. Faurer Final Team Draft based on comments
from John S. Dave M. and Martin H.
1.0 2004, Jan TMF Staff Updates prior to Member Evaluation
posting for Release 4.0
1.0a 2004.01.08 J. Fleck Final Version incorporating comments
from SMT and change to clarify the

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page ix

difference between NGOSS Lifecycle

and the NGOSS Methodology.
1.1 2004, April TMF staff Updates as a result of Member
Evaluation Release 4.0.
1.2 2004, J. Fleck Updated version 1.2: a number of
August small changes resulting from member
comments and new section on the
relationship of NGOSS Artifacts.
1.3 2004, TMF Staff Updates prior to Member Evaluation of
November Release 4.5

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page x

Time Stamp

This version of this document can be considered valid until further notice, by which
time it will be updated or reissued.

How to obtain a copy

An electronic copy of this document can be downloaded at the TM Forum Web Site
(www.tmforum.org) at Publications or through a link to Publications from a specific
team’s public project area.

If the document version has only been released to members for review and
comment, the document can only be downloaded from the TM Forum Web Site in
the Members Only Area. Depending upon the document, it could be accessible from
New Items, Evaluation Versions, or a team’s Members Only project area.

If you would like a paper version of this document, please order via the TM Forum
Web Site or contact the TM Forum office. If you are not a member, please contact
the TM Forum office on +1.973.292.1901.

How to comment on the document

Comments must be in written form and addressed to either the NGOSS Lifecycle
Team leader or the TMF staff sponsor for review with the project team. Please send
your comments to the contacts shown below:

Joel Fleck Team Leader [email protected] +1 908.575.8129

Cliff Faurer TMF Staff Sponsor [email protected] +1 720.323.4097

Team Email: [email protected]

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page xi

Table of Contents

Notice ..................................................................................................................................................................ii
EXECUTIVE SUMMARY...................................................................................................................................iii
How to Use This Document...................................................................................................................... iv
Acknowledgments ............................................................................................................................................v
About TeleManagement Forum .....................................................................................................................vi
About this document ......................................................................................................................................vii
Document Life Cycle ................................................................................................................................ vii
Document History.................................................................................................................................... viii
Time Stamp ................................................................................................................................................x
How to obtain a copy..................................................................................................................................x
How to comment on the document ...........................................................................................................x
Table of Contents .............................................................................................................................................xi
Table of Figures..............................................................................................................................................xiii
Introduction ........................................................................................................................................................1
Background........................................................................................................................................................2
Business Context........................................................................................................................................2
Principles (or Overall Approach)................................................................................................................2
NGOSS Lifecycle and Methodology...............................................................................................................4
Why do we care..........................................................................................................................................4
Why it is needed .........................................................................................................................................4
The Four Views of an OSS Lifecycle ........................................................................................................5
Software Development Frameworks and Methodologies........................................................................7
Zachman Framework ............................................................................................................................8
Reference Model for Open Distributed Programming.........................................................................8
Model Driven Architecture.....................................................................................................................9
Unified Software Development Process............................................................................................ 10
The NGOSS Lifecycle – Holistic Visibility of Concerns ......................................................................... 11
NGOSS Lifecycle Logical and Physical Views ................................................................................. 12
NGOSS Lifecycle Service Provider and Service Developer Views................................................. 13
NGOSS Lifecycle Business View ...................................................................................................... 15
NGOSS Lifecycle System View......................................................................................................... 15
NGOSS Lifecycle Implementation View............................................................................................ 16
NGOSS Lifecycle Deployment View ................................................................................................. 16
NGOSS Lifecycle Knowledge Base .................................................................................................. 16
The NGOSS SANRR Methodology ....................................................................................................... 18
Scope .................................................................................................................................................. 20
Analyze................................................................................................................................................ 21
Normalize............................................................................................................................................ 21
Rationalize .......................................................................................................................................... 21
Rectify.................................................................................................................................................. 22
NGOSS Use Cases ................................................................................................................................ 23
The NGOSS Contract ............................................................................................................................. 25

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page xii

NGOSS Contracts Basics .................................................................................................................. 25

Morphing NGOSS Contracts.............................................................................................................. 26
Relationship of NGOSS Artifacts ............................................................................................................ 30
Next Steps........................................................................................................................................................ 33
NGOSS Lifecycle in Detail ...................................................................................................................... 33
Conclusions..................................................................................................................................................... 35
References............................................................................................................................................... 36

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page xiii

Table of Figures

Figure 1. NGOSS Lifecycle: Logical and Physical Views 13

Figure 2. NGOSS Lifecycle: Service Provider and Service Developer Views 14
Figure 3. NGOSS Lifecycle: Business, System, Development and Deployment Views15
Figure 4. NGOSS Lifecycle: NGOSS Knowledge Base 17
Figure 5. NGOSS Lifecycle with Knowledge Base 18
Figure 6. NGOSS Lifecycle using Iteration with SANNR Methodology 19
Figure 7. NGOSS SANRR Methodology Steps 20
Figure 8. NGOSS SANRR Methodology Flow 23
Figure 9. NGOSS Lifecycle: NGOSS Contract Views 26
Figure 10. Interconnection of NGOSS Contract Views 28
Figure 11. NGOSS Use Case Hierarchy 31
Figure 12. NGOSS Artifact Relationships 32
Figure 13. Detailed View of NGOSS Lifecycle 34

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology 1

Introduction

The global communications industry is seeking technological advances that will improve
time to market for new products and services. Technological advances identified and
specified by the TMF’s NGOSS program include a description of common business
processes for the ICT industry (the eTOM), a common information model (the SID), and a
common distributed, technology-neutral architecture (the NGOSS Architecture). However, to
ensure consistent and common usage of all of these elements, a unifying methodology is
needed to facilitate the creation and deployment of a solution compliant with the NGOSS
program.

The NGOSS Lifecycle and Methodology project is providing the industry with a common
framework for the definition of a business problem, and the specification and development of
a deployable solution that conforms to the NGOSS program and makes use of NGOSS
elements from NGOSS projects including the eTOM, the SID, and the NGOSS Architecture.

Phase I of the NGOSS Lifecycle and Methodology project was tasked with the goals of:

• Identifying or developing an NGOSS lifecycle process/architecture/methodology that

provides a framework for the definition, design and development of an NGOSS
Solution using NGOSS constituent elements (NGOSS eTOM, NGOSS SID, NGOSS
Architecture);
• Addressing integration of NGOSS Lifecycle and Methodology processes with user
processes for management of their business and technology lifecycles.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 2

Background

Business Context

Organizations in the communications industry have expended considerable effort in

terms of:

• Analyzing their business (e.g. identifying business drivers, setting goals,

gathering business requirements, understanding business and operational
processes, and evaluating future operating models);
• Identifying system requirements (e.g. system functionality, COTS package
policy and selection, information models, and accessing legacy
applications);
• Solution implementation (e.g. data models, target environments,
technology guidelines, development techniques); and
• Deployment (e.g. specific technology, industrial strength applications, data
replication, performance and quality measures).

The result of these activities forms the processes which are operated by user
organizations for the internal management of their business and technology lifecycles
and the policies which govern their operation. The NGOSS Lifecycle and
Methodology aims to address the integration of these existing user processes,
policies, functionality and information models through the use of the NGOSS
Lifecycle and Methodology processes.

Successful integration will involve recognizing the boundary between what the TMF
can contribute and what must be done by the organization itself and how the
information from the organization and TMF will evolve over time. This requires
placing a strong emphasis on the value offered by a pragmatic, practical and
adaptable approach.

Principles (or Overall Approach)

During the development of the NGOSS Lifecycle and Methodology, a number of

principles have been identified that have governed the overall approach of the
NGOSS Lifecycle and Methodology Team. These principles include:

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 3

• There is a boundary between what the TMF can/should do and what the Target
Organization can/should do. The TMF NGOSS program cannot populate the whole
space.
• There are boundaries between the different lifecycle phases. A key goal of the
NGOSS Lifecycle and Methodology Team is to understand the transformations,
conditions and criteria which apply at these boundaries by developing use cases that
capture these requirements.
• There are also synergies and relationships between the different lifecycle phases.
Another key goal of the NGOSS Lifecycle and Methodology Team is to understand
these interactions by developing use cases and a standard means with which to
exchange knowledge and share and reuse data.
• The standard unit of interoperability is the contract; however, the NGOSS Lifecycle
and Methodology Team must enhance and expand the definition of the contract to
suit the above two objectives.
• There are different communities of interest. Each community must be able to look at
an NGOSS Solution from their own viewpoint.
• A Knowledge Base exists. This Knowledge Base must be made explicit and
comprises information from both the Target Organization and the TMF NGOSS. The
NGOSS Lifecycle and Methodology Team will define the means by which a Shared
Knowledge Base can be defined.
• There is an interaction between the TMF artifacts and the Target Organization
throughout the lifecycle.
• The Contract is used as a container to collect and carry information throughout the
lifecycle, while also being a mechanism for the modification, addition, and morphing
of that information.
• There are associations between similar artifacts in the different phases (e.g.
Business Policy, Policy Model, Policy Spec and Policy Instance).
• The NGOSS Lifecycle and Methodology should be practical, pragmatic, and
adaptable.
• Artifacts should be necessary and sufficient so as to proceed to the next phase.
• Traceability and visibility provide means to verify that required business, system and
implementation processes, policies and functionalities are realized (forward
Traceability).
• Traceability and visibility throughout the lifecycle is necessary to ensure that running
and available services meet the specified needs of the business (backward
Traceability).
• An information model that is shared throughout the lifecycle as a common underlying
foundation for all models is essential to assure specified requirements, processes,
policies and constraints can interoperate and are traceable.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 4

NGOSS Lifecycle and Methodology

The NGOSS Lifecycle and Methodology provides the industry with a common framework on
‘How to use and deploy NGOSS within an organization.’ Its purpose is to show how an
organization can apply the artifacts and thinking from the NGOSS program to its own
processes for business analysis, system requirements, solution design, implementation and
deployment. Up to now, for an organization intending to apply the NGOSS concepts, it has
not been clear how to use, for example, the eTOM process framework , the SID, or the TNA
contracts in their own development processes and operations. Nor has it been clear how the
NGOSS concepts can be combined with what an organization already has in place including
systems engineering methods. The NGOSS Lifecycle and Methodology is intended to
provide practical guidance on these matters.

Why do we care

Total cost of ownership drives us to constantly improve the way we do business in a

competitive environment. In this context, we identify the need for an end-to-end
lifecycle for systems engineering and show that it is a necessary and critical element
for ensuring the delivery of appropriate business solutions. The NGOSS Lifecycle
and Methodology is the TMF approach that seeks to apply coherency to the
otherwise chaotic application of knowledge and methods used in delivering OSS
solutions. To make NGOSS work it is essential to define and explain the NGOSS
Lifecycle and Methodology.

Why it is needed

Agile businesses require agile processes, policies and capability discovery,

development and deployment methods. Lean operators require highly efficient and
low cost solutions. The TMF NGOSS program offers a number of individual products
or artifacts, that, when applied individually, each can bring business benefit. But
when they are combined they effectively bring a step change in business agility and
cost of ownership. The NGOSS Lifecycle and Methodology seek to show how the
combination of individual and community domain knowledge along with combined
methods can bring about this step change.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 5

The Four Views of an OSS Lifecycle

The NGOSS Lifecycle utilizes all the artifacts which are part of the NGOSS
program. It uses the eTOM process framework, the SID, and the NGOSS
architecture to provide a holistic business driven OSS development approach
covering 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 different ways. Views may overlap, for example
some system requirements work may take 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 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. These views have identifiable entry and exit criteria.

NGOSS recognizes, in general, four views in OSS development: business

requirements, system design & modeling, solution implementation and service
operations. The purpose of the NGOSS Lifecycle is to bridge the knowledge,
activity of interests and inputs/outputs produced within each of the four views and
make them a traceable and re-useable asset to the company. The definition of
the four views and applicable NGOSS artifacts for each view is described below:

Business View
This View is about “identification of the business need”. The purpose of the View is to
document the business requirements and all associated business activities that help to
define the business requirements, such as process definition, policies, stakeholders,
resource, etc.

NGOSS Artifacts used/produced:

• In this view there are items relating to the business context, business process
(eTOM “verbs”), business entities (SID “nouns” and “verbs”) and the business
flow. Together these make up a vocabulary for expressing the business

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 6

requirements. They will be expressed using an NGOSS Use Case styled

narrative and captured in the Contract consistent with reuse in later Views;
• SID business view definition and description;
• NGOSS Input: NGOSS Lifecycle Use Case for the Business View;
• NGOSS Output: NGOSS Contract from the Business View.

System View
This is about "modeling the system solution". In this View there is formal
information modeling of business needs and the desired system solution, done
using a “grey box” perspective that places a focus on the points of interoperability
(interactions). There are items relating to system Contracts, COTS capabilities
and policy, process flow in terms of systems, information model, data
specification, built s/w components and built COTS components.

NGOSS Artifacts used/produced:

• SID system view definition and description;
• Distributed computing architecture (TNA);
• NGOSS Input: NGOSS Lifecycle Use Case for the System View +
Business View Artifacts;
• NGOSS Output: NGOSS Contract for the System View + Business View
Artifacts.

Implementation View
This is about "validating the proposed solution". The Implementation View maps
the System View solution models onto target technologies, potentially including a
COTS component base assembly. There are items relating to Contract
implementations, Class instance diagrams, Data models, Execution
environments, Trial/pilot of system solution and Technology Neutral guidelines.

NGOSS Artifacts used/produced:

• Proposed solution model (built using the SID) and proposed distributed
computing harness (specified using the TNA);
• NGOSS Input: NGOSS Lifecycle Use Case for the Implementation View
plus the Artifacts produced in the Business and System Views;
• NGOSS Output: NGOSS Contract for the Implementation View + Artifacts
from the Business View + System View + NGOSS components built from
the Business View and System View contracts and SID.

Deployment View
This is about "realizing the solution". Here there is the observable behavior of the
solution operating in the ‘real world’. There are items relating to Contract
Instances, Components, full-scale run-time solution and technology specific
guidelines.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 7

NGOSS Artifacts used/produced:

• NGOSS Input: NGOSS Lifecycle Use Case for the Deployment View and
Artifacts produced from the Business, System and Implementation Views;
• NGOSS Output: NGOSS Deployment View Contracts + NGOSS Components
built from the Business View + System View + Implementation View +
Deployment View Contracts and SID.

The following sections provide detailed descriptions of the background and root sources
used to create the NGOSS Lifecycle and Methodology. It describes how the Lifecycle
and Methodology function to effectively bridge the knowledge and activities of the four
Views into an OSS development cycle and which systems engineering methods were
borrowed.

Software Development Frameworks and

Methodologies

The past 30 years has seen a dramatic evolution in the science of software
development. From the early efforts (where the development of large systems
was primarily viewed as an art-form or even “black magic”) of the software
engineering pioneers including Frederick Brooks [BROOKS], Edward Yourdon
[YOURDON], and Brian Kernighan [KERNIGHAN] a number of techniques for
developing and managing large scale software projects have emerged. Typically
these techniques deal with either the management of software development
projects or techniques and styles for developing specific software
implementations that facilitate testing, maintenance, and modification.

More recent efforts including the Zachman Framework developed by John

Zachman [ZACHMAN1] [ZACHMAN2], the Reference Model for Open Distributed
Programming [RM-ODP], the Model Driven Architecture (MDA) from the Object
Management Group (OMG) [MDA] and the Unified Software Development
Process (USDP) [USDP] by Jacobson, Booch, and Rumbaugh have extended
these early works to the development of frameworks and methodologies that
follow the whole lifecycle of solution delivery from the specification as business
problems through the deployment of the run-time solution.

One of the initial steps of the NGOSS Lifecycle Team was to perform an analysis
of the available software design frameworks and methodologies and evaluate
their potential for use by the NGOSS program, or if none were found to be
sufficient then build a new methodology, borrowing on their strengths as
appropriate. The analysis identified a number of characteristics and processes
associated with each framework and methodology that the Team felt was
essential to be included in an NGOSS Lifecycle Methodology. This analysis led to
the conclusion that, individually, the frameworks and methodologies did not

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 8

provide the holistic visibility needed to support the vision and principles identified
for NGOSS above. Following is a short analysis of the frameworks and
methodologies investigated.

Zachman Framework
The Zachman Framework, developed by John Zachman at IBM in the late 1980s,
is a framework for defining the constituent parts that make up the whole of a
solution. The framework uses the format of a matrix with rows of the matrix
reflecting the perspective of a particular stakeholder (Planner, Owner, Designer,
Builder, Sub-Contractor) with each column posing questions (Who, What ,
Where, When, Why and How), the answers to which, provide understanding on
each perspective. The Zachman Framework provides a valuable tool for focusing
the definition of a solution and places particular emphasis on providing broad and
strong analysis from an Enterprise point of view. Disadvantages of the Zachman
Framework include:

• No “built-in” methodology. The Zachman Framework is primarily a tool to

facilitate definition and categorization.
• The matrix/cell approach of the Zachman Framework doesn’t encourage
definition of relationships between information, definitions or models.
• As typically used, the Zachman Framework places an emphasis on the
breadth of the definition of the Enterprise while minimizing aspects of
systems, implementation and deployment points of view.

Reference Model for Open Distributed Programming

The emergence of distributing computing technologies and high speed
networking in the late 1980’s created a huge void: technologies existed to build a
solution based on distributed software and systems, but there was no formal
method for specifying, designing and building such solutions. The Reference
Model for Open Distributed Programming (RM-ODP) was developed and
standardized jointly by the ITU-T and ISO to provide a "big picture" for organizing
the pieces of a distributed system into a coherent whole. As a means of
organizing the solution, RM-ODP views a distributed solution from a number of
specific viewpoints:

• Enterprise focuses on the purpose and scope of a solution,

• Information focuses on the semantics of the information used within and
by a solution,
• Computational emphasizes the functional decomposition and interface
definition of distributed components of a solution,
• Engineering spotlights the mechanisms needed to support the distributed
interaction of a solution,
• Technology spotlights the technology selection process that is used to
realize a solution.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 9

Each specified viewpoint of RM-ODP has its own language for articulating that
viewpoint. RM-ODP is a very powerful tool for the designer and developer,
providing representation for each player involved in the development of a
distributed solution (Information and Computational Viewpoints primarily
emphasizing the functional specification, the Engineering Viewpoint focusing on
design, and the Technology Viewpoint concerned with implementation) and a
strong methodology from design through the development phase. Disadvantages
of this approach include:

• Its language is only specified at a very high level and is generally not very
useful in the specification of business missions, goals, processes, policies
or models; this has resulted in RM-ODP seeing the least amount of effort
• The Enterprise Viewpoint doesn’t include a business model
• Different architectural concepts and structuring rules are used in each of
the five viewpoints
• Linkages between the five viewpoints aren’t obvious

Model Driven Architecture

Developed by the Object Management Group (OMG) over the past few years, the
Model Driven Architecture (MDA) provides an architectural means for using
models to analyze business problems, relate those models to system or
technology neutral models and finally the map the system models into technology
specific models. The categories of models specified by MDA are:

• Computation Independent Business Model (CIM) - Specification of the

business and its requirements for the system, done using business rather
than technical language
• Platform Independent Model (PIM) - Formal logical specification of
business functionality supported by the system and system structure,
undistorted by technology details.
• Platform Specific Model (PSM) - Mapping of the PIM to specific
middleware and implementation technologies. Distribution design,
including networking, fail-over, backup and recovery, data replication, and
distributed transactions.

In addition, so as to ensure linkage between the models, MDA requires

correspondences between each model category. For example, a PIM must not
violate its associated CIM and similarly, a PSM must not violate its associated
PIM. It is anticipated that tools will be used to apply standard mapping algorithms
and facilitate the generation of PIM from CIM, and PSM from PIM.

MDA provides the solution architecture world with a very strong decomposition
model which, if applied correctly, ensures that once a business model (CIM) has
been developed, any system model (PIM) or implementation (PSM) developed
from that business model will adhere to its constraints. This mapping has a direct

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 10

correspondence to the Business, Technology Neutral and Technology Specific

Models specified by the NGOSS Program. In addition, the toolsets that are used
to develop the models for MDA (including UML, MOF, XMI and CMW) are used
for the development of NGOSS models.

Considering its strengths, MDA seemed like a natural candidate for the NGOSS
Lifecycle Methodology. However, a number of factors caused some concern:

• MDA is a general model and there is no real emphasis on methodology,

• A widespread perception exists (particularly within the business community)
that Models expressed in UML are too technical and not easy for people at
the business level to review/understand/revise.
• Business rules are embedded in the model and difficult to find and modify,
• Most work using MDA is currently focused on design (particularly in the area
of automatic code generation from PIM to PSM) rather than architecture,
• Current uses tend to be monolithic and hard to use.

Unified Software Development Process

A final framework/methodology investigated was the Unified Software Development
Process (USDP) developed by Jacobson, Booch, and Rumbaugh in the late 1990s.
USDP, while primarily focused on the development of software offers a number of
strong capabilities to any lifecycle methodology. In particular, USDP is driven by use
cases, is explicitly iterative and being strongly rooted in software design and
development is well understood by technical design and development communities.
In addition, by following the USDP roadmap, an organization is able to answer
questions relating to:

• Overall organization of a software system,

• Major organization workflow processes that the system interacts with,
• System software required,
• Application software required,
• Development tools required,
• Hardware devices required,
• Networking and telecommunication requirements,
• Legacy systems involved,
• Standards and policies,
• Non-functional requirements such as reliability, reusability, stability and
performance,
• Distribution requirements,
• Behavior of the interfaces and interactions of the structural elements listed
above as described in collaborations,
• Which structural elements are static (meaning that there is limited or no
capability to change) and dynamic (meaning can be changed to meet the
requirements determined by the use cases).

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 11

Interestingly, the USDP’s strengths are also its disadvantages when considered as
the process for developing NGOSS solutions. For example, USDP provides no
means to represent business rules, little attention is paid to either enterprise or
business models, and the resulting process is focused on software design and
development and perceived as being too complex and technical for input and review
by the business community. In addition, no real guidance on how to build a shared
information model, nor how to apply it, are offered by USDP. Finally, the industry
currently lacks a mechanism to translate well-developed use cases into software in
an automatic fashion.

The NGOSS Lifecycle – Holistic Visibility

of Concerns

After reviewing the various methodologies the conclusion was reached that no single
software framework or methodology met the needs of the NGOSS program and that
the NGOSS Lifecycle and Methodology Team would need to set about to construct
the desired lifecycle and methodology. Rather than construct a completely new
lifecycle and methodology, and to expedite the effort, it was decided to build on the
strengths of the existing works as much as possible, meld the knowledge and
experience from those efforts together and augment the result where gaps were
identified. For example, some of the goals of the effort were to develop a lifecycle
and methodology that:

• Promoted and strongly encouraged linkage between NGOSS eTOM,

NGOSS SID and NGOSS Architecture,
• Emphasized the “consumer” - “provider” relationship for each level of
decomposition,
• Facilitated the identification of “testing” points that can be used to
test/monitor/manage the health of both NGOSS solutions under
development as well as deployed NGOSS solutions,
• Provided a formalized specification of the Business Model/Solution,
• Demonstrated the linkages from the Business Model/Solution to the
technical/realization models (i.e., Architectural Traceability):
o Traceability from the business model/solution through each
level of decomposition & refinement (vertical traceability),
o Traceability from the process model to the data model to the
policy model at each level (horizontal traceability),
• Documented the steps and guidelines for developing an NGOSS
solution using the NGOSS style of problem solving

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 12

Building on the strong shoulders of the efforts that were outlined above, the NGOSS
Lifecycle and Methodology borrowed from the Frameworks and Methodologies as
follows:

• Zachman
o Emphasis on Enterprise and Business Model
o Established a “pattern” of describing concepts and things of
interest to the business
• MDA
o Meta-Models
o Business (CIM) - Technology Neutral (PIM) - Technology
Specific (PSM) separation of concerns
o Ability to use a model to specify architectural artifacts (as the
model changes, code is updated to reflect those changes)
• RM-ODP
o Viewpoints (particularly Information, Computational,
Engineering and Technology)
o Strong support for modeling distributed architectures
• USDP
o Use Case Driven
o Iterative Approach

NGOSS Lifecycle Logical and Physical Views

One of the distinguishing factors of the NGOSS program is its use of a lifecycle,
the NGOSS Lifecycle, to govern its development. From a System Engineering
perspective the realization of the NGOSS Lifecycle requires and is instantiated by
the fusion of the identified aspects from the above and similar methodologies.
From a quality management perspective this states what must be done without
dictating how an organization achieves this. Lifecycle processes can be
introduced, not by a big bang, but as always, cautiously and with extreme
prejudice where operations and real customers may be effected. The introduction
should be a natural extension of current systems engineering practices and fused
into modified or new tools and processes.

The NGOSS Lifecycle is a formalized specification for defining the characteristics

and behavior of NGOSS Components. It enables the interests of various
stakeholders to be expressed and protected by representing the evolution of their
interests throughout the solution as it progresses from the definition of business
concerns, through the mapping to a particular architecture and implementation
technology, and through to its deployment.

Identifying the stakeholders whose interests are represented by the NGOSS

architecture was the first step in developing the NGOSS Lifecycle. This step was
taken by identifying a number of dimensions that the Lifecycle would need to
cover. The first dimension, illustrated by the two planes in Figure 1, is the

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 13

separation of the Physical (or Technology Specific) View from the Logical (or
Technology Neutral) View of the problem/solution space. This separation
decouples the definition of a solution (the Logical View) from actual
implementation and deployed/running instances of that solution (the Physical
View), thus facilitating the development and deployment of multiple equivalent
instantiations from a single solution definition.

NGOSS Lifecycle

Logical
View

Physical
View

Figure 1. NGOSS Lifecycle: Logical and Physical Views

NGOSS Lifecycle Service Provider and Service Developer Views

By further examining the Logical and Physical Views of the NGOSS Lifecycle, it can
be observed that the second dimension to the NGOSS Lifecycle is a dividing of those
planes into pillars of interest: a Service Provider View of interests and a Service
Developer View as illustrated in Figure 2. As illustrated, both Service Providers and
Service Developers have interests that reside within the Logical and Physical Views
of the Lifecycle. The Service Provider focus in the Logical View is the statement of
business problems, business missions, business processes and policies, while their
perspective on the Physical View is one of actual deployment, operations, and
maintenance of a solution. The Service Developer, on the other hand, emphasizes

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 14

the modeling of the solution (i.e., the specification of the business problem as
Technology Neutral models) in the Logical View, and the implementation of those
models using specific technologies in the Physical View.

NGOSS Lifecycle

Logical
View

Physical
View

Service Providers Service Developers

View View

Figure 2. NGOSS Lifecycle: Service Provider and Service Developer Views

Thus, as shown in Figure 3, conceptually there are four quadrants, each representing
the aspects of defining, designing, implementing and operating an NGOSS Solution
and are termed the Business, System, Implementation, and Deployment Views,
respectively. A key advantage of this approach is that it provides traceability from
business definition of the solution through to its architecture, implementation and
deployment specification. It also facilitates that information and data entities will be
more fully developed and more consistent as they are worked through the
development process.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 15

NGOSS Lifecycle

Logical
View Business System

Business Capabilities, System Capabilities,

Constraints & Context Constraints & Context

Deployment Implementation
Physical
View
Implementation Capabilities,
Deployment Capabilities,
Constraints & Context
Constraints & Context

Service Providers Service Developers

View View

Figure 3. NGOSS Lifecycle: Business, System, Development and Deployment Views

NGOSS Lifecycle Business View

In the Business View, the focus of concern is on the business: processes, entities
and interactions. The eTOM and SID are used together to identify and express the
business processes as well as the information entities that must be related and
engaged in interaction in order to successfully support the business need. The
Business View is used to describe the goals, obligations, and policies that will be
used to drive the managed environment and the services offered by the business.
This is done using high-level, technology-independent terms.

NGOSS Lifecycle System View

In the System View, the focus of concern is on system: objects, behavior and
computational interactions. The System View is primarily concerned with the
modeling of system processes and information in a technology neutral manner. The
SID, eTOM and TNA are used collectively to create such a model of the desired
BSS/OSS solution. The various tasks and functions that the business performs are
identified and modeled as collaborations in which contracts are used to specify how
information and functionality is exchanged between the collaborating entities that will
make up the BSS/OSS solution.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 16

NGOSS Lifecycle Implementation View

The Implementation View puts the focus on how to build hardware, software, and
firmware that will implement the system being designed. This View uses the
particular NGOSS architectural style to map from the technology neutral
specifications of the system to a selected target architecture. This mapping may
include using available off-the-shelf solutions and legacy systems as required by the
solution being delivered.

NGOSS Lifecycle Deployment View

Finally, the Deployment View is concerned with operating and actively monitoring the
system to ensure that the observed solution behavior is what is expected – if not,
then the behavior can be adjusted appropriately by using the NGOSS behavior and
control mechanisms of: process and policy based management.

NGOSS Lifecycle Knowledge Base

The NGOSS Lifecycle effort identified the need for visibility and traceability as being
central to the development of a solution which would maintain consistency from the
first identification of the business problem through to the actual execution of the
solution. This is the concept of a central repository of information and is called the
NGOSS Knowledge Base1. The NGOSS Knowledge Base contains three categories
of information:
• Existing Corporate Knowledge, which represents the
accumulated experience collected from operating the
business;
• NGOSS Knowledge including the models, information,
policies and process descriptions identified in the NGOSS
technical program, which includes the eTOM, the SID and
the TNA;
• Community or Shared Knowledge, knowledge which is
common to both NGOSS and a corporation.
It should be noted that none of these categorizations are static; indeed, the NGOSS
Lifecycle anticipates and is designed to encourage the movement and exchange of
knowledge among each of the categories. Figure 4 provides an illustration of the
NGOSS Knowledge Base.

1
The NGOSS Knowledge Base and Change Control processes to extend or modify it are being developed and will be under
the oversight of the NGOSS Steering Team.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 17

NGOSS Lifecycle Knowledge Base

SID
Corporate NGOSS
Knowledge Shared Knowledge
Base eTOM Base

TNA

Figure 4. NGOSS Lifecycle: NGOSS Knowledge Base

Combining the NGOSS Knowledge Base with the previously identified stakeholder
Views, the NGOSS Lifecycle emerges (Figure 5). As knowledge is developed, by
any stakeholder (or third party), in any View, this knowledge is added to the
community Knowledge Base. Thus, there is an interaction between each View and
the Knowledge Base and the Knowledge Base can be used from any View to inspect
information contributed from other Views or by other roles. The NGOSS use of a
shared information model provides the means for ensuring the consistency of the
knowledge as it is viewed from the various perspectives.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 18

NGOSS Lifecycle

Logical
View Business System

Business Capabilities, System Capabilities,

Constraints & Context Constraints & Context
Corporate NGOSS
Knowledge Shared Knowledge
Base Base

Deployment Implementation
Physical
View
Implementation Capabilities,
Deployment Capabilities,
Constraints & Context
Constraints & Context

Service Providers Service Developers

View View

Figure 5. NGOSS Lifecycle with Knowledge Base

The NGOSS SANRR Methodology

As shown in Figure 6, the NGOSS Lifecycle provides an iterative approach for the
analysis, specification, design and development of a solution. Additionally, the
Lifecycle and Methodology Team also recognized the need for iteration to occur
within each View.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 19

NGOSS Lifecycle with Iteration Using Iterate with

Iterate with
SANRR

NGOSS SANNR Methodology

SANRR

Logical
View Business System

Business Capabilities, System Capabilities,

Constraints & Context Constraints & Context
Corporate NGOSS
Knowledge Shared Knowledge
Base Base

Deployment Implementation
Physical
View
Implementation Capabilities,
Deployment Capabilities,
Constraints & Context
Constraints & Context

Service Providers Service Developers

View View

Figure 6. NGOSS Lifecycle using Iteration with SANNR Methodology

To provide a consistent means for iteration both at the Lifecycle loop level as well as
within each View, a methodology has been developed to identify the steps, activities
and outputs associated with the Lifecycle. This methodology is known as the NGOSS
SANRR Methodology (from the first letters of each step). It borrows heavily from
previous work and experience in solution, software and hardware design. The
NGOSS SANRR Methodology (shown in Figure 7 and Figure 8) is itself iterative and
specifies five steps:

• Scope,
• Analyze,
• Normalize,
• Rationalize,
• Rectify.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 20

Applying the SANRR rmethodology to both the NGOSS Lifecycle and to each View it
becomes possible to add an adaptive style that complements the predictive part of the
lifecycle development approach. Thus, NGOSS recognizes and supports the management
desire for planned activity (predictive) while anticipating and preparing for handling the
unexpected vagaries of real world projects.

NGOSS SANRR Methodology

Iterate with
Iterate with
SANRR
SANRR

1. SCOPE : Define Solution Boundary including Solution Mission

Goals, and Business High-Level Use Cases
2. ANALYZE: Document existing (legacy) and desired
environments with detailed Use Cases, Process Maps and
Policy Lists
3. NORMALIZE: Map current view onto common vocabulary to
achieve a “single unified model”
4. RATIONALIZE: Examine normalized model for needed
changes (Gap Analysis, Replication Analysis, Conflict
Analysis). Terminate when no more changes needed
5. RECTIFY: Modify, delete or add functionality to resolve
needed changes identified in Step 4. Once complete, cycle to
Step 3.

Figure 7. NGOSS SANRR Methodology Steps

The purpose, activities and output of each step of the NGOSS SANRR approach are
defined below:

Scope
– Purpose:
ƒ To define the solution boundary by understanding and documenting
business purpose of the solution, the current business environment and
the target business environment. Scoping the solution is necessary to
assure that the goals, missions and objectives of the solution are
consistent throughout the lifecycle, from the Business View through to the
Deployment View.
– Activities:
ƒ Document mission and goals of current business operations targeted for
improvement (i.e., existing environment). If this information has been

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 21

previously documented and is part of the Knowledge Base, this Activity will
make reference to the existing work.
ƒ Document mission and goals of desired business operations
– Outputs:
ƒ Mission Statement(s)
ƒ High Level Use Case(s)

Analyze
– Purpose:
ƒ To document in detail the existing operating environment and the
operating environment desired for the new solution. This step is necessary
preparation for the subsequent identification of missing or duplicated
functionality.
– Activities:
ƒ Identify Processes for improvement/consolidation
ƒ Identify Policies associated with Processes under study
ƒ Identify Information/Data Models associated with Processes under study
ƒ Define target Processes, Policies and Information Model
– Outputs:
ƒ Detailed Use Cases (with linkages to Policies and Processes)
ƒ Detailed Processes with mapping to reference business processes
(eTOM, as appropriate)
ƒ Detailed Policies
ƒ Information Model(s)

Normalize
– Purpose:
ƒ To facilitate interoperation of different Physical Views (technologies,
implementations, and deployments) of the same Logical View statement of
need, and to assure that private pair-wise agreements between services
are kept to a minimum, it is essential that all components of a solution
conform or map to a common “lingua franca”. The output of the
Normalization step of the SANNR methodology provides these mappings
and/or Information Model extensions as appropriate.
– Activities:
ƒ Map Information Models for Processes under study to a common
reference (SID)
– Output:
ƒ Single normalized Information Model (with details on how to map existing
Information Model to normalized Information Model)

Rationalize
– Purpose:

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 22

ƒ The identification of new processes, policies, functionalities and

technologies that need to be designed, developed and/or deployed to
support the new business solution. In addition, any duplicated functionality
(both pre-existing and anticipated as a result of the deployment of new
functionality) will be identified. If the Rationalization phase identifies any
required additions or changes, two actions are possible: Rectify the
required modifications with the next step or return to the Scoping step,
either within the current View or within a previous View, to redefine the
solution boundary to better reflect the desired outcome.
– Activities:
ƒ Perform Duplication Analysis on the existing Processes, Policies and
Information Models to identify redundant functionality
ƒ Perform Gap Analysis between existing Processes, Policies and
Information Model(s) and target Processes, Policies and Information
Model to identify missing functionality
– Outputs:
ƒ List of duplicated functionality (both within existing environment and
between existing environment and target environment)
ƒ List of functionality gaps in existing environment

Rectify
– Purpose:
ƒ To supply new processes, policies and functionality to fill the gaps
identified in the Rationalization, to modify pre-existing functionality,
processes and policies to meet the needs of the new solution, to eliminate
redundant functionality and to update the Knowledge Base (Corporate,
Shared and NGOSS) as appropriate to reflect the new solution and its
environment.
– Activities:
ƒ Fill gaps
ƒ Build new functionality
ƒ Obtain access to pre-existing but unavailable functionality
ƒ Modify existing functionality
ƒ Re-use/retire functionality so as to best meet Business Goals
ƒ Update Knowledge Base to reflect new/modified artifacts
– Outputs:
ƒ New functionality (built, modified or accessibility obtained) to fill identified
gaps
ƒ Replicated functionality removed
ƒ Updated Knowledge Base (both Corporate and NGOSS as appropriate)

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 23

Iterate with

NGOSS SANRR Methodology

Iterate with
SANRR
SANRR

Analyze
Scope (Document Existing and
Desired Problems)

Rationalize
Normalize

Rectify
Deployed
NGOSS
Environment

Figure 8. NGOSS SANRR Methodology Flow

NGOSS Use Cases

A use case describes, through defining a sequence of actions, an agreement

between the stakeholders of a system. Stakeholders are people and other non-
human entities that have a vested interest in the system; they are affected either
directly or indirectly by the use case. The agreement described in the use case
defines the expected behavior of the system and of the stakeholders in addition to
any material, services, and other items or functionality that are exchanged between
the stakeholders of the system. It also describes, through reference to other use
cases, different scenarios that can arise and their behavior.

Stakeholders are defined in terms of a set of roles, which enables the functionality to
be abstracted from the entity performing the function. Use cases always distinguish
between a primary actor and other stakeholders. The primary actor is the stakeholder
that initiates an interaction with the system, in order to accomplish one or more goals.
As the system responds, it also seeks to meet the goals of its other stakeholders.
However, different behavior (usually expressed via a sequence of different actions)
can result in a different sequence of events, with different results.

NGOSS Use Cases are described using templates in order to promote reusability.
Since the four different NGOSS Views each focus on different aspects of the overall
solution, there are four associated NGOSS Use Cases templates from which the Use

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 24

Cases for each View is constructed. Each Use Case is built using a set of core
elements and adds a new set of elements to reflect its particular focus. The invariant
core elements of the different Use Cases enable them to be related to each other,
while the changeable elements reflect new phases and/or options used in building
and delivering the overall solution.

Typically, a Business Use Case will define the overall goals to be achieved, services
to be provided by the solution and the high-level methods of operation. The process
of mapping this business description to a given target architecture will give rise to one
or more System Use Cases. The System Use Cases will in turn be mapped to
specific target technologies which will raise various implementation issues. These are
described in one or more Implementation Use Cases. Finally, Deployment Use
Cases are required to guide the installer, operations personnel, administrative
personnel, and other actors in the installation, deployment, monitoring, and overall
management of the solution.

A key feature of the above NGOSS environment is its ability to be used to codify the
concerns of different stakeholders in a simple, textual narrative that enables different
constituencies to collaboratively describe and define what is need to build this
particular NGOSS solution. The use of templates enables each constituency to
express their own requirements using their own specific vernacular, but remain tied to
the underlying core elements which are essential for providing consistency across
the views.

Requirements and business goals change as a function of business concerns,

obtainable technology, available workers possessing the correct skill sets, and many
other factors. The NGOSS program accommodates these variables by providing a
means to:
• Preserve each Use Case as part of the solution;
• Relate a given Use Case to other appropriate Use Cases;
• Support different information, in the form of goals, requirements, processes,
procedures, and other knowledge, to evolve and morph into new knowledge,
in order to address the changing needs of the environment;
The shared information model (SID) enables Use Cases to be treated as objects in
their own right. This enables them to be easily related to the information entities
(modeled using the SID) themselves. This also enables key knowledge embedded in
these Use Cases to be automatically extracted using enhanced MDA techniques.

The morphing of NGOSS Use Cases is facilitated by enabling these Use Cases to be
treated as objects. As each Use Case changes, a digital history of these changes
can be easily implemented.

In particular, as each Use Case is finalized, it enables objects, processes, policies,

and other NGOSS elements to be described, defined, registered, and advertised to

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 25

other elements. Thus, multiple projects can share the knowledge that is codified in
the Use Cases.

The NGOSS Contract

NGOSS Contracts Basics

The NGOSS contract is the fundamental unit of interoperability in an NGOSS

system. Interoperability is achieved for each of the four views that are defined in the
NGOSS Lifecycle through consistent use of the contract. For example, the Contract
is used to define a specification of a service to be delivered, as well as to specify
information and code that implement the service. It is used to monitor the service and
ensure that any external obligations of the contract (e.g., from an SLA) are met, and
to define what measures to take if they are violated in some way.

The above means that a contract has its own lifecycle, enabling the specification and
implementation of its functionality to evolve during each phase of the solution.
Specifically (illustrated in Figure 9):
• 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 to business personnel.
• The system view of a contract specifies the architectural requirements
necessary to implement the contract, as defined in the business view. This is
done in a technical, though technology-neutral, manner.
• The implementation view of a contract specifies the configuration,
programming, and other implementation factors of the components necessary
to provide the functionality specified in the contract. This is done in one or
more technology-specific manners, using vendor-specific devices and
languages as necessary.
• The deployment view of a contract specifies mechanisms for monitoring the
performance, cost, and other aspects of the functionality delivered by the
contract. It ensures that if the contractual obligations of the contract are
violated, appropriate corrective action can and is taken.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 26

‘Morph’ the Contract

1. Define the Business 2. Architect the Business
(Leadership Team, (Enterprise IT Architects)
Business Process Engineers)
1
Business
1 Contract
Business
Contract Systems
Contract
2

Corporate NGOSS
Knowledge Shared Knowledge
Base Base

1 3
Business Implement
Contract 1 3
Contract
Business Implement
Systems Deployment Contract Contract
Contract Contract
Systems
2 4
Contract
4. Execute the Business 2
(Operations) 3. Implement the Business
(Development Org.)

Figure 9. NGOSS Lifecycle: NGOSS Contract Views

It is convenient to think of the functionality of a contract in terms of a service (even

though resources and other objects are required to deliver the functionality). The
Contract specification covers the functional and non-functional characteristics and
behavior of a service, along with its goals and obligations. Note that the same
Contract can have different obligations to different stakeholders.

All data exchanged in a contract invocation are defined using the SID, which enables
information to be exchanged and reused. The needs of a particular constituency
(e.g., the business analyst vs. the programmer) are accounted for by the use of a
particular View, as previously explained. The NGOSS reference information model
(i.e., the SID) is used to supply information entities to each of the views, and
therefore supports linking them together. It is important to note that this provides
consistent visibility and traceability – information for one constituency isn’t lost in a
transformation, but rather is used as appropriate in other views.

Morphing NGOSS Contracts

A cornerstone of the NGOSS environment is the ability to define a collaborative

development and deployment environment, in which the needs of different
constituencies are seamlessly integrated. That is, NGOSS supports all phases of the

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 27

lifecycle of its system and components, connecting business, system,

implementation, and deployment concerns. The mechanism for doing this is the
Contract; the methodology for doing this is to support the evolution and morphing of
contracts and the knowledge that they contain.

Different constituencies have their own ways of expressing their requirements. The
NGOSS Contract provides the ability for each constituency to express their business
and technical requirements in a standard format. More importantly, such information
is not considered static – the Contract process enables different information in the
contract to evolve and morph (that is, transform existing information according to the
demands of the changing environment to provide new functionality, capability or
meaning) into new information in order to address the changing needs of the
environment. The SID enables these different views to be linked together as a single
cohesive whole.

For example, consider just the QoS [SID QoS] aspects of a Service Level Agreement
(SLA) [SID SLA]. Today, SLAs are currently limited to defining availability (e.g., the
percent of time that the Customer is able to access a particular resource [SID Res],
or use a given service [SID Svc]). Unfortunately, the world is rarely a static
environment. A Customer can change the mix of applications that are being used; a
virus can affect network operations; different business needs can suddenly be
spawned due to economic changes. Traditional systems cannot cope with sudden,
unforeseen changes, and instead try to manually adapt by manually reconfiguring
their networks to support these changes. This leads to the network being divorced
from the needs of the business and consequently, the needs of the Customer [SID
Cust]. What’s needed is to be able to:
• Define performance parameters (e.g., response time and throughput) that are
a function of the current environment and current business needs,
• Define non-functional parameters (e.g., optimize cost),
• Support the ability to negotiate resource and service functionality, availability
and usage,
• Support customer-provider relationships of arbitrary complexity.
Contracts provide a conceptual “container” in which these and other considerations
can be stored. More importantly, Contracts use the SID as their lingua franca,
enabling different constituencies to view the Contract in their own business- and
technology-specific ways. This enables the different actors in the organization, as
well as the different stakeholders involved in the solution, to communicate with each
other.

As a simple example, consider an SLA. It will be written in business terms for

business people to agree on – this is represented by the business view contract.
Clearly, however, a link needs to be made to:
• The System View – how is the architecture affected, and can it support the
goals and objectives set forth in the Business Contract?

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 28

• The Implementation View – how can the architecture be realized in hardware,

software and firmware to implement this Contract?
• The Deployment View – how can this Contract be monitored to ensure that
the terms in the SLA are not violated (and if they are, what corrective action
should be taken).
These views can be conceptually interconnected as shown in Figure 10:

Interconnection of NGOSS Contract Views

Service Provider’s
Customer’s NOC
Contract Issuer
Contract Designer
SLA

deploys
Repository

The Network

Figure 10. Interconnection of NGOSS Contract Views

There are several different types of interactions present in the above diagram. The
Issuer of the contract that represents the Service Provider must understand the
capabilities that are present in the network as well as the business needs of
prospective Customers. (Note that there are many other types of stakeholders that
would need to participate in this offering – Product Designers, Market Analysts,
System Architects, Programmers to mention a few – but this simply reinforces the
need to enable different constituencies to speak a common lingua franca, which in
turn emphasizes the need to enable knowledge describing the concerns of each
constituency to be represented in a common form. That lingua franca is NGOSS and
in particular the SID.)

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 29

When the Service Provider’s Contract Issuer defines the SLA to be offered,
prospective Customers will either accept it as is or try and negotiate some of its
terms. Both of these (and other types of) actions need to be recorded and “follow” the
SLA through its lifecycle. This function is represented by the business contract.

Once the SLA is agreed on, it is stored in a repository, so that it can be installed and
deployed on the system supporting the Contract. At this point, several outcomes are
possible; each can require a series of interactions between the business, system,
implementation and deployment views. Three examples will be given to illustrate this
complex set of interactions:
• The SLA is decomposed into other related forms (SLOs and SLSs2, see [SID
Svc]) so that it can be implemented, tested and then offered to the Customer.
If something goes wrong, then being able to relate what went wrong to entities
representing the contract in its various forms enables the process to be
corrected. It also enables the Service Provider to build a knowledge base that
learns from these problems, so they can be avoided in the future.
• The Customer asks for new features which the Service Provider agrees to
add. The negotiation process needs to be recorded to protect both parties.
However, being able to capture what specifically was changed in the service
offering is important for marketing, product management, and future
engineering. The new features may or may not have ramifications in the
system design and architecture of the offering, and will certainly cause the
service to be reconfigured to meet these new features.
• The environment changes, either because the Customer needs to use
different resources and services, or because of external events (stock crash,
more people than expected subscribing to different variations of the service, a
DDoS3 attack, and so forth). The Customer doesn’t want to renegotiate all
aspects of the Service – he or she simply wants the “right” thing to happen.
This autonomic behavior requires the system to know itself, its capabilities
and constraints, and the environment in which it is operating in (i.e., its
context). More importantly, it requires business goals and obligations to be
“translated” into equivalent forms in the system, implementation and
deployment views. This requires more than a common lingua franca – it
requires a common representation of policy and process management, which
can be used to govern how the solution morphs to suit the changing needs of
the environment.
Thus, it is mandatory that associations between each of these four views are
supported, so that the process of offering the service may fluidly and dynamically be
adjusted. Clearly, if Contracts are implemented as static entities, the above scenarios
cannot be accommodated. However, it is equally important to realize that the above
scenarios require policies, processes and data to change. Put another way,
Contracts establish the current context for delivering a Service, and enable that

2
Service Level Offer and Service Level Specification
3
Distributed Denial of Service

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 30

context to change as necessary. In reality, there is a continuum of Contracts, where

each Contract is visible in one or more of the NGOSS Views.

To ensure that these changes do not compromise the overall solution, it is imperative
that data, policies, processes, and most importantly, knowledge, do not “disappear”
or become disconnected from their changed cousins. Hence, NGOSS Contracts are
designed as dynamic containers that can morph and expand as needed to enable
new and changed knowledge to be stored. This provides visibility and traceability,
from business needs through the architecture, implementation, and deployment of
the solution, as well as visibility and traceability describing how policies, processes,
information processing entities, and other NGOSS Components interact to form a
solution.

Relationship of NGOSS Artifacts

Having described the purpose and general structure in NGOSS of the Use Case and
the Contract, a natural question arises; how are Use Cases and Contracts related
and how do each relate to other NGOSS artifacts, e.g., the eTOM processes,
activities and policies. The first thing to note is that there is not necessarily a one to
one relationship of Contracts to Use Cases. This is natural since in most instances
there will be a hierarchy of Use Cases:

• A high level (or solution driving) Use Case which is a general statement of the
solution mission covering all Views of the NGOSS Lifecycle,

• A high level Use Case for both the Service Provider and the Service
Developer describing the general concerns regarding the solution of each,

• A high level Use Case for both the Logical and the Physical perspective of
the solution,

• A View specific driving Use Case for each NGOSS Lifecycle View which
states the goals of the solution from the perspective of the specific View it
covers,

• and, a series of decomposition Use Cases for each view which references
specific processes, policies, roles and actors that interact to deliver that
portion of the solution.

Thus, it can be seen that a High Level NGOSS Use Case will most likely be related
to a number of (increasing) more focused Use Cases as illustrated in Figure 11.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 31

Use Cases in the NGOSS Lifecycle

High Level
Business System
View Driver Use Case
Use Cases
Stakeholder
Use Cases

Logical and Physical

View Use Cases

Deployment Implementation
View
Sub Use Cases

Figure 11. NGOSS Use Case Hierarchy

At all levels, even at lowest level of decomposition, use cases describe a sequence
of activities and events that occur to cause the goal of the use case to be delivered.
The sequence of activities that are identified in a use case have a direct
correspondence to NGOSS processes (although at the current time most of the
processes described by the NGOSS eTOM focus on the Business View, certainly
processes exist and will be identified for each View). The behavior of each process
and its interaction with its environment is governed by a formalized set of policies
that define actions to be taken depending on environmental stimuli in the form of
events. In turn, each interaction is formally described by an NGOSS Contract. These
relationships are illustrated in Figure 12 It should noted that all NGOSS Artifacts are
defined by the NGOSS SID; this is illustrated by the SID being the background in
Figure 12

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 32

Relationship of NGOSS Artifacts

references Policy
references
containedPolicySets
0..1 PolicyStatement PolicyAction
PolicySet
0..n
1..n

PolicyStatement is used
policyConditionInPolicyRule
by PolicyCondition and
PolicyAction sub classes
1..n 1..n {ordered}
PolicyCondition PolicyGroup PolicyRule 1..n

{ordered} policyActionInPolicyRule

controls
0..n 1..n

isTriggeredBy
controlsExecutionOf
1..n {filled in by triggerConstraints}
PolicyEventSet PolicyEvent
0..1

adjusts
{filled in by executionConstraints}
1 {filled in by eventConstraint} 0..n

hasEvents

references
NGOSS Policies

Custom er
S trateg y, Infrastru ctu re & Pro du ct Op eratio ns

1 2
Name of Field Commentary
Strate gy & Infrastructure Product Opera tions F ulfillmen t Assu ran ce B illing
C om m it Lifecyc le Lifec ycle Supp ort &
M a nagem en t M ana gem ent Rea dine ss

Business System
Use Case Title Business Phase – NGOSS Lifecycle
M ark eting & Offe r M a nagem ent C ustome r Relation ship M a nagem en t
Scope Enterprise: The activities, constraints and artifacts (e.g. business plan) needed to perform the NGOSS Business Lifecycle

Contract Contract
Level Very High Summary
Service D eve lopm en t & M ana gem ent Serv ic e M anage me nt & Ope rations
Audience Anyone that is involved with establishing and operating the Business Phase of the NGOSS Lifecycle

selects
Primary Actor(s) Business Analysts and programme managers in user organizations
Re sourc e Dev elopm ent & M a nagem ent R esou rce M ana gem ent & O peratio ns
(Application, Co m puting an d N etw ork) (App lication , Co m puting an d Netw ork)

Implement
Secondary Stakeholders for System, Implementation and Operations

Deployment
Actor(s) TMF Team members

Supply Chain De velopm ent & M anage me nt Supplier/Pa rtne r R elations hip M an agem ent
Tertiary Actor(s) TMF Members, suppliers, partners, industry analysts

Primary Goals To capture and transform a user organisation’s business goal - based on possible existing systems and organization constraints - into a set of artefacts that express

Contract Contract
references
the Business Requirement in a complete form that meets the pre conditions for the Systems Phase of the NGOSS Lifecycle. Some of these artifacts may be recorded
in the TMF OR the Organisation’s Own Knowledge Base
E nterprise Strategic & B ran d M a nagem ent, Stake hold er & Exte rnal Disa ste r R ec overy ,
M anagement En terp ris e M arket Res earc h & Relation s M anage me nt Security & Fraud
Stakeholder Goals To capture the business goals and needs in a form that can be realized with high fidelity by Systems Implementer’s in an acceptable deployment. Plann ing A dve rtising M ana gem ent

4 3
This methodology uses a Validation Verification AND Testing (VV&T) concept over the full NGOSS Lifecycle. Res earc h &
Fin ancial & Ass et H um an Re sourc es Dev elopm ent, Enterprise Qua lity
M anag em ent M anage me nt Technology M a nagem ent, Proce ss & IT
Policies Used NGOSS Design and lifecycle policies tbd (draft available in J Strassner Policy base Network Management Solutions for the Next Generation) Acqu isition Planning & Arc hitec ture
Organisation’s internal policies

Processes Used Currently Conceptual - NGOSS Knowledge Base processes, extension methodologies for eTOM, SID and NGOSS Contract exploitation.

NGOSS Process NGOSS Contracts

NGOSS Descriptions interfaces
Use Cases defined by
defines
references
Ord er Handling
TEA M DRAFT
© Te leMan agement Forum e TOM Apr il 200 1

Preorder Credit Order Issuance Order Tracking Or de r Completion Customer

Fe asibility A uthorization and Status Satisf action
De te rmination Validation

contains Re ceive Pre-Order

Fe as ibility Request

Issue Pre-Order
Fe asibility Study
Credit
In v estigation
De te rmination

Credit
In v estigation
Order Request
Validation

Order Plan
Dev e lopment
Status
Es ta blishment and
Ma n a gement

St atus Report
Ma na ge Customer
changes to
A g reement Con

Test solution and

d e monstrate to
cust
Con f irm Customer
Value delivery

Billing Satisfaction
Validation

Ob tain Appropriate Order Creation Cu stomer Co nf irm Order Follow up on

Approvals Jeopardy Co mpletion w ith o pt imal Customer
No tification Cu stomer Utilisation

Advise and Ord e r Amendment Co mmitted Date Train the customer

Ne gotiate Re-negotiatio w /
A cceptable Terms Cu stomer

Ord e r Cancellation Validate inf o f or

Assurance and
Bil ling

Re port unmet
c o mmitments or
c a pabilities

NGOSS Activities

Figure 12. NGOSS Artifact Relationships

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 33

Next Steps

NGOSS is about improving the design, deployment and operation of new

generation BSS and OSS solutions. The pieces that make up the whole of
NGOSS – eTOM, SID, TNA and Compliance – are all brought together using the
NGOSS Lifecycle and Methodology to provide the necessary background and
reference structures, materials and guidelines used to increase the visibility and
traceability of concerns across the full solution continuum.

The context of the NGOSS Lifecycle, as described in this paper, forms the
backdrop for determining where to put emphasis into the NGOSS Initiative as it
continues to develop and evolve. Several areas that will require particular focus
are:

o Further definition of the NGOSS Artifacts that are used to represent each of
the Views
o More specific descriptions of the entrance and exit criteria for each of the
Views
o Examples of how to build NGOSS solutions using the eTOM, SID, TNA and
Compliance through adherence to the Lifecycle and Methodology
o Linkage to existing artifacts expressed using XML, Java and CORBA, which
are representative of the Implementation and Deployment Views of NGOSS
o Definition of compliance test points and evaluation criteria and identification of
where they fit into both the Lifecycle and the Methodology

NGOSS Lifecycle in Detail

The vision for the NGOSS Lifecycle is illustrated in Figure 13 with some details on
linkage to a Company’s existing organization. Future work will provide further
definition on how to use the NGOSS Lifecycle to organize knowledge from the
eTOM, SID, TNA and Compliance programs, along with the requisite constructs:
use case, contract and component. Used in concert, they provide a mechanism
for expressing the context, capabilities and constraints across the solution
continuum.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 34

NGOSS Lifecycle
Business System
Tailored Business
Business Scope, Goals, Company Design System
Processes & Mission Standards Processes
Tailored & Procs.
Bus. Policies
Business System
Definition System Contracts
Business Process Definition
Contracts
Tailored Process
Business View Policy Model
Info Model Info Model
Corporate NGOSS
Knowledge Shared Knowledge
Base Base
Contract
Impls.
Process
Instances
Run-Time Implementation
Process Process Processes
Data
Instances Deployment
Environment Implementation Policy
Contract Environment Specs
Instances Policy Data Model
Instances
Deployment Implementation

Figure 13. Detailed View of NGOSS Lifecycle

GB927 v1.3 TeleManagement Forum 2004

 The NGOSS Lifecycle Methodology Page 35

Conclusions

NGOSS is about visibility and traceability linked across the solution continuum. It puts the business
concerns at the forefront to drive a better operating solution that can be more easily monitored to
see if it is meeting the current needs of the business. Communication is key, and the shared
information model provides the means for aligning and integrating the concerns from the various
constituencies into a shared solution.

The heart of NGOSS is technical, and relies on a solid system engineering-based approach and
service-oriented architectural style, heavy on re-use, which yields agile and flexible business
solutions. The emphasis with NGOSS is on ‘before the fact’ decision making through the creation of
solution models rather than ‘after the fact’ production forced-fitting to make things work.

The NGOSS Lifecycle and Methodology have been shown to be very flexible methods that support
starting in any View and moving forward or backward to make visible the set of concerns under
investigation at any given point in time. This 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.

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, to not only
conform to the goals of the Capability Maturity Model, but to strive to reach Level 5 compliance.

NGOSS challenges you to begin to look at the bigger picture and see the road ahead. Through
abstraction, you can avoid having to make technology decisions too early; the focus can then be
put on refining and evolving businesses processes, policies and models. By working in 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 governed by different implementation choices.

The NGOSS Lifecycle and Methodology defines a framework for a new environment suggesting
what an organization must do without prescribing how to do it. It follows the lead of ISO 9000 and
helps you determine ‘how it is that you do business’ and guides you in creating the necessary
model incorporating both your business and your system solution concerns.

Success with NGOSS will be achieved once current business and systems engineering methods
are adapted to accommodate the NGOSS Lifecycle, both in company specific as well as industry
standard business quality systems.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 36

References

Brooks: “The Mythical Man-Month, Essays on Software Engineering,” Frederick

P. Brooks, Addison-Wesley Publishing Company, 1972
Yourdon: “Techniques of Program Structure and Design,” Edward Yourdon,
Prentice-Hall, 1975
Kernighan: “The Elements of Programming Style,” Brian Kernighan, McGraw-Hill,
1974
Zachman1: "A Framework for Information Systems Architecture," John A. Zachman.
IBM Systems Journal, vol. 26, no. 3, 1987. IBM Publication G321-5298.
Zachman2: "Extending and Formalizing the Framework for Information Systems
Architecture," J.F. Sowa and J. A. Zachman. IBM Systems Journal, vol.
31, no. 3, 1992. IBM Publication G321-5488.
RM-ODP “ISO/IEC 10746 Reference Model for Open Distributed Processing - Part
1 – 4,” ISO/IEC, 1995.
MDA “Model Driven Architecture (MDA),” OMG, OMG Document Number
ormsc/2001-07-01, 2001
USDP “The Unified Software Development Process,” I. Jacobson, G. Booch, J.
Rumbaugh, Addison-Wesley 1999
GB 921: “enhanced Telecom Operations Map™ (eTOM), version 3.6,”
TeleManagement Forum, 2003.
GB 922: “Shared Information/Data (SID) Model V 3.0,” TeleManagement Forum,
2003
SID QoS GB922 “Shared Information/Data (SID) Model” Addendum 4S-QoS v1.0,
TeleManagement Forum, 2003
SID SLA GB922 “Shared Information/Data (SID) Model” Addendum 1A v3.0,
TeleManagement Forum, 2003
SID Res GB922 “Shared Information/Data (SID) Model” Addendum 5PR v3.0 &
5LR v1.0, TeleManagement Forum, 2003
SID Svc GB922 “Shared Information/Data (SID) Model” Addendum 4SO v2.0,
TeleManagement Forum, 2003
SID Cust GB922 “Shared Information/Data (SID) Model” Addendum 2 v3.0,
TeleManagement Forum, 2003
TMF053: “The NGOSS™ Technology Neutral Architecture Specification V 3.5,”
The TeleManagement Forum, 2003.
TMF053b: “The NGOSS™ Technology Neutral Architecture Specification; Annex b:
Contract Specification,” The TeleManagement Forum, 2003.

GB927 v1.3 TeleManagement Forum 2004

The NGOSS Lifecycle Methodology Page 37

TMF053c: “The NGOSS™ Technology Neutral Architecture Specification; Annex c:

Behavior and Control Specification,” The TeleManagement Forum,
2003.
TMF053d: “The NGOSS™ Technology Neutral Architecture Specification; Annex d:
Metamodel Specification,” The TeleManagement Forum, 2003.
TMF053f: “The NGOSS™ Technology Neutral Architecture Specification; Annex f:
Distributed Transparency Services Specification,” The TeleManagement
Forum, 2003.
TMF053s: “The NGOSS™ Technology Neutral Architecture Specification; Annex s:
Security Specification,” The TeleManagement Forum, 2003.

GB927 v1.3 TeleManagement Forum 2004