SID Adoption Reaching Maturity: Can Large-Scale Integration be Realized?

Comments
Print
Integration cost has always been the nasty thorn in the side of any OSS or BSS implementation. While APIs and various software-based integration approaches have matured over time, they have each been undermined by data model disparity across the many integrated application components. Over the years, the only thing that’s been universally agreed about integration is that altering the information model in every existing application to meet a common standard is virtually impossible and would be outrageously expensive. Now, new integration approaches are driving architects to seek standard reference models they can use to map disparate data into a comprehensive model. More often than not, the information model they decide to use is the TeleManangement Forum’s Shared Information and Data (SID) model. In development now for more than four years, the SID model has reached maturity and is now being embraced and implemented on a broader scale than in the past.

WHY SID MATTERS

As every carrier’s IT infrastructure has grown over the past decade, systems integration has become a greater and more expensive burden. Distinct systems serving distinct functions for distinct organizations have continued to grow, despite a clear recognition in the IT community of the potential business benefits of both horizontal and vertical applications integration. Watching architects build out new silos amidst a backdrop of systems consolidation is like watching a gambling addict losing at blackjack – he knows he should stop, but he just can’t.

The constant speed to market demand associated with new service launches puts pressure on the IT infrastructure that it can’t really adapt to meet – hence the need for new silos each time a new type of service or technology enters the network. It’s simply easier to throw a silo together and get a product running than to try and weave support for the new service into the existing quagmire of systems, processes, and organizational barriers. One major issue that makes this so difficult is information disparity. In short, when every system speaks a different language, none can understand any other very easily.

To this point, integration technologies have become more open and more effective at moving data from place to place. Where they lack is in providing any sort of validated data translation that references a standard or common information model and allows applications to communicate in a business context. Two applications that need to integrate could house identical data sets, but with different naming and organizational schemes, a painstaking effort is required to enable them to share data or to become functionally integrated.

At the heart of any software application is its information model. Every function an application performs has to touch that model. As such, changing an application’s information model is akin to heart surgery – you don’t do it unless you absolutely must. Engineers and architects recognize, for obvious reasons, that ripping out the heart of every application to transplant in a standard data model is basically impossible. Integration strategies therefore turn toward information mapping, where the context of data is mapped from one integrated application to the next.

If the issue were only to map a few applications’ information models to each other, it wouldn’t be much of an issue. The problem is that hundreds of systems must be mapped to hundreds of others. So, when service providers began building out EAI infrastructure and adding layers and tools to handle information mapping or translation among the connected applications on a one-off basis, they eventually found that the mapping intelligence itself could not scale. There was no centralized way to manage changes in the business context of the data exchanged in different transactions across the whole integration architecture, much less according to one, common information model that put all the disparate models in a manageable context.

Enter the SID. As these EAI implementations heated up in the late ‘90s, technical leadership at the TeleManagement Forum recognized that the industry needed to agree on some common information model just to give architects a basis by which they could organize the information common throughout their systems environments and use it to plan application integration, data mapping and process design.

In 2001, the Forum introduced the Shared Information and Data (SID) model, a comprehensive information model that provides structure from multiple business and technical contexts. The SID provides a knowledge base that is used to describe the behavior and structure of business entities as well as their interactions. In its early days, the SID was met with some amount of indifference as systems integration was not as sexy or critical to carrier executives as it is today.

Times have changed and telecom organizations realize the critical importance of a sound integration strategy. According to the TeleManagement Forum’s CTO Martin Creaner, there are four fundamental reasons large service providers realize that they need the SID, or at least something like it.

First of all, off the shelf software is difficult to integrate. “Over the last six to 10 years, many of these large service providers have decided they want to use off-the-shelf software, but integrating that is often a nightmare because of their distinct data models,” he says. As such, a common model like the SID is critical to normalizing those data models in an external manner. Ideally, all applications would share the same information model, but no common model has yet reached that level of introduction. Second, the SID provides the model to which data in a distributed architecture can be mapped. This functionality can be directly applied to the concept of the much sought after 360-degree view of the customer.–“ If you don’t have the right data or have it in an accessible format across the whole business you’re going to give the customer the impression you are disorganized, can’t manage their services and therefore you can’t meet their needs,” says Creaner. Third, today’s services aren’t really delivered by a single carrier anymore. Nearly all services traverse multiple networks to reach their destination which in turns makes data sharing across organizations critical to service delivery and management.

Finally, with all of the massive mergers and acquisitions, integration has grown in importance and visibility. Creaner says, “having a common data structure or model to work with makes the whole process [of integrating different carriers together] much more effective.”

THE NEXT GREAT INTEGRATION CAPER

With the margins systems integrators and integration bus vendors can earn thanks to application chaos, one wonders if the suppliers are treating the symptoms without curing the disease. This year’s do-all integration salve is SOA and though it’s cloaked in tired terms like “loosely coupled” and “federated data,” proponents say it and its attendant technologies such as XML, web services, and OSS/J APIs,are mutually mature enough to make it all work this time. Let’s remember that “they” said that last time too... and here we are again.

The fact is that no matter how well an integration technology can provide connectivity among widely distributed applications, putting all of the information that’s flying around into context is what really matters. SOA’s loosely coupled, web services-like approach may be able to offer great flexibility with fewer static connections among systems, but it won’t guarantee that what it’s supposed to enable from a business context is actually what’s happening. The SID can help, but to do so it must move from being a pure reference model to something that can be implemented as a management tool on top of an integration environment – be it SOA, EAI, API-to- API, or all of the above as is the case with most large carriers. As SID has become more important, the need for this sort of application or tool that can enable SID implementation is being recognized across the industry.

PANTERO AND SID REALIZATION

Pantero Corporation is like the first soldier through the sea wall on D-Day after the bangalores go off. There’s a lot of chaos around them, but they see daylight and are running toward it at full speed. Unlike most start-up companies who fit a similar description, Pantero has a chance to survive, even in an environment that can be harmful to start-ups.

Pantero calls itself a provider of “semantic integration software” that enables the SID to be leveraged in SOA and other integrated environments. What Pantero’s software does primarily aids architects, developers and business analysts working on large integration projects and managing large, integrated applications environments. As such, it is cryptically technical, but it cuts to the heart of what makes systems integration so difficult. In the process of implementing an SOA, the architects and analysts are responsible for defining all of the process and transaction flows and, as such, which systems and specific pieces of information are involved in each.

Often this incredibly complex task is done on paper, with spreadsheets or with other tools that can help organize some of the concepts, but this exercise doesn’t really do much to drive the actual implementation. In short these folks are using stone chisels instead of steel jackhammers to cut across massive organizations. “Essentially what Pantero has tried to do is make [integration development and maintenance] into something much more straightforward.”

Pantero’s technology allows users to map all of their data into the SID. With that as a reference point, Pantero’s metadata driven tools give users the ability to create or define the services that make up business transactions across an SOA while providing a point of data transformation and validation that will constantly oversee the integration architecture in production. In layman’s terms, it provides all of the construction equipment, makes sure everything conforms with the blueprints, and oversees the health and maintenance of the building for the future.

Assuming this approach works, it can provide a critical control that attends to and simplifies the most costly and time consuming aspects of delivering and maintaining a large integrated environment. Pantero is gaining attention, thanks in large part to leveraging the resources the Forum provides to its members, and gained credibility in October when it was announced that IBM would incorporate Pantero’s technology into its Service Delivery Platform.

Pantero’s software integrates into IBM’s WebSphere SOA platform (Process Server 6.0) and is being used to integrate the various application components – reportedly more than 10 - that comprise the platform, including Ceon’s Intelligent Order Manager and a component from Leapstone. IBM’s SDP is one of the key platforms on which the OSS architecture for SBC’s Project Lightspeed is built, though the version currently installed does not incorporate Pantero’s technology at this time. IBM was unavailable for comment, but did confirm the inclusion of Pantero’s technology as part of its solution architecture.

WHAT’S NEXT FOR THE SID?

Pantero is the first through the breach, but not likely the last. More companies recognize carriers’ need for some centralizing, organizing principle or tool that can help them reign in data disparity and all of the problems that come with it. Externalizing the SID is one approach that seems sensible for the near term. In the long term, however, the vision, says Creaner, is for “all of the various vendors to have developed their implementations consistent with the SID.”

The OSS/BSS space is moving in this direction. Though vendors aren’t rushing to rip out the information models in all of their products, they are embracing things like OSS/J APIs which allow them to expose their applications’ data and functions to integration environments in a SID- and NGOSS-compliant way. With companies like Sun Microsystems wanting to define a market for reusable software components that attend to such interface and integration issues, there would seem to be some real momentum.

In the big picture, were the industry to embrace a common information model approach, at some point – theoretically – there would no longer be a need for an externalized system to manage data translation and validation. In reality, however, service providers IT environments have decades of heterogeneity to cope with. This makes it imperative for the Forum to keep the SID up to speed with changes in the industry. It also means more technologies like Pantero’s need to emerge to address the ongoing data disparity problems any integration architecture – no matter how promising – is going to encounter.
Comments