Pipeline Publishing, Volume 3, Issue 12- Kenneth Rugg

Pipeline Publishing, Volume 3, Issue 12

	This Month's Issue:
	Standards Make A Stand

Achieving Data & System Integration Nirvana with SID

By Kenneth Rugg

Over the past several decades, information technology (IT) professionals at service provider organizations have struggled with integrating the diverse operational and business systems present in their environments. While they have in some cases found technologies such as enterprise service busses (ESBs) to connect systems together, they have continued to hit challenges in getting these systems to understand data that is exchanged between them, or put more simply, to “speak the same language.” This difficulty led to a desire to develop some form of common model for information exchange.

With the advent of service oriented architectures (SOAs) and new systems interacting with legacy and homegrown systems, the need for a common data model that can be used as a common language in the exchange of data between applications has never been so critical.

Some service providers have developed internal exchange models that are used in limited ways to simplify cross-system integrations but few have achieved a common model across their entire enterprise, let alone one based on an industry standard that could be used across enterprises.

With the Shared Information/Data (SID) model, the TeleManagement Forum (TM Forum) has developed a common language for enterprise operations in the telecommunications industry. It provides a vocabulary for communications across the entire business and operational systems of a service provider as well as a standard format for exchanging information with partners and vendors.

So how are service producers taking full advantage of the SID as a common data model in integration projects for operational and business support systems (OSS/BSS)?

This article will take a fresh look at the SID model and its relevance in addressing the thorny challenges of data interoperability in the integration of OSS/BSS and examine the requirements for software tools to effectively support the SID in application integration.

Why use the SID model?

Think about, for example, a service provider’s retail division and its wholesale division; two divisions with two drastically different definitions of what constitutes a customer. A retail division has a simple definition of customer; it represents a person with a name, address, and perhaps a credit rating; but nothing too complicated. The wholesale customer, on the other hand, might include many other attributes such as multiple contact points, custom service level

So how are service producers taking full advantage of the SID as a common data model in integration projects for operational and business support systems (OSS/BSS)?

photo here
agreements, and VAT identifiers among other things. In addition to this, a wholesale customer may also be a vendor or even a competitor in other contexts.

For this and other reasons, it’s useful to use the SID model to provide the party abstraction. A party represents any participant in a business interaction. This could be a retail customer, a wholesale customer, or even a vendor or competitor. This allows both individual customers and organizational customers to be represented, enabling both divisions to share the same information and information model.

A Triple Play Case Study

The value of a comprehensive information model is demonstrated in this case study based on a project to implement a Triple Play bundle consisting of:

Voice, using Voice Over Internet Protocol (VOIP)
Video, using the Internet Protocol Television (IPTV) protocol
Data, using high-speed Internet (broadband)

In this project, over a dozen applications supporting nearly 100 operations needed to be integrated. These systems provided functionality that spanned CRM, inventory, activation, and service assurance; designed to provide a “zero-touch” fulfillment and assurance solution. The use of ESB and business process management (BPM) technology enabled integration in an SOA. However, the lack of a common data model was going to necessitate an enormous amount of custom code in order to implement the required data transformations and ensure the semantic consistency of data exchanged between systems.

article page | 1 | 2 | 3 |

© 2006, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding
the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.