NGOSS and its suite of tools assist on the transition of the existing business to the “future mode of operation”.

To take on the challenge of changing and enhancing existing business operations and functionality the scope of work can be decomposed into the following:

• Analyze the business (business drivers, business requirements, business and operational processes, future mode of operations)
  
  
• Identify the system requirements (choice of COTS applications, information model)
  
  
• Solution implementation (data models, development techniques)
  
  
• Deployment (industrial strength applications, replication, performance)

The listed activities constitute a life cycle. Phases may overlap and iteration may be necessary.

The use of a life cycle enables processes to be introduced cautiously with prejudice where operations and real customers may be affected. It uses formalized specification for characteristics and behavior of NGOSS components.

The methodology applies the following key principles

• Acknowledge boundaries and synergies between different life cycle phases
• Standard unit of interoperability is the contract
• Different communities require different view points
• A common knowledge base
• Artifacts should be necessary and sufficient to proceed to the next phase
• Traceability provides means to verify that required system and business processes, policies and functionalities are realized
• Traceability ensures that realized business & system processes meet specified business needs
• An information model is shared throughout the lifecycle as common underlying foundation for all models. This is mandatory to ensure that requirements, processes, policies and constraints can interoperate and are traceable

The key activities per phase are as follows.

Business View - Identify the business needs

• Document the business requirements
• Process definition
• Policies
• Stakeholders
• Resources

System View - Modeling the system solution

• Formal information modeling of business needs and desired system solution
• Focus on the points of interoperability
• Deliverables are relating to:
• System contracts
• COTS capabilities and policy
• System process flow
• Information model, data specification
• Built s/w components and COTS components

Implementation View - Validate the proposed solution

• Map system view models onto target technologies, potentially including a COTS components base assembly
• Deliverables are relating to:
• Contract implementations
• Class instance diagrams
• Data models Execution environments
• Trial/pilot of system solution
• Technology neutral guidelines

Deployment View - Realizing the solution

• Observable behavior in the “real world”
• Deliverables are relating to:
• Contract instances

• Components full-scale run-time solution

NGOSS Frameworks and Modeling

NGOSS provides four key frameworks supporting the specification of architecture for managing next generation communications networks.

eTOM

• Enhanced Telecommunication Map
• Business Process Framework

SID

• Shared Information & Data
• Enterprise wide information framework

TNA

• Technology neutral Architecture
• Systems Integration Framework

TAM

• Telecom Applications Framework

These frameworks describe the business, the shared information models and a technology neutral view of the architecture.

These frameworks do however not show

• how to model the artefacts
• what modeling language to use
• how to map existing processes to desired eTOM processes and decompose them
• how to plan an NGOSS omplementation project

There are plenty of good resources available on the internet for best practice on modeling strategies, concepts and methodologies:

For instance:

www.uml.org/
www.agilemodeling.com/
http://www.fmc-modeling.org/
http://www.bpmi.org/
http://www.soamodeling.org/

With the combination of the concepts and principles of NGOSS with a suitable design methodology one can specify the NGOSS solution.

With the application of a suitable project management approach one can plan how and when to make use of the NGOSS artifacts.

Since every modeling approach has its pro’s and con’s it is not so much about what approach to choose but rather about sticking to choice.

In fact the introduction of an NGOSS styled modeling approach requires change management and programme management.

You have to acknowledge that this change is in most cases a cultural change. It changes the way business describes their functions and processes, how system architects model the supporting architecture and how development looks after the implementation. It requires training of analysts, causes natural resistance among all involved departments and is an ongoing refinement process. All this demands strong commitment from management.

NGOSS is also not an all or nothing approach. It works best if one defines one area of change (‘scope’) and starts from there. After having done a first phase one can review what did work and what didn’t. This allows identifying improvement opportunities and applying them in the next phase.

NGOSS Lifecycle and Methodology

The NGOSS lifecycle methodology aims to provide the industry with a common framework on ‘How to use and deploy NGOSS within an organization’. It provides for the identification and description of a business problem and for expressing the specification that will be used to direct the development and deployment of practical solutions that:

• 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

NGOSS consists of a framework of principles and procedures that can be used to guide the development of distributed computing solutions through the creation and re-use of artifacts retained in the knowledge base. The concept of the knowledge base is central to the methodology because it provides a way to “link” work efforts and activities as the progressive views of the system solution are developed.

www.tmforum.org

Each view serves a specific community within the enterprise. The delivered artifacts vary accordingly. The delivery lifecycle process ensures the use of common language elements. Artifacts can be referenced between the views and traceability ensures the adequate realization of business needs.

To take on the challenge of changing and enhancing existing business operations and functionality the scope of work can be decomposed into the following:

• Analyze the business (business drivers, business requirements, business and operational processes, future mode of operations)
  
  
• Identify the system requirements (choice of COTS applications, information model)
  
  
• Solution implementation (data models, development techniques)
  
  
• Deployment (industrial strength applications, replication, performance)

---

Yes, that sound great - but ...

• How will this help me to define and deliver my OSS project?
• What are the supplementing tools and techniques?
• How do these tools interact with each other?
  
• How do I practically appy the tools of NGOSS?

There is no single straight answer to these (and many more) questions (yet). NGOSS is an evolving programme that uses so called catalyst projects to find out what works and what doesn't in the "real world".

I figured using a blog might be the right platform to keep my own working experience with NGOSS in a kind of diary. That way I won't loose my notes (as I usually do with my paper scripts) and share miseries and mysteries with you.