OSS/BSS implementations continue to be limited by the time and cost of integration. While integration costs often overrun the cost for new software components, the time needed to integrate is becoming as significant an issue, because it can slow or delay new service launches. A majority of major communications service providers (CSPs) have some degree of confidence that service-oriented architecture (SOA) initiatives are either beginning to or have the potential to decrease integration complexity for them. But SOA is revealing new complexities relating to semantic data interoperability across systems that must be addressed to ensure SOA delivers scale and adaptability over the long haul.
Semantic Challenges
In order for data to be interoperable in OSS/BSS integration, it must conform to the correct format, or syntax, as well as the correct meaning, or semantics, of the systems for which it is intended. As a simple example, one system might contain "street number" and "street address" in different fields, while another might include both in a single field. In a more complex example, similar data constructs such as "address" can have completely different meanings among systems. In one system it might mean the billing address, while in another it means the address where a circuit terminates.
In point-to-point integration approaches, typical of enterprise application integration (EAI), custom adapters are developed to address the disparities between two systems, but not across multiple systems. SOA introduces a many-to-many integration paradigm, but it has no built-in mechanism to ensure that data are semantically valid across systems.
Dan Druta, senior OSS integration architect for Cingular Wireless/AT&T, says that "integration challenges can be partially addressed with service adaptation solutions," but he cautions that as service-oriented enterprise implementations become more process-oriented and enable composite applications, web services alone are not enough. "The content of what is being exchanged, the vocabularies and terms," he says, "also need to be defined in order to achieve scalable SOA."
Stewart Welbourne, lead integration architect for BT, echoes Druta's perspective. He says that "integrating data in SOA is a lot more than just ensuring that data is provided to each system in a format it can understand." He says that implementing an SOA without semantic data validation will necessarily result in significant fall-out. "While something like an order seems to be a simple concept," he says, "there are differences in what constitutes a valid order in different circumstances." For example, he explains, orders for pre-paid versus post-paid services require very different information. "For post-pay services, information such as ‘preferred payment method' and ‘billing cycle' might be critical, but in an order for pre-pay services, this information doesn't apply," Welbourne says.
He adds that the XML schemas often used to overcome data disparity among systems are limited in their abilities to deal with semantic differences and to enforce consistency across systems. He argues that although "localized solutions" can help to reduce the overall semantic challenge, the industry needs to evolve beyond such single-use fixes to repeatable enterprise solutions. Failing to do so, he says, will result in "a lot of localized code and a fundamentally brittle integration architecture." This result is clearly in conflict with the flexibility, adaptability and reusability SOA is intended to enable.
SOA is meant to co-exist with the enterprise service bus (ESB) implementations in which CSPs have invested significantly. These same providers commonly observe, however, that while ESBs are useful for mapping between two specific application interfaces, they don't fully address the re-use and life cycle support required for the data mediation logic they tend to require. Manual coding and various data mapping approaches are generally used to fill in the gaps, but these approaches haven't progressed to meet the data integration challenges inherent to SOA. And even though SOA is "a necessary step on the road to reduced OSS/BSS integration cost," says Lorien Pratt, Stratecast director for global OSS/BSS and infrastructure, it is in fact insufficient on its own. "If data models are out of sync, integration costs remain high."
Solution Approaches
In order to drive semantic and syntactic interoperability in large collections of integrated systems, CSPs are following several defined steps. These include consolidating redundant systems; simplifying integration using semantic exchange models; examining standards like the TM Forum's SID model; and adopting tools that utilize metadata to support the entire integration life cycle.
Consolidating Redundancies
Clint Heckel, enterprise architect for Verizon Business, says that "step No. 1 needs to be consolidation of systems whenever practical." He says that in conversations with his peers across the industry, it is now widely agreed that regardless of the various reasons behind it, systems have been allowed to proliferate too much. "We will never succeed in delivering an agile integration infrastructure without reducing the number of OSS/BSS applications we are supporting," Heckel says. He argues that in some cases this will mean reduction by "an order of magnitude," particularly given the ongoing pressure to reduce operational costs in total.
Welbourne adds that an important part of BT's "One IT initiative" is a multi-year effort to reduce the number of systems it supports "from over 3,000 to just a few hundred." A few hundred systems, however, is still a "substantial and evolving estate of OSS/BSS," and it is critical for BT to integrate these systems using a highly flexible architecture. He says, however, that using a "vanilla" COTS strategy, extensible business services and an enterprise data model means that "we push the ever-present complexity into the fabric between those abstract interfaces and the COTS engines we are driving. This is where integration agility needs to be addressed."
Simplifying Integration With Semantic Exchange Models
Interest in using data modeling as a tool to simplify integration is resurgent (see sidebar). A data model can serve as a common data abstraction, or semantic exchange model, across systems. It can support the loose coupling of systems in SOA and eliminates the need for one-to-one mappings of the differing data schemas between each set of systems. An architectural approach that maps each application data schema only once to a neutral data model can reduce the manual coding for data transformation and validation. It can also provide a common vocabulary across OSS/BSS applications, masking some of the semantic data inconsistencies between systems.
Welbourne says that BT has coined the phrase "exchange data model" to emphasize that data modeling is not an academic exercise, but a step toward realizing a common data representation across integrated systems. BT's Common Capability Model (CCM) is already delivering substantial results. Any of BT's discrete platforms, such as billing or CRM, can now expose service capabilities based on the CCM that can be understood by any consumer of those capabilities in the organization. Using this approach, BT can support multiple implementations of discreet platforms like billing, CRM, and service activation and can swap underlying systems without impact.
Heckel at Verizon Business observes that today's enterprise data modeling projects are significantly different from those pursued a decade ago, because management is unwilling to fund any multimillion-dollar project that strives toward "some vague goal." Instead, he says, data modeling initiatives now target practical and specific outcomes, such as determining the business ownership and governance of data and "ensuring that there is some kind of shared data abstraction … that provides a common semantic" and therefore makes OSS/BSS integration simpler across the board.
Fabrice Cornet-Libon, senior OSS architect for Sprint-Nextel, recommends that CSPs start their modeling initiatives at the project or business unit level. "It is very tempting to want to start at a global level," he says, because the end goal is to have a single model across the entire business. In reality, however, the scope of this overall challenge "needs to be understood in bite-size chunks," he says.
Examining Standards
Industry data and information standards offer an elusive promise of simplifying OSS/BSS integration and reducing the so-called integration tax. Past consensus has been that critical standards, including the TM Forum's Shared Information/Data (SID) model, have not matured enough to support large-scale integration projects. Recent initiatives across both wireless and wireline carriers are, however, providing real proof that the SID is up to the task.
AT&T's Druta says that the increasing industry-wide focus on the SID gives reason for optimism, though the steps at this stage are somewhat small. "The SID is a large and abstract model, and nobody is going to find everything they need or agree with how everything is modeled," he says. Despite this practical fact, he says, "the more we anchor our data exchange in SOA on the SID, and the faster the vendor community steps up to the challenge of supporting the SID, the better off we will all be." He suggests, however, that no one should expect the end result to be plug-and-play OSSs, but rather they should expect that leveraging the SID in application interfaces and as a common data abstraction for SOA "can substantially reduce complexity."
Supporting the Integration Life Cycle
It is generally accepted that SOA based on data-centric integration is intended to ensure a loose-or, in other words, flexible and adaptable-coupling of OSS/BSS solutions. But a common concern is that just writing a lot of code will produce brittle integration architectures that won't adapt to future demands. Druta warns that "we can't rely on manual coding" when it comes to data integration in SOA. He says that because the industry is now "moving beyond a point-to-point, adapter-based integration approach that was common in EAI," there is a clear need for software tools that can "support the many-to-many patterns in SOA."
Two of the must-have requirements Druta points to include new software tools that can organize all data mappings based on a common semantic exchange model, and the ability to capture comprehensive design metadata that supports an end-to-end impact analysis for any change in the architecture. He argues that if CSPs try to throw code at data integration challenges, it will result in tightly coupled interfaces that will be inflexible and will lack any of the metadata needed for ongoing flexibility.
Why MDM Isn't the Answer
Another common pitfall, says Verizon's Heckel, is the natural tendency to attack data integration with a master data management (MDM) approach that implements a single "golden master" for critical business information. Heckel argues that there is a time and place for MDM, but in an enterprise implementation, the challenge to achieve consensus across the business regarding the content and ownership of data can be insurmountable.
"What we really need are tools that support virtual consolidation of data more than the physical consolidation of data," says Heckel. He explains that even with a fundamental concept, like a customer, "it isn't realistic to expect that a Tier 1 CSP can get agreement across all operational silos for every context in which that data is used." Stratecast's Pratt agrees that "a single master data record approach simply isn't practical for CSPs" and that instead the appropriate place for coordination is the information model.
Pratt reported that because CSPs are now making efforts "to establish common data models for fulfillment, assurance and billing data," they are likely to reap the benefits of reduced time and cost to integrate. Perhaps more importantly, she says, this activity is likely to result in an ability "to leverage this data for new revenues and competitive differentiation in areas like personalization, advertising, and marketing."
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article