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.

Telecom Applications Map – TAM

 NGOSS  Comments Off on Telecom Applications Map – TAM
May 092010

TAM (Telecom Application Map) is one of the frameworks of the NGOSS (Frameworx) initiative. Its main goal is to draw the boundaries of the OSS/BSS applications. Standardized business processes and the applications that run those business processes, emerged in parallel. However, the OSS application vendors named and scoped their applications by themselves without following a standard. This led to confusion among the customers (service providers). That’s why, TAM started as an initiative that was triggered by the service providers. The service providers needed an application map where they can see the scope of their current and future OSS/BSS applications. They created a complete view of applications. TAM will help the providers to identify the missing applications within their infrastructure. It will also help to discover the overlapping functionalities. Why should I maintain 2 applications that are capable to run the same functionality? That’s where the TAM helps.

TAM is a logical view of applications. That is to say, it does not include any platform dependent, or implementation specific information. Rather, it focuses on the applications and their capabilities to perform business process requirements.

TAM can also help in creating RFI/RFP documents. Suppose you want to issue an RFP and constructing the compliancy matrix that will be submitted to the vendors. Which functionalities should be asked? You can utilize TAM for this purpose. If you will invest on an Order Management application, open TAM, and find the Customer Order Management application. Ask your vendors how they can comply with these functionalities. A real time saver…

The framework is mapped to eTOM and SID frameworks. How? via the domains. We have seen that eTOM Level 0 domains (concepts) are consistent with the SID domains (which include the ABEs). This domain concept continues in the TAM framework. TAM also includes the domains “Market/Sales, Product Management, Customer Management, Service Management, Resource Management and Supplier/Partner Management”. The concept is the same but the naming is different. TAM calls these as “Application Areas”.

Application Areas are composed of Applications. There are Customer Management Applications, Service Management Applications etc. Each area will include applications under it. For each application we can see the overview, functionality and supported business services section. Like eTOM, TAM was also designed in a hierarchical structure. Applications that are listed in Level 1 may also be decomposed into lower levels sub-applications (Level 2 and below). These sub applications are also called modules. A customer order management application should have an orchestration (workflow) module. This module can also be decomposed into order distribution and order tracking modules. (This is the L3 detail). Vendors heavily use this module concept within their applications and they apply separate licenses per module. This also gives the provider the option to select the modules it wants from the application. If another, previously bought application has a workflow module that can be reused in the order management, while procuring for an Order Management application; I may not want to buy that specific module.

TAM brings a common application dictionary that can be used by multiple types of stakeholders. It represents an application standardization which also guides the vendor products. Vendors use it for marketing purposes. TAM mappings are used by the vendors to draw the scope (footprints) of their applications. Service providers utilize it for creating RFPs, deciding on the IT transformation strategies which will lead them to increased automation and organizational efficiency.