But over the years, precious few of the large U.S. telecoms can boast much progress toward a leaner and meaner OSS/BSS infrastructure. In fact, it can be argued that industry mergers and time-to-market pressure to build product-specific platforms have made the integration problem worse.
The telecommunications industry has tried to integrate and consolidate its infrastructure. It has invested in several integration programs and generations of middleware solutions from CORBA and MQSeries to EAI, J2EE, and OSS/J. However, the results have been mixed. Integrations have worked, but scalability is still a major concern. . Service providers have succeeded with e-commerce initiatives using their OSS/BSS by enabling better sales, customer care and self-service applications. But integration has largely failed with regard to reengineering outdated processes, reusing IT components and migrating legacy systems to fewer and more nimble platforms.
To further understand the degree of progress, Dittberner Associates conducted market research specifically on four large U.S. wireline carriers to assess their recent integration and consolidation efforts. Of the carriers that participated in the survey—AT&T, BellSouth, SBC and Verizon—Dittberner concluded that AT&T demonstrated the most proficiency with its integration and consolidation efforts.
In recent years, AT&T has been under considerable pressure due to long distance price wars, RBOCs entering the corporate telecom game, and heavy debt forcing the sale of AT&T Wireless to Cingular and AT&T Broadband to Comcast.
Despite these facts, AT&T reported earlier this year that it had managed to retire more than half of its roughly 800 OSS/BSS platforms and now has (a still daunting) 350 remaining. But even allowing for the many systems retired due to divestitures and business exits, this progress is quite impressive.
To consolidate systems, AT&T used several middleware technologies and integration approaches, and simultaneously worked to overcome the dozens of organizational barriers that tend to grind so many large integration projects to a halt.
The Concept of One
AT&T’s transformation began in 2001 when the company launched a sweeping operational improvement program called the Concept of One.
Concept of One was AT&T’s metaphor for radical OSS/BSS change: integrate and consolidate OSS/BSS to the point where theoretically only one system would be left standing.
Considering that AT&T had hundreds of redundant, product-based legacy systems, some whose code hadn’t been touched in 15 years, it was going to be difficult. But AT&T realized that even if it could pare its OSS/BSS systems down to a few dozen, it would earn a huge payback.
The key to the project was specifying a target architecture—a series of company-wide technology and functionality requirements that each OSS/BSS would need to support.
Although this sounds like an IT blueprint, it was really a broad operational plan that combined a service-oriented architecture (SOA), budgetary controls, Sarbanes-Oxley compliance, “contract event migration” and a way to maintain accurate customer accounts and hierarchies.
Once the target architecture was defined, centralized control of development budgets across AT&T was used to reform or weed out obsolete systems. So wherever AT&T had large staffs operating old, semi-automated OSS/BSSs that didn’t conform to the target architecture, it threatened to cut the budget for future development of those systems. As a migration path, AT&T created several target architecture-compliant BSS/OSSs that would support families of related telecom products.
One such BSS is AT&T’s Universal Billing Platform (UBP), the target architecture for all AT&T billing systems. The plan is for the UBP to eventually provide an audit trail of every billing event at AT&T. Furthermore, every new product that AT&T launches will go through the universal biller.
To migrate customers to this system, AT&T often employs a “contract event migration” technique. This approach uses price and sales force incentives to transfer customers to a new contract that effectively moves the customer from an old network or OSS/BSS.
Sarbanes-Oxley Compliance
Sarbanes-Oxley (SOX) regulations presented another incentive for AT&T’s far-flung business units to support the target architecture.
Take the area of applying customer credits to a billing system. Formerly, if a customer called to complain about a service outage, the customer care agent would credit the customer, say, 5 days’ worth of charges on the next monthly bill.
Unfortunately, when credits are charged to a future accounting period, taxation is inaccurately applied, meaning it doesn’t meet the SOX litmus test. And making that change forces AT&T to modify its billing systems to apply credits in the correct manner.
So SOX became yet another management hammer. The message was, “If you want money to support your legacy OSS/BSS platform, you need to support both the target architecture and the new SOX-compliant accounting rules.”
The Database of Record
If budgetary control and Sarbanes-Oxley supplied the muscle, then the DBOR—the DataBase of Record—supplied the brains of the target architecture.
Simply put, the DBOR is an enterprise-wide data translator, transformation engine and data scrubber that lets databases across AT&T understand one another.
Being able to trace a corporate contract through all the databases in the contract-to-collections food chain is a critical capability. Without that knowledge, it is unknown whether credits and discounts are being applied to contracts correctly. Before the DBOR was created, AT&T could not easily trace such a chain for its largest business accounts. Yes, AT&T business units could track their own in-house generated contracts, but getting a 360-degree view of the larger parent organization was tough to deliver.
In short, AT&T’s lack of a big-picture understanding of its corporate accounts and hierarchies was a gaping infrastructure hole that required many manual solutions.
To address that problem, the company went on a massive data cleansing and transformation campaign. Its internal OSS/BSS experts spent months, even years, fully documenting and mapping their systems knowledge across contract, circuit provisioning, billing and finance databases—each database having its own provincial view and often lacking common fields with its neighbors.
But the effort was worth the cost, for in the end, AT&T had a rock-solid DBOR—a priceless master translator that could match contract numbers on one end with collections account numbers on the other.
Web Services and SOA
With the DBOR supplying the trusted data source for integration, AT&T chose a service-oriented architecture as its middleware framework.
Like other large carriers, AT&T had experienced plenty of problems with earlier generations of middleware:
With SOA, AT&T could rework the layers or architecture of its OSS/BSS functions and applications, exposing them as autonomous modules (or services) around a series of AT&T-standard APIs. Then, with everybody writing to standard interfaces, AT&T could eliminate pair-wise integrations involving different rules, different logic, different technologies, different data, different schedules and different politics.
And those modules could be implemented using many technologies (SOAP, an ETL procedure, etc.) based on the message size, complexity, security requirements and frequency of use across clients. Where loosely coupled messaging didn’t exactly fit, such as in real-time apps, AT&T could encapsulate CORBA, J2EE and other middleware into a loosely coupled scheme.
AT&T found that web services even made sense for integrating applications that it had no intention of rebuilding. Using WSDL, AT&T could quickly create self-documenting adapters to wrap those applications into a web services framework.
And instead of requiring a software bus for data transformations, web services enabled AT&T systems to talk in parallel using XML as a common language.
These benefits aside, designing the structure of AT&T’s corporate SOA was painstaking. Because industry-wide SOA best practices are still in the pioneer stage, AT&T’s SOA team had to plan carefully. It spent much time figuring out how it would integrate web services and layer functionality for the internal SOA. Setting up a repository of web services, for instance, involved naming services so that people across the AT&T organization could understand them.
Once built, AT&T implemented its SOA in areas such as trouble ticketing, where it defined web services such as “create ticket,” “get ticket” and “update ticket.” Since so many OSS systems touch the trouble ticketing area, it proved a fruitful area of web service reuse. Thus far, Dittberner estimates roughly 15 percent of AT&T’s integrations have been “re-factored” onto the SOA.
Lessons for the Future
AT&T’s target architecture story is a textbook example of how integration milestones can be achieved with careful planning, cross-departmental cooperation, budgetary control and an SOA framework.
As other operators continue to consolidate and integrate their systems, Dittberner offers the following observations based on AT&T’s initiative:
Dan Baker is director of Dittberner's OSS/BSS KnowledgeBase, an annual research service. Prior to joining Dittberner Baker founded Technology Research Institute (telecomOSS.com) and has been analyzing the OSS/BSS market since 1994. Email: info@dittberner.com
