A look at a successful object database management system at AT&T

Changing telecommnications options are drastically altering the way companies do business, and nowhere is this more apparent than at a major telephone company, which has to deal with changes outside as well as within. At AT&T, the Corporate ITS Group is responsible for internal matters, ensuring that the company can recover its costs and allocate charges correctly throughout its major sites.

As organizations within AT&T change their internal chargeback processes and as new products are introduced to the market, this group is required to track charges for every service on a variety of levels. Supporting new products and services used to take up to nine months with the older system, which was responsible for processing millions of messages monthly and hundreds of millions of dollars annually.

To address this problem, the ITS Group established the General Purpose Collector (GPC) project to explore ways to handle the increasing complexity of the services and chargeback strategies within AT&T.

"We are required to provide one bill that consolidates all of the services based on employee usage. It's tremendously complex," says Tim Schlagheck, senior specialist and project database manager with the ITS Group.

AT&T's internal systems had additional problems. The ITS Group, for example, needed to track the actual end users of the services and split overhead expenses automatically. This meant phone calls from a particular conference room may have been handled as overhead for one location and may have required direct chargeback for another. Also, organizations within the company needed the ability to contest charges when expenses had to be redirected.

Another key part of the project gave AT&T departments and organizations access to the chargeback information. Although it was a relatively new idea at the time, the team decided to use the World Wide Web to effectively disseminate information on demand. As part of this, the team had to ensure that the information was secure so that managers couldn't see or adjust bills from other organizations.

Finally, the project was designed to react more quickly to the company's internal needs. The group was encouraged to move to less-expensive systems with significantly less-expensive maintenance. "The team was fortunate to have supportive management throughout this project," says Schlagheck. "We were able to set reasonable expectations about project timetables, equipment and other necessities."

Two Key Areas There was nothing particularly complex about a standard telecommunications chargeback operation. Although the schema for chargebacks was complex, analysis for a single chargeback application could be modeled easily by a relational database. "However, management was committed to two issues: adapting to change and decreasing software maintenance costs over time," says Schlagheck. "Time to market for new services is the competitive lever today."

After some investigation, the team decided that an object database management system (ODBMS) would be the optimal solution for several reasons. First, rejoining the data during operations would become unnecessary because usage data was stored directly as objects. Even though some of the ultimate flexibility may have been reduced because objects are pre-defined, the team believed it would get faster throughput by using an ODBMS.

Second, an object database would reduce the complexity and size of AT&T's code base. In its investigation, the team estimated that trying to transform objects into a relational database would add approximately 20% more code, which could dramatically increase maintenance costs as developers tried to keep object definitions and database schema in sync.

"With objects, we would be able to meet the demand to provide varying levels of detail for differing customer requirements for whatever services were created," says Schlagheck. The main emphasis of the GPC project was to match up information from the AT&T switches with activity reports and send the reconciled data to internal financial systems. The system also handled exceptions so that groups could redirect charges effectively.

In addition, the system had to handle interactive requests so that managers could figure out which locations caused charges to their organizations. Likewise, the GPC had to be able to report down to the lowest levels of management and provide the detailed usage records for all services.

The emphasis was on knowledge transfer, so consultants acted primarily as mentors, bringing the team up to speed. The project team expanded to include subject matter experts, who were important in determining the business requirements that drove the project's analysis and design efforts.

"The best thing we did to ensure the success of this project was to use mentors to help us learn quickly," says Schlagheck. "We didn't want to rent people, since that would not have made our team stronger for the future. Instead, we got a heavy information transfer using the experts from Bell Labs, the AT&T Education Centers and Versant."

Boost in Traffic The six-phase project began Oct. 1, 1994, with the hardware and software delivered by the end of the year-four months before the team started writing code for the project. "Nothing was as easy as typing 'a:\install' at the prompt," says GPC Project Manager Keith Napier.

Still, the system was deployed on schedule last August, and it handled a significant percentage of the expected traffic during the first month.

The initial database was already a sizable number of gigabytes that eventually grew threefold with active data because it kept past months on-line for operational and financial analysis.

With the first three phases of deployment complete, the team is working on completing the external Web interface and adapting additional services to the new GPC system.

Based on the success of this venture, the team intends to expand this solution at AT&T as confidence grows about object-oriented solutions throughout the organization, says Schlagheck.

"It was the best choice for our business problem. It's non-trivial to deploy the first time, but our team feels the added complexity of a relational layer between the object model and its physical structure would be more difficult to manage over time," says Napier.

"The first time around you don't do it any quicker, but after that you can. We can add a new product or service in about half the time as it took a legacy system after the initial design."

Barry Wetmore is Director of Telecommunications for Versant Object Technology, Menlo Park, Calif. The final installment, appearing in the May 27 issue, will discuss how to choose the right ODBMS and plan its implementation.