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.

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.



Aug 142011

Let’s stop and think if it is meaningful for a service operator to give away all the OSS tools and infrastructure it has, for the sake of moving to cloud. A very big shift in the operations would occur for sure. Trouble Ticket, Fault Management, Performance management , Inventory, Fulfilment systems even mediation should be moved.

Cloud solutions promise availability and maintainability with less cost. But they should be on the cloud service provider’s infrastructure which resides on a remote site.

Thinking of the gigabytes of transactions that occur in a service provider environment, it is necessary to invest in high capacity links to the cloud provider. And since the information is critical, we cannot rely on Internet connections, we would need dedicated links.

Guess what then? We should then monitor these links to be sure that they are up and running all the times. If you notice any performance problem, (at L7) you should open a trouble ticket to the service provider to fix the problem. Offcourse you can rely on your service provider’s monitoring capabilities and trust them that they are doing their jobs well but this is not the case in real world. At the end, we would need to reconcile what they say and what we perceive.

OSS Cloud may also come in front of us in the name of “Managed Service”. Some OSS vendors offer this kind of a solution where they construct a shared OSS infrastructure (TT, FM, PM etc.). These services are under heavy control by the cloud (managed) service provider. If you want to create a new report, change an existing rule etc, you cannot do it by yourself. Managed service providers have to apply this change management mechanisms in order to maintain this shared OSS architecture. Most of the high-tier telecom service providers have complex OSS business processes. Moving to an OSS cloud may mean, giving up these processes and move to more generic ones.

On the other hand, OSS cloud solutions could be suitable for green field operators where starting investment costs should be minimized. After becoming more mature, they could easily switch to a private OSS infrastructure. Offcourse, if that happens, investing in the same software would decrease the project’s implementation period so it is wise to understand cloud provider tool’s footprint, roadmap etc. before deciding on their services.

Introduction to CEM

 CEM, OSS/BSS Transformation  Comments Off on Introduction to CEM
Mar 042011

Customer Experience Management (CEM) is a relatively new term that entered to the telecommunication service provider’s  jargon. Customer Experience Management is managing all the interactions of the Customer with the service provider. These interactions could be made over all available channels that are defined in the Customer Interface Management process. Call center, e-mail, Web, WAP , Stores could all represent those different channels.

CEM focuses on the customer and his/her experiences. It focuses on monitoring, measuring and improving the customers experiences.

Each interaction that the customer experienced, will create a negative or positive perception in his/her mind. Obviously, an overall good perception will ultimately lead to higher ARPU and lower customer churn.

When first introduced, CRM (Customer Relationship Management) aimed to improve the “relations” of the provider with it’s customers. However, CRM became a sales/product oriented tool and mostly forgot the relationships part. Today’s CRM focuses how to sell more to the current customers by analyzing their transactional behaviors. Buy this, take the other 20% off, today is your birthday so your first product in your cart is 10% off, here’s a coupon that you can use for your purchases $500 or more etc. The aim is simple: To sell more to the existing customers. Some initiatives include basic user satisfaction surveys after a sales experience but these are very primitive. Also, features such as remembering my birthday and sending a happy birthday email may indeed generate a negative experience sometimes.

CEM is a holistic approach to look to the customer from a 360 degree perspective. It addresses pre-service and in-service needs of the customer and it is not a “single tool” solution. Rather, it is a cross organizational culture where all the shareholders should commit to. It may and will include several OSS/BSS components to monitor and act upon the customer interactions.

Monitoring all the customers in the organization is not feasible. That’s why CEM initiatives rely on segmentation. Ofcourse an overall enhancement can be applied to all of the customer interactions however, features like real-time monitoring and analytics will require resources. Because of this, we see that most service providers who implement CEM start with corporate and VIP customers.

CEM will require a shift in company culture. CEM will require a shift in the way of working. It will, for sure, bring transformation of some kind but this time not for reducing OPEX and CAPEX, but understanding the customers.


Transforming the OSS

 OSS/BSS Transformation  Comments Off on Transforming the OSS
Dec 112010

Products and services that are sold by the service providers use multiple technologies that are implemented by multiple vendors. These vendors deployed their NEs into the provider’s network infrastructure. Each vendor also deployed an EMS system which is capable to manage their (and only their) NEs. These EMS systems are very welcomed by the providers as these systems enabled them to run the FCAPS functions for the multiple devices.

As the demand grows, providers needed to scale their infrastructures. To do this, they expanded their NE sets. In the mean time, the technologies were also standardized. An SDH technology, for example, can run on multiple brand SDH nodes to deliver an e2e VC12 circuit. This interoperability, gave the change to operators introduce multiple vendors/brands into their infrastructure. The drivers of this were lower costs and reduced vendor dependencies.

Each new vendor’s equipment brought another EMS to the network and the EMS layer started growing. In the mean time, new technologies emerged. The operators needed to deliver these technologies very quickly. And if this technology is a completely new technology that cannot be delivered on the current NEs, new NEs and EMS systems are introduced again. To cope with this growth, network management layer grew on the top of the EMS layer, providing the same FCAPS functionality but in a more consolidated way. We deployed fault managers, performance managers, configuration managers and inventory managers to the NMS layer.

The OSS investments are triggered by functional department needs. For example, the transport division who is responsible for the SDH/PDH systems had their own NEs, EMS and NMS systems. They had Fault Managers, Performance Managers etc. that are managed by them. (Or sometimes these are given free by the NE vendors during the deployment time and nobody is using them). The access network division also did the same thing.

This caused the silos to appear within the infrastructure. Silos had a problem. You were not able to see your end to end infrastructure view easily. Suppose, there is an SDH problem appeared in the network. SDH devices would send alarms to their EMS systems and those would report them to their NMS systems. Because of this L1 problem, ATM VCs would be impacted and the same alarm propagation would again happen on the ATM side. ATM DSLAM, which sensed that uplink failure, would also start complaining. Since there is no end to end visibility of given services, every division would send the responsibility to the other. This would increase the problem-to-resolution process times. Some operators invested on manager of manager systems to cope with this problem. However, for me, this is another cost (both operational and capital) to the operator which needs to be eliminated.

Silos bring inefficiency, increase capital and operational expenses. However, during the golden ages of telecommunications, where there were very high margins, upper management did not care at all the operations burden that is growing at the bottom. At last there are just 10 more salaries to pay.

Today’s conditions are different. Technology costs decreased and new players came to the market. Regulatory bodies started monitoring unfair activities that are against the competition which are leading to monopolies.

As the competition increased, the margins started to fall. In order to make more revenues or just keep the current revenues stable, operators started to create new product offerings. Only voice and data were not bringing the enough value. And there came the value added services concept. SMS, MMS, Mobile TV are such kind of services the operators began to offer.

Other ways to survive in this arena was to lower the costs (OPEX and CAPEX) and to improve customer satisfaction.

The transformation concept is introduced at this point. We now have the best practices frameworks to tell us how we should build and run our OSS/BSS infrastructure. We have past experiences. We should utilize those to transform the way we operate.

Transformation projects (OSS or BSS) start with a as-is analysis of the current infrastructure. In this analysis, we identify all the business processes, systems and people who run those processes. We also construct a to-be analysis that is driven by the best practices (such as NGOSS etc.). We then try to transform our infrastructure from as-is to to-be in a transformation program. During this study, we will possibly find duplicate processes and systems. We will also see some business process gaps that need to be implemented for efficiency. (SQM and SLA management processes are most likely to be introduced). Consolidation will be necessary in most areas.

Transformation programs are hard to implement. They are spread across multiple functional organizational groups. They need to have CxO level commitment and the most important fact is they should be continuous.