Beyond bonding: A three-tiered approach to operations support systems can facilitate information sharing between carriers

It's well-known that local exchange carriers are rethinking their operations support systems, which handle a wide range of daily operations such as billing and service provisioning. This trend is driven, in part, by legislation aimed at increasing competition in the local telephone service market, which requires incumbent LECs to open up their OSSs to new competitors.

A general trend away from mainframe-based systems to a client-server architecture is another factor. Client-server technology is making it possible to provide dramatic improvements in customer service, while substantially reducing the amount of time and training required for common service operations. Client-server computing also may provide the best alternative for meeting new requirements for electronically interfacing with other carriers.

Yet contrary to many predictions, client-server computing is not replacing traditional OSSs. Instead, a blended system is emerging that combines the data processing horsepower of the legacy OSS with the opportunities for rapid application development and electronic interfacing capabilities of client-server technology. The cornerstone to this solution is a three-tiered approach, in which an application layer provides an interface between the client-server system and the legacy OSS.

The legacy re-examined A good way to present these developments is to trace the differences in the way that a simple service call is handled now compared with a few years back. Consider the example of a customer who orders call waiting and finds that the feature is not working.

For a telephone company operating traditional monolithic OSSs, this service call would normally require queries to at least four separate OSSs--each potentially requiring a callback by a separate service representative. The service representatives have to determine which OSSs must be accessed; log into those systems; enter information onto a number of screens; translate codes such as ISDN field identifiers, universal service order codes and switch codes; and compare results.

At a minimum, the representative would need to access a system to determine if the telephone number experiencing the problem is the main billing telephone number. After obtaining the billing telephone number, the rep would access the billing system to see if the user is actually being billed for the call waiting service. At that point the rep would access the switch that services the user, determine which parameters are set for the user's line and, finally, access the service ordering system to determine if an order is pending for this change. The codes and information from one system are used as input for the next system. Chances are, service representatives would have to complete at least six months of training before they would be able to complete all the tasks required to diagnose and fix the problem.

It's no wonder that in the late 1980s, most carriers began moving toward a three-tiered client-server architecture in which a Unix-based server interrogates the OSS and provides a simplified user interface (Figure 1). The basic idea is that the OSS continues to handle its existing functions while new functionality is added through the client-server system.

A key advantage of fronting the OSS with a client-server system is that development can proceed much faster using modern programming tools. While the development cycle on a legacy OSS typically is six to 12 months, in the client-server environment this normally is reduced to a month or two.

The server architecture is distinguished by an access layer that communicates with the OSS. This access layer must understand the idiosyncrasies of the OSSs operated by the various incumbent LECs. For example, although New England Telephone and New York Telephone merged back in the mid-1980s to form Nynex (which in turn has been acquired by Bell Atlantic), the company still maintains separate billing systems that date back before the merger. The server also would provide the consolidation function, which selects the appropriate access method for a given request, and the message router, which communicates between all the different elements of the system.

Perhaps the most critical components of the server architecture are the business objects. These are object-oriented programming constructs that represent various business functions and provide a simplified interface to the user. An example would be a business object that handles a perceived discrepancy between features ordered and those actually provided. This object can perform all the steps described above, involving queries to various OSSs, in order to resolve the problem. Business objects provide the advantages of object-oriented programming, enabling users to think in terms of higher-level business concepts rather than arcane coding constructs.

Returning to the example of the customer with the call waiting problem, a representative using a business object-based system would only need to enter the telephone number of the calling party. For even greater streamlining, the system can use the inbound calling number to automatically generate that entry.

The system then would initiate the request for the proper telephone number. In parallel, the system would also access the billing system, the switch and the service order processor. Once results are obtained from these systems, the client program would display any discrepancies between the bill and the switch and allow the representative to point and click on the screen to correct the problem. Besides reducing the time required to solve the problem, this approach could reduce training time for representatives from six months to a matter of hours.

The client-server architecture used in the three-tiered solution also can provide significant savings in hardware expenditures and maintenance costs compared with mainframe-based environments. Additionally, such an architecture allows organizations to protect future investments by using expandable, scalable products.

Client-server applications also provide the opportunity to build applications with reusable assets or with business objects that can be developed, implemented and tested in far less time than mainframe applications. Users can play a greater role in the development process and have more control over the application once it's operational.

Enhancements are everything Soon after the three-tiered approach was developed, its flexibility encouraged users to make enhancements to address other chronic industry problems.

Before the early 1990s, the vast majority of consumers bought local service from their LEC and long-distance service from an interexchange carrier. If a problem arose that involved both carriers, the consumer typically would call an IXC customer service representative, who would open up a trouble ticket and then call an LEC representative. The two representatives would try to work through the problem together.

Because it relied on verbal communications, this system typically required a long period of time to solve problems and was fraught with the potential for errors and misinformation. That's why, in the early 1990s, electronic bonding standards were developed to communicate between the separate OSSs maintained by the LECs and IXCs (Figure 2).

The basic idea was to reduce the time required to resolve trouble tickets, and reduce error rates and staffing requirements. The problem, of course, was how to make different computer systems, which had grown up independently at all the major telephone carriers, talk to each other.

Initial efforts focused on communicating through a hardwired link using the Open Systems Interconnection stack, the same group of protocols through which local area networks communicate with each other. Although this custom approach has improved customer service, it cost about $1 million for a typical installation.

Electronic bonding through the OSI stack took the industry almost three years to implement, and by the time it was completed, the environment had changed drastically again. It's important to note that legacy OSSs, which still handle the bulk of trouble tickets under the new system, were designed to communicate with trained internal users, and security was not a major concern. Electronic bonding opened up the OSS interface to trusted partners, the few selected IXCs that handled the bulk of the traffic and could justify the cost of the solution. Minimal security features were added to the interface when electronic bonding was implemented.

Today's operating environment is entirely different. In addition to trained users and trusted partners, the OSS is likely to be accessed by a wide range of other companies with which the LEC does not have a close relationship--the CLECs. A number of these companies are likely to compete with the LEC in both the local and long-distance markets.

The flow of information between incumbents and CLECs is potentially heavy. The Telecommunications Act of 1996 mandates that the incumbent LEC provide the CLEC with electronic access to the OSS equivalent to what is provided to internal users. In particular, CLECs must be able to obtain pre-ordering information, order local service, order directory listings and specify features.

In response to these heavy demands on the interface and on OSS security, a new breed of OSSs has arisen in the last few years. Rather than a single Unix-based server, these systems consist of a network of computers, each providing specialized functionality. These computers can run Unix, OS/2 or Windows NT operating systems. Each provides specialized capabilities at a lower price-to-performance ratio than legacy systems, and they also offer a high level of redundancy to support mission-critical tasks.

One of the unique capabilities of the new generation of client-server systems is their ability to provide multiple electronic interfaces such as OSI, electronic data interchange (EDI), Internet and intranet, as well as the usual Windows and OS/2 clients that are used by the LECs (Figure 3).

The system receives information from trading partners in a specific format such as EDI and electronic interchange format. Partner profiles determine what each partner is permitted to access based on a unique message set. The communication layer then transmits these formatted message sets using the customer-specified communication profile. Logging functions provide accurate tracking and matching of transactions in the request cycle.

The problems of security and authentication are handled at the server level using gateway and firewall technology that has been developed for Internet applications. The latest generation of client-server architecture can take advantage of inexpensive commercial component technology to provide high levels of validation and security at a far lower cost than would be required to upgrade legacy OSSs.

These new systems also make it possible to offer Internet or intranet access to key customers, as is being provided today by several Bell regional holding companies. These carriers are providing special client software to major customers that allows them to access the OSS to order additional services, add or remove features, report problems and check the status of reports.

Another key advantage of client-server based solutions is that they can eliminate the need to train the user on several legacy applications, instead learning the new graphical user interface-based solution. This solution is typically presented in a model that mimics the business process and not the often arbitrary, function-delineated legacy systems it front-ends. The result is a tremendous savings of training time and increased customer satisfaction.

The open architecture of client-server technology also provides some key benefits. For example, carriers can allow authorized sales agents to electronically access customer service and support systems. Providing agents with access to the server via a network can save agents from having to call the carrier thousands of times per month to obtain customer data, initiate service orders and verify order status. With fewer follow-up calls and more time to sell, agent revenues could increase by millions of dollars per year.

Technology that can interface with these systems is being offered to IXCs that are entering the local market. Products using this technology make it possible to perform pre-order inquiries and to make requests for local service, directory service and other types of services. Such products include a translation engine that formats data from the internal OSS to the trading partner's format and a communication engine that permits the user to talk to the trading partners using a variety of transmission techniques and protocols.

Ideally, the industry should coalesce around a single communications standard, but the trend actually seems to be headed in the other direction.

The problem, essentially, is that in the period of time required for the industry to agree on a standard, technology and demand change to such a degree that the standard either becomes obsolete or is replaced by de facto standards.

A good example is the development of the electronic bonding standard. It took a year to define the standard and another year and a half for it to be accepted in the marketplace. By that time, new methods of data interface, such as EDI and the Internet, had become so compelling for applications such as ordering local service that the chance for the OSI standard to dominate already may have passed.

Love it or hate it, client-server technology is here to stay. In fact, it has proliferated to such a degree that its use may be one of the primary factors determining the winners and losers in the telecom market of the next decade.