As promised in the first post in this series, we'll now zoom in on the Telemanagement Forum (TMF) and OSS/J. This post will be a bit theoretical, but I promise that the next one will be more practical ;-)
Telemanagement Forum is an organization that strives to improve the interoperability in the Communication Service Provider (CSP) industry through its New Generation Operations Systems and Software (NGOSS) program. Members of the TMF are not only the telco's, but also network equipment vendors and system integrators. All of them provide input to the NGOSS program
NGOSS consists of:
Enhanced Telecom Operation Map (eTOM). Describes the business processes that each CSP typically has to run it's business. The processes are grouped into domains (product, customer, service, resource etc.) as illustrated in the figure on the right. When visiting a CSP you'll often see a more detailed version of this model used as wallpaper.
Shared Information/Data Model (SID) Provides an information model consisting of so-called Aggregate Business Entities (ABE) and the relationships between them. The ABEs do not contain all relevant attributes, it is an abstract model. Even though it is abstract, is has proven to be very useful to ease communication and it is used as a basis for OSS/J. The SID model is organized in domains (eTOM domains) where the entities in a domain have a high degree of cohesion and coupling between the domains is loose.
Technology Neutral Architecture (TNA): This is still under development, but the intention is that it describes the structural underpinnings and building constructs to support analysis, design, implementation and deployment of NGOSS open distributed computing solutions.
NGOSS Compliance test A suite of tests to validate compliance to NGOSS standards
The idea of applying eTOM, SID and TNA of course is to create Lean Operators that can adapt quickly to new market conditions and deliver excellent value to it's customers.
Both eTOM and SID ease communication (both on a human-to-human and machine-to-machine level) by defining a common vocabulary for the CSP industry. For example, when discussing with vendors both can refer to eTOM domains or SID ABEs to specify what they search for (CSP) and what their products cover (vendor).
I've personally used to SID model to do domain modeling several times now. Initially I used to start with my own 'common sense' model, but discovered that I ended up with a model that was less flexible and less complete than the SID one. So now I always start with the SID model and check if there are aspects that can be left out or must be added to meet the business requirements.
The OSS/J APIs focus on Operations Support Systems (OSS) like Trouble Ticketing, Inventory Management and Order Management. The main goal of the OSS/J APIs is to slash the integration costs associated to the integration of Operations Support Systems. Initially the OSS/J Community was a separate organization, but since the summer of 2006 it is an integral part of the TMF. TMF stated that OSS/J is the preferred way to implement the concepts layed out in TMFs SID. Since the start of the OSS/J initiative, the Java Community Process has been used to develop the specifications.
OSS/J can be summarized as:
Defining separate OSS/J APIs per eTOM domain, eTOM is used to group functionality into APIs. Currently there are 12 OSS/J APIs defined. Examples are Inventory Management, Order Management, Trouble Ticketing, Billing Mediation. One of the APIs is the Common API. This API forms the basis for the other APIs and defines the elements that are used on more than 1 API. Examples of these elements are the 'meta' operations used by clients to discover capabilities of an API implementation and the Managed Entities (see next bullet that are used by multiple APIs. Apart from the Common API, each API can be used independently of the other APIs, however, in some business scenarios it makes sense to use multiple APIs.
Takes the Aggregate Business Entities from SID to define the OSS/J Managed Entities and their relationships. Examples of Managed Entities are Customer, Role, Service, OrderItem. Compared to the ABEs in SID, the Managed Entities are a more concrete representation. However, extension of these Managed Entities is typically needed when implementing an OSS/J API and there are strict guidelines (OSS/J Design Guidelines) that define how Managed Entities may be extended to guarantee interoperability. Integration costs are reduced because all OSS/J APIs base their Managed Entities on the SID ABEs, and the Common API defines the Managed Entities shared by multiple OSS/J APIs. As an example, a Order Management server typically needs to integrate with an Inventory Management system to query or update the inventory as orders are processed. Because they use the same (base) definitions for their Managed Entities, this integration is smooth.
Provides 3 integration profiles:
EJB: Tightly coupled and bound to Java.
XML/JMS: Less tightly coupled, asynchronous and could be used with other languages.
WebServices: Loosely coupled and can be used with other languages.Each OSS/J APIs exposes the same functionality through the 3 integration profiles. You can pick the integration profiles that meets your requirements best.
Defines the interaction patterns. Basically there are two main patterns:
Request – Response (or Exception in case of errors): synchronous (or asynchronous in case of JMS integration profile)
Events: Asynchronous, used to inform subscribers of actions that took place (for example: Order state changed)
In addition to these basic patterns, each OSS/J API defines how and in what sequence operations defined in the API should be used.
For each API a fixed set of operations is defined. These operations are used to manage and query the Managed Entities used by the API. Fixed means that it is not possible to add new operations (as opposed to extending the Managed Entities which is allowed and often needed). It is possible to define so-called Named Queries such that you can define specific queries when needed. APIs typically already contain several named queries as part of the API definition.
Sounds complicated? Well to be honest, the learning curve for the first OSS/J API you work with is a bit steep. However, once you know one, the others are pretty simple and the initial efforts starts to pay off.
Demand in the marker for products that comply to the OSS/J specifications is increasing. This of course convinces vendors to make their products OSS/J compliant (see certified products) and also creates a market for companies that build adapters that can provide a OSS/J compliant interface to non-compliant products.