Common Data Model: Does it worth implementing?

 Frameworx, NGOSS, OSS/BSS Transformation  Comments Off on Common Data Model: Does it worth implementing?
Oct 302012
 

As the name implies, common data model or CIM, is a business (and technical) model of entities that are used during a telecommunication operator’s activities. As the businesses and the operational functions become complex, integrations between tools that are handling those also become complex. Telecommunications, probably the most complex business among the others has been suffering this since it’s beginnings.

In Telco, there are hundreds of entities that can be involved in a business process. And most of the time, these entities are managed by different OSS or BSS components. In order for the process to flow, two or more entities should be shared as information carriers.

The multi-vendor structure of the Telco sector introduces problems in here. The OSS/BSS vendors use entities that are conceptually same but technically different. A customer entity has a customerName attribute in one tool, the same attribute is called “cName” in the other tool. Following the same example, the first tool holds a customer type attribute in Integer type, while the other holds the same in a String type. Obviously, there should be some conversions between these two systems.

To put the understanding of these entities to a common ground, common data model studies have been around since the beginning of the sector. The aim is to simplify the inter-tool integrations. The last concrete effort on hand is the TMForum Shared Information Data Model (SID).

A common understanding requires, abstraction and abstraction means the loss of the details. We can see the loss of the details in the attributes level in the SID model for example. SID, tries to avoid common attribute names rather it tries to spread them to atomic entities. This approach makes the model involve lots of new entities.

TMForum says, SID is an informational model , not a data model , so it rather should be customized to be aligned with the organization. This alignment is done via class extensions or attribute additions. (which different vendors may decide to implement separately)

When I am designing(and developing) a brand new OSS tool, I can use this common model for sure. If the tool I will communicate in the business process uses the same entities(not customized ones), they can communicate (slightly) seamless. But is this the case? Look at the off-the-shelf tools around the Telco business. None of them implements a common information model. Some vendors offering multiple tools in the OSS domain, however implement their own propriety models to improve integration between their components but these are propriety.

Look at the big OSS vendors. Most of these vendors are not interested in this common world. They don’t have OSS/J adapters natively supported for example. They rely on small partners to provide and sell the adapters separately.

Common information model, will dramatically reduce the system integration costs which are not welcomed by these vendors. And this CIM thing will kill an argument like “Buy also TT from us, not from another vendor. Because our TT has seamless integration with our PM tool which we cannot guarantee with the other tool”.

In today’s environment, If I wrote that CIM based brand new tool, I still need to write an adapter that will do the necessary conversions and mappings on the “legacy” tool’s side. (The conversions and mappings can be implemented on the bus if I use an ESB). Even in SID-SID communications, if one side has done some “custom” things such as addition of new classes, the other side should be aligned to that change on the adapter or bus level.

In any case you will write adapters, you will do mappings, you will add validation rules. There will always be some integration effort and if you are not living in the ideal “all SID” world, your additional efforts to aligning to a CIM (SID etc.) will multiply the costs and risks.

Why TAM is “less” popular?

 Frameworx, NGOSS  Comments Off on Why TAM is “less” popular?
Feb 292012
 

OSS is all about automations and tools automate things. Maybe we should pay more attention to TAM rather to eTOM. This is all about marketing indeed. TMForum “sells” eTOM in a very successful way. TAM, on the other hand, seems to be left on one side to it’s destiny.

If you have a look at the documentation differences, you will see that TAM has only 1 reference document attached in contrast with eTOM which have dozens of related documents. You won’t also see any related training directly addressing TAM.

The second reason for this situation is the driver of the standards. The driver of TAM is the service providers themselves not TMForum itself.

However, when you go to the field, the first thing the service providers use for any OSS gap analysis is the TAM framework. eTOM, which should appear first, goes next. Offcourse any transformation activity should start at the processes level but this requires time and effort.

Do you also see TAM more in the picture in your transformation programs?

Feb 152012
 

Anyone who enters the complex world of OSS/BSS transformations, will face different technologies, standards and their terminology they carry with. Management standards depict the terms, and the terms become the language people talk to each other. Take IT for example.  ITIL is the dominating de-facto standard for managing the whole lifecycle of IT services, from birth to death. ITIL sees IT as a function that serves the core business whether it is a restaurant business or a telco. When it comes to telco, as we said, the principle is the same. However, in telco, IT is more “involved” in the business. Even worse, the business cannot live without it.

When we have a look at IT services in a telco, you will see that most of them serve some part of a service that has been served to the customers. Why just some part? What is the other part? The other part is the bearer, the network itself, and it is a separate organization, structure and culture. So the end user service needs IT and Network. (Telcos playing the role, cloud provider, can only serve IT services without Network, however, this is another story.)

This holistic view has been adapted nicely by the TMForum standards where the service that has been “used” or “perceived” by the customer is called the customer facing service(CFS). CFS’s reside in the product catalog and they include one or more resource facing services.(RFS) CFS and RFS reside in the product catalog of the organization.

Returning our attention back to IT, we have business service, which reside in the business service catalog. Business service, as its name implies, the service that is served to the business. So it can be a payroll application or SMS application, which means, it can be involved in a CFS or not. But it is the business service at the end.

The problem I have seen while communicating the services and catalogs is this. In order to be inline with the holistic view, IT tends to divide its business service catalog to “internal” and “external” business services. External business services are the CFS’s or RFS to some CFS’s. Internals are the ones who are internal to the business such as payroll. This creates multiple catalogs. (On the other side, Network can live with CFS and RFS terms as they don’t have ITIL).

Some eTOM-ITIL mapping studies has been issued by TMForum to solve these communication problems. However, for me, there needs to be more studies around standardization of these service catalog structures. Especially for telcos who follow ITIL for the IT standard.

 

 

Understanding Frameworx Views

 Frameworx, NGOSS  Comments Off on Understanding Frameworx Views
Mar 312011
 

TMForum Frameworx(NGOSS), defines 4 views. These are different perspectives for looking at a service providers’ challenges and how to solve them.

First one is the “Business View”. Business View, focuses on the business and try to define and scope the business problem/ business case  to be solved. A business problem may be “implementing trouble management in order to increase operational efficiency”, “adding self ordering capabilities to the current order to cash process” or just “Decrease the OPEX”.

Business View’s main stakeholders are business analysts and sponsors(mostly managers). Business analysts will;

  • Capture the requirements
  • Define the use cases
  • Define the processes to fulfill these use cases
  • Define the business objects, manipulated by these processes.
  • Generate business workflows.
  • Define the roles

In constructing a business case, the main activity for the business analyst would be defining the process descriptions and their information/data requirements. Here, business analyst can find all the relevant information from eTOM, Business Process Framework. For this reason, eTOM is mapped to the Business View. The case documentation (and also eTOM) references to business entities to be manipulated by these business processes.  SID defines the business glossary. From this perspective, SID is also involved in the business view.

Business view is technology neutral and does not point to any technology specific topics.

The second view, “System View” looks at the business problem from more technical perspective. However, it is still technology neutral. IT Architects and Enterprise Architects are the main actors looking from the System View. SID is the main player in here. But the “I” part of it. It providers an Information Model explaining how several business entities are related to each other. SID uses UML to explain those associations, and cardinalities between the business entities.

The “D” part, data model will come at the next view, “Implementation View”. Implementation View is the view that the developers and system integrators look from. Here it is technology (J2EE, .NET, CORBA, DCOM etc.) and application specific (IBM x, HP y,etc.) areas that is the main concern of these stakeholders. Data Model is also in here, a solution specific look at the data that was defined in the system view. The Interfaces that are required for communicating with other applications are defined in here. The Data Model is also used to define the structure of these interfaces (and the databases).

Finally, the solution is developed/customized and ready to be deployed on the site. Here, “Deployment View” begins. IT Operators deploy the solution on the servers and start monitoring them. They manage the whole life cycle of the solution. In the mean time, business users are using the system and providing feedbacks about the efficiency of the solution.

It is important to note that Business View and System View are not “visible” when we went into the production environment.  What we will see would be workflows that represent business processes and  databases /technology specific distributed objects that represent the business entities.  For this reason,  the “hidden” views (Business and System) are called logical views while the “visible” ones (Implementation and Deployment) are called Physical Views.