THE ELUSIVE OPEN SYSTEM

Although one RBOC has opened its OSS, few CLECs have achieved full interconnection because of the formidable challenges in creating workable interfaces between disparate systems

As of Dec. 22, 1999, Bell Atlantic holds the distinction of being the only RBOC allowed to offer long-distance service. But for the most part, what separates it from its Bell brethren is a single regulatory requirement: Only Bell Atlantic has satisfied regulators that it has opened its operations support system to its competitors. That task has proved so daunting that the other 13 of the 14-point checklist items seem almost inconsequential in comparison.

The rationale behind the OSS interconnection requirement is simple: New local market entrants need to purchase services and network elements from the incumbent carriers. Unless a competitive local exchange carrier (CLEC) can feed orders into the incumbent's OSS smoothly, the incumbent never will be able to fill orders for the CLEC as fast as it fills orders for its own customers.

To recognize the need for such an interface, remember the early days of local competition, when the only way a CLEC could send orders was to fax them - a process that was fraught with delays and errors. Not surprisingly, orders were often lost as well.

Today, fax-based ordering systems are on the wane, and CLECs increasingly are sending orders into many incumbents' OSSs through a graphical user interface (GUI), often provided by the incumbent carrier (Figure 1). These GUI-based systems typically offer a mechanism for returning an order confirmation to the CLEC to prevent incorrect entries.

But such interfaces still do not achieve 100% interoperability. In addition to typing an order into the GUI, CLEC representatives must re-key the same information into their own OSS. That takes extra time and opens the possibility for errors if they don't type the information exactly the same way in both systems. Also, if a CLEC operates in multiple RBOC regions, its representatives typically have to use a different interface for each RBOC.

To achieve the fastest processing time on orders and the lowest error rates, CLECs must connect their own OSSs to the incumbent carrier's OSS. With such a direct OSS-to-OSS interconnection, a CLEC can eliminate re-keying and can provide its service representatives with a uniform order entry screen that works with all theRBOCs. The intricacies and variations from one RBOC to the next are handled internally by the system, eliminating the need for CLEC representatives to learn multiple systems.

One facilities-based CLEC that has been a pioneer in interconnecting its OSS with several incumbent carriers, including Bell Atlantic, is Allegiance Telecom. "We did it for three reasons," says Jerry Sklar, senior vice president of OSS for Allegiance. "Scalability, minimizing rework and reducing the process interval to the customer."

Before turning up its OSS interfaces, Allegiance faxed its orders to the RBOC. Moving to the direct OSS interface has reduced the service turn-up process from an average of 22 days to 17 days, Sklar says - and the company hopes to reduce that even further.

Faster service delivery could be a major differentiation point in competing with multiple carriers with similar products and pricing, says Phil Cavallo, senior vice president of worldwide sales and marketing for DSET, which supplied interconnection equipment to Allegiance. "If one [carrier] can deliver in 20 days and the other can deliver in five, which one will win?" Cavallo asks.

Direct OSS-to-OSS interconnection already has become a differentiation point for Wall Street analysts who follow the CLEC industry. Investors "won't just rate these companies on access lines but on the efficiency of their OSS," Cavallo says, adding that CLECs figure that the investment in a direct OSS-to-OSS connection is "worth a couple of bucks a share on the open market."

Yet surprisingly, few CLECs have achieved direct OSS-to-OSS interconnection (Table 1). The number of CLECs using a direct OSS-to-OSS interface to support a facilities-based strategy is especially low - and fewer still are using it to support functions other than ordering, such as pre-ordering or trouble ticketing.

Even in Bell Atlantic's region, these numbers are low. But Bell Atlantic has persuaded regulators that it could support a high volume of such interfaces should more CLECs choose to use them, and several other RBOCs seem poised to receive the regulatory nod soon. The question now is, Why haven't more CLECs connected their OSSs to the incumbents' - and how soon, if ever, will they?

An enormous undertaking

One way to understand the complexity of OSS-to-OSS interconnection is to think about the questions that had to be answered first. What communications method should be used between the incumbent and the CLEC? What should the electronic order form, or local service request (LSR), look like? Complicating matters, especially for CLECs that operate in multiple RBOC regions, is the fact that different RBOCs have chosen different answers to these questions The communications method had to be chosen for five different interfaces, including ordering, pre-ordering, billing, trouble ticketing and provisioning. Most RBOCs have chosen electronic data interface (EDI) for most interfaces, but a few are using CORBA (see sidebar on page 18).

In designing the LSR, carriers had to agree on what information would be gathered, how many characters each information field should have and what were acceptable entries for dozens of possible products and services that a CLEC might order.

This task fell to the Alliance for Telecommunications Industry Solutions, which has been tackling open items based on priorities agreed upon by carrier representatives. About once a year, ATIS generates a new version of the LSR. It also may update some of the 20 additional special purpose forms that often must accompany the LSR. Different RBOCs are using different versions of the LSR. And where standards have not yet been defined, such as in the area of DSL, each RBOC typically creates its own interim solution.

Each RBOC also has its own internal business rules. For example, its legacy OSSs may reject an order that says "St." where it expects to see "Street," creating extra work for the CLEC trying to place an order and the incumbent trying to fill it.

Making interfaces to these incumbent OSSs more user-friendly has occupied a host of players. RBOCs have built pull-down menus into the GUI order interfaces they offer to their CLEC customers to help prevent incorrect entries. A few CLECs have built such capability into systems they have developed themselves. And players such as DSET, Exceleron, Mantiss, Nightfire Software, Quintessent Communications and Wisor Telecom have focused on building interfaces into the RBOC systems for the CLECs, creating a whole new product category - and, one might argue, a whole new industry.

A CLEC would need 20 to 30 full-time employees to track business rule changes for all the RBOCs, says Dale Quick, executive vice president and chief operating officer for Quintessent. "The reason most [CLECs] will go with a solution like ours is they can't afford that kind of staff," he says. "You have to spread the smart people around."

Third-party interfaces, also known as gateways, often have something the RBOC-supplied GUIs do not: a uniform order entry screen, regardless of which RBOCs they connect to. The intricacies and variations from one RBOC to the next are handled internally by the system, eliminating the need for CLEC representatives to learn multiple systems.

Typically, a CLEC will start out using one of these third-party interfaces as a stand-alone system, meaning representatives still have to re-key orders into their own OSS. "We provide order entry and limited management of orders," Quick says. "We're not an order management OSS." Order interfaces from Quintessent and some other third-party vendors, however, can be interconnected with CLEC OSSs - and some vendors offer both pieces. Also, some OSS vendors specializing in the CLEC market are working with gateway vendors to integrate their systems.

One of these OSS vendors is MetaSolv, which has CLEC customers using its system with DSET gateways and is in the process of integrating its system with Mantiss, Quintessent and others. Integrating the OSS with the gateway not only eliminates re-keying, it also simplifies the order management process, says Beth Krevis, MetaSolv product manager.

"If you can't synch the two [systems] up, you have to manage separate work flows," she says. With full integration, the delivery date provided by the incumbent LEC (ILEC) is automatically fed into the CLEC OSS via the gateway. Without that integration, CLEC representatives might have to manually re-open the order to add the delivery date when they receive it.

MetaSolv's interface with the order gateway lets representatives enter a retail order without worrying about what network elements must be ordered from the RBOC to support it. The system makes that determination and automatically places the order with the RBOC. "We map a retail order into an LSR," Krevis says.

CLECs using such solutions still may have a long way to go before they achieve full OSS-to-OSS interconnection, however. Implementing such an interface takes time, and most CLECs have concentrated their efforts where they would have the maximum positive impact on the business. Allegiance, for example, has a direct OSS-to-OSS interface with Bell Atlantic for ordering, but it still uses Bell Atlantic's GUI for pre-ordering. Pre-ordering involves such tasks as reserving telephone numbers from an available pool and making sure that the address a customer has provided exists in the RBOC's database.

CLEC pioneers

As daunting as it might sound, a few CLECs actually have undertaken the task of building their own interfaces into incumbent carrier OSSs. Managers at Florida Digital Network, a facilities-based CLEC operating in the Southeast, incorporated interconnection capabilities into the OSS it designed from scratch.

"The implementation of an OSS is often a disaster because the first thing the vendor asks is, `What are your business processes? We'll write software to support them,'" says Mike Gallagher, president and CEO of FDN. "But often [CLECs] don't know their business processes." FDN's approach was to detail its business processes on three 50-foot rolls of butcher paper. "Once it was laid out, we said, `Now that we've got this done, let's get some programmers in,'" Gallagher says. The company offers service primarily in BellSouth's territory but also offers service in some GTE and Sprint markets.

Currently, FDN's OSS-to-OSS interface works only with BellSouth, but the company plans to add interfaces to the other two carriers.

The interface into BellSouth supports ordering and pre-ordering. The ability to pull pre-ordering information from BellSouth's system and feed it directly into FDN's OSS provides a significant edge, Gallagher says. When FDN wins a customer from BellSouth, "we need to know which of five lines are in hunting and what other features are on the line, like three-way calling or caller ID," Gallagher says. "We built a system that can look into the data fields and extract the data so we can populate [orders] accurately. We're throwing their exact data back at them."

Using the GUI provided by the incumbent, CLEC representatives might be able to view that information but would not be able to extract it, Gallagher says.

However, not every local competitor paints such a pretty picture of the OSS interface development process.

In stark contrast with FDN's experience is that of Sprint, which abandoned its project to build an OSS-to-OSS interface. "We built a gateway to GTE, Pacific Bell and Ameritech and watched our maintenance costs rise," says Carol Bussing, Sprint's vice president of product development. Bussing estimates that it would have cost Sprint $27 million to keep up with the change control process just to support a resale strategy - and that cost would have been even higher to support a facilities-based approach.

Instead, the company plans to rely on a clearinghouse operated by Telcordia. Using this approach, which currently is operational between Sprint and BellSouth, Telcordia ultimately plans to provide connections to multiple carriers, including incumbents and CLECs. The task of keeping those interfaces up to date will fall to Telcordia, which will charge each participant per transaction. This approach will cost Sprint only about one-third of what the company would have had to spend to maintain its own gateway, Bussing says.

Telcordia will not be alone in the clearinghouse business. Gateway vendor Mantiss also is entering that market, and other players say they are looking at it, too. As CLECs gain market share, a clearinghouse can provide additional benefits, says Rachit Dhingra, managing director for Mantiss. Eventually, CLECs will begin winning customers from each other and will need a way to interconnect with the OSSs of other CLECs. Using a clearinghouse could be the easiest way to manage connections to multiple trading partners.

In search of parity

If so few CLECs actually have interconnected their OSSs with the incumbent carrier, how do regulators know that ILECs have achieved their requirement to open up their OSS?

This is one of the questions being tackled by third-party testers enlisted by regulators in several states to examine OSS interfaces as part of the approval process for RBOC long-distance entry. Data shows that some RBOCs already are processing some fairly high transaction volumes through RBOC-supplied and CLEC-supplied GUIs - and that they could handle more. Even though few CLECs have undertaken the task of connecting their OSSs directly to any of the incumbents', Bell Atlantic has managed to satisfy regulators that it has done nothing to prevent CLECs from doing so.

Third-party testing has focused primarily on ensuring that the time between an incumbent receiving a transaction from a CLEC and completing that transaction is on a par with the time it takes the ILEC to handle such a transaction for its own customers. When it comes to unbundled elements, this isn't an easy thing to measure because the incumbent doesn't have to order unbundled elements to serve its own customers. As an alternative gauge, most regulators have established benchmarks - turn-around times they expect ILECs to meet in filling CLEC orders for unbundled elements.

Bell Atlantic is required to give CLECs a firm order confirmation within 48 hours, and it then has five to 15 days - depending on the type of order - to deliver. Part of the third-party testing process involves measuring hundreds of parameters to determine whether an RBOC is meeting these benchmarks.

Increasingly, CLECs are satisfied with the incumbent's performance - but they want to see benchmarked turn-around times continue to drop as systems become more efficient. "Our goal is to mimic the interval it takes to change a [primary interexchange carrier] code for long-distance," says Allegiance's Sklar.

Ultimately, how fast a CLEC can serve a customer depends not only on how long it takes the ILEC to deliver but also on the efficiency of the CLEC's own internal processes. Although few CLECs have measured the added gains they get by interfacing their OSS directly with the incumbents', more of them seem to be recognizing that a direct OSS interface can provide an edge. Quintessent has seen a four-fold to five-fold increase in new deals and proposals in its most recent quarter, Quick says, and he expects most of those CLEC customers to eventually interface their OSS with the Quintessent gateway.

DSET's Cavallo supports that view. Six of the last seven CLECs that bought the DSET gateway also are in the process of procuring MetaSolv's OSS, Cavallo says.

Until now, carriers have been dealing with hierarchical needs, Quick says. Many CLEC business plans did not call for large volumes of orders in their early years - but as volumes increase, automation becomes more important. "The choke point is no longer billing. It's now off-net provisioning," he says.

Given the challenges that have been involved in OSS interconnection, it's not surprising that CLECs to date have obtained market share of only a few percentage points. Conversely, it's interesting to speculate about how quickly that market share might jump as most of these challenges are mastered.

Quick expects to see much more competition in the local market in the first part of 2000 and says an OSS interface will be "table stakes" for CLECs. "When competition kicks in, it will kick in fast, and there will be a lot of people scrambling to make sure they have the ability to compete," he says.

In designing interfaces from competitive to incumbent local exchange carrier operations support systems, developers not only have had to work with a huge volume of message formats that vary from one ILEC to another, but they also have had to implement a variety of communications formats.

The predominant format for communication between incumbents and CLECs is electronic data interchange (EDI). EDI, which has been around for about 20 years, is a little like e-mail. Traditionally, messages sent from one carrier to the other sit in a mailbox until someone checks for them. Unlike e-mail, however, many of today's systems operate in real time.

EDI delivery systems, known as value-added networks (VANs), have mechanisms in place to confirm when messages were received - a useful capability that can help prevent finger pointing when disputes arise. VANs also support shared delivery - a capability that Joseph A. Rogers, director of IT for Ameritech Information Industry Services, finds appealing. "When my system is down, the VAN pools messages, and when I'm operational, it pushes them to me," he says.

Some have argued that using the Internet, rather than a VAN, could eliminate the need for CLECs to order a dedicated line to the RBOC. But that approach would entail other trade-offs, he says. "If we used the Internet, I would have to build all that stuff," Rogers says, referring to the VAN's shared delivery and order confirmation capability. "We didn't want to spend all our time doing that. Also, I would have to teach EDI. Now [CLECs] learn that from the VAN."

Most RBOCs have taken the same approach as Ameritech, perhaps because they already had EDI in place to support communication with key vendors. A notable exception is BellSouth. Although that company's first interfaces were based on EDI, it now has shifted its development efforts to focus on CORBA. "We chose CORBA because it matches our view of how the world will work in five years," says Bill Stacey, operations vice president for interconnection services at BellSouth. The company has begun to heavily emphasize CORBA for its own internal systems.

Venkates Swaminathan, executive vice president and chief strategist for OSS gateway vendor Nightfire Software, compares EDI and CORBA: "EDI defines the content of the message. You can print it on a piece of paper. It's encrypted text. There are many ways to get it to the ILEC. You could e-mail it. You could create a file and [use file transfer protocol to send it over] or you can use a VAN. It's like sending e-mail, but it's proprietary."

"CORBA combines the content, which is created through objects, with the transport part. You can't print out an object. It's an abstract entity inside the computer. CORBA replaces the VAN and EDI. It's more a dialogue than a single message. It's easier to use and more well-structured."

Others argue that CORBA and EDI provide comparable performance. "There is no performance degradation between EDI or CORBA," says Phil Cavallo, senior vice president of worldwide sales and marketing for DSET.

Because no single standard interface exists, CLECs wanting to interconnect with multiple RBOCs may have to acquire EDI and CORBA capabilities - and that still only takes care of part of the equation. To achieve full interconnection, CLECs may need yet another type of interface to connect their internal OSS with their order interface gateway: In addition to CORBA, the interfaces most commonly used for that purpose include extensible markup language (XML) and the COMM (component object model) format, originally developed by Microsoft.

Mike Desey, product manager of regulated ordering for OSS vendor MetaSolv, is bullish on XML. "It's a data-based communications language," he says. "It provides independence from the data repository and it lets you run across the Internet so you might get away from fixed pipes."

Dale Quick, executive vice president and chief operating officer for gateway vendor Quintessent Communications, also sees advantages to XML. "XML can be rapidly modified by less skilled people, and you can modify the data without worrying about what you're doing to the [order] form."

To date, the Alliance for Telecommunications Industry Solutions, the group charged with selecting standards for OSS interconnection between ILECs and CLECs, has focused primarily on EDI. It is working on a CORBA interface for trouble ticketing, however, and may develop one for pre-ordering if carriers show sufficient interest. A request also has been made for the group to look at XML as an ordering interface.

Making decisions on whether to adopt any of these new communications formats will require carriers to weigh the pain of making a change against the potential benefits. One thing is clear, though: Like an office LAN, OSS interconnection will forever be a work in progress.