Case Study: Rapid Integration of PIC CARE

Carriers that add new applications into legacy environments often discover that they must hold it all together with a complex system of ropes and pulleys, and they may wonder if they’re really any better off. This case study about integrating PIC CARE processing for an ILEC describes an alternative approach that uses business process management.

Background

Most carriers face major challenges when they integrate new and legacy applications to support new products, services and operational automation. Efficiency and competitive pressures require that systems communicate and cooperate with each other, yet many have significant design limitations that hamper integration. The need for end-to-end integration and automation of OSS functionality collides with domain-specific applications that don’t integrate easily.

Business-as-usual solutions involve either developing custom point-to-point interfaces, or implementing data model-based, message-oriented enterprise application integration (EAI) tools. Each approach involves major investment for development and maintenance, and tends to limit support for reporting and exception handling. Ultimately, sub-applications must be written, which compounds the complexity and difficulty of the problem. But according to one Midwestern carrier, using a business process management systems (BPMS) to address the problem can be highly effective.

Iowa Telecom’s PIC CARE Challenge

Iowa Telecommunication Services (ITS) is the 14th largest ILEC in the United States, with approximately 290,000 subscriber lines served by 297 local switches. ITS purchased these properties from GTE in July 2000 and implemented a set of commercial off-the-shelf applications for OSS and BSS functions. It contracted with Munro & Associates for support during the cutover from GTE to ITS for operational control; strategic systems planning; systems selection, implementation and testing; and operational management of Primary Interexchange Carrier (PIC) Customer Account Record Exchange (CARE).

The company’s aggressive timeline for business activation limited the potential for integration during startup, so it was already known as an issue that had to be addressed. The strategy was to pilot the integration technology first for a bounded business problem as a proof of concept and thus PIC CARE was selected for the pilot effort.

Local phone companies and long-distance carriers exchange PIC CARE records to implement customers’ decisions to change long-distance carriers. The change process is complex and filled with the potential for errors, and failure to execute it correctly can impact the business on many fronts. Orders must be processed according to specific rules, in specific sequences. Mishandled transactions, slamming or even cases where family members don’t communicate about changing carriers can result in complaints to the state public utilities commission or FCC. Cumulatively, such missteps pose the risk of fines or revocation of certification. Furthermore, processing delays create friction between the long-distance and local providers, delay revenue, prevent carriers from billing their new but still unidentified customers, and add to the general distrust between competitors. These delays can also result in fines.

ITS initially handled PIC CARE processing as a 35-person manual effort involving “swivel-chair interfaces” among a gateway database for PIC CARE trading partners, the order management system, a legacy switch provisioning application and billing system. This manually supported environment processed approximately 55,000 PIC changes per month,. No single, authoritative source of data existed in any of the applications, and some of the required data was not present in any of the existing systems.

The gateway vendor collected and transmitted transaction files for ITS between the service provider gateway and 128 interexchange carriers (IXCs). Transactions could originate externally or internally, and were accepted via voice, magnetic tape, fax and FTP.

Defining the Approach

According to Brian Naaden, CIO for ITS, the company had three business objectives for PIC CARE integration. The first was to drive down operational costs through automation of PIC processing. The second was to support the company’s revenue assurance and customer service goals by enforcing business rules to perform accurate and timely PIC processing. The third objective was to pilot an integration strategy that ITS could afford, reliably implement using a phased approach, easily maintain and leverage to provide high ROI in short time frames.

Proposals recieved mostly involved the well-established message-oriented EAI packages as the primary toolset. But these tools carried three potential problems. First, they required that ITS have a deep knowledge of its existing OSS and BSS data structures, which can be a serious challenge for a startup company. Second, all involved development and implementation time lines of eight months or more. Third, all required a budget higher than what ITS planned to spend for the pilot. “We simply could not find a solution that we had confidence in that would allow us to quickly implement the solutions we needed at a price we could afford using traditional middleware technologies,” Naaden says.

In addition, Munro had serious concerns about the dominant EAI vendors’ use of publish-and-subscribe message bus architectures, because they are asynchronous in nature. This is a mismatch with the characteristics of many cross-application processes in the telecom environment, including internal processing of PIC CARE records with related orders and switch updates. These transactions are synchronous in nature. Converting asynchronous message bus events and datagrams to synchronous application programming interfaces (APIs) with multiphase commit characteristics is inherently a problem. It increases complexity, and it is hard to implement, hard to maintain and costly.

This is not to say that the publish-and-subscribe approach doesn’t have its place. That architecture is ideally suited for bulletin board and stock quote systems that distribute small datagrams to large numbers of recipients. Such applications are asynchronous by default. However, this architecture’s “fire-and-forget” approach cannot ensure the complete processing of an order and provisioning of service to a customer.

ITS is not the first company to have noticed the limitations of middleware in this regard. Tom O’Dea, cofounder and president of the western region of Foxfire Consulting, has observed that “middleware vendors are having more success in other industries than telecom, because this market provides a challenge that is a little beyond what the vendors planned for. They have to mature a little and, frankly, be able to manage more interfaces and more complexity … The reality is that it’s not only how complex the telecom architecture is but how much of that is constantly changing because of changes in software, the product catalog, and the company as a whole.” (See “OSS Integration: Telcos Struggle to Connect the Pieces,” Billing World, February 2001)

Based on the needs for cost control, rapid implementation, synchronous messaging support and maintainability, Munro and ITS identified Fuegotech’s business process management tool FuegoBPM as a possible alternative. It is designed to define, model, script and execute business process “supervisory applications.” These represent the business processes, rules, and manual methods and procedures that all too often are bridged by using ‘swivel-chair’ activities between existing applications.

Unlike processes created with business modeling tools, the processes defined in FuegoBPM are executable, because its EAI capabilities provide preconfigured connectors to underlying application technologies. As a result, the executable business process supervisory application can trigger a company’s existing applications using component services and APIs, as well as manage the flow of work to and from employees.

Business Needs

ITS’ objectives were to automate more than 80 percent of all PIC changes and billing name and address (BNA) requests, and to automatically manage errors and exceptions. If these objectives could be accomplished, staff dedicated to PIC processing could be reduced by over 80 percent, the remaining staff could be dedicated to error handling and management reporting, and outsourced vendor services for B2B interaction could be eliminated.

CIO Naaden also wanted to create an environment where employees could define, refine and add rules over time to increase automation, despite the fact that the company’s hometowns of Newton and Grinnell (populations 15,000 and 9,000, respectively) are not flush with a supply of highly skilled Java programmers.

PIC CARE records are exchanged between carriers using industry standards defined by the Order and Billing Forum (OBF). The exchanged records are labeled with four-digit identifiers called Transaction Code Status Indicators, or TCSI codes. An analysis of ITS operations revealed that out of the hundreds of TCSI codes theoretically possible, just 51 represented the vast majority of the repetitive daily work of the 35 employees. The 51 key TCSIs to be automated included subscription orders, disconnects, access carrier (AC) requests for information such as BNA, and access carrier notifications.

Further analysis identified several priorities and their benefits. First would be to automate switch updating and provisioning, so that the company could quickly and accurately implement customer or IXC initiated change requests. Second was to eliminate the outsourced tape and FTP processing, in order to bring control of the process in house and reduce costs. Third, automate BNA responses to IXC requests to ensure regulatory compliance and earn additional revenues. And fourth was to automate and integrate the process of entering orders into the PIC gateway from the order management system and vice versa, thereby, processing orders more quickly, and ensuring very high levels of accuracy.

Implementation

The implementation relied heavily on FuegoBPM to model processes, build technology connectors, and publish models and scripts into Java. The project involved the following steps:
1. Defining the functional requirements
2. Modeling the business processes
3. Taking inventory of existing APIs for underlying applications
4. Writing simple Java wrappers to access the underlying CORBA APIs
5. Introspecting and building the technology connectors, and creating a library of
methods and procedures for the underlying application component
6. Writing application services scripts that defined how to use the selected methods and
procedures
7. Capturing the business rules of the business process in simple, executable scripts
8. Publishing the process models, business rules scripts and application services scripts
into Java code
9. Deploying the digitized processes onto the process server
10. Executing a user acceptance test
11. Migrating the tested business processes and supporting scripts into production.

The project was not without difficulty. The primary lesson learned was the importance of using great care to address application data elements that are not API-exposed. In the absence of developers who intimately know the system in question, future efforts may address this issue by using application graphical user interfaces, if necessary.

Outcomes

ITS was able to integrate its service provider PIC gateway, order management system and switch provisioning system in just 2 1/2 months. The endeavor “has given us a tremendous operational uplift and dramatically reduced our operational expenses associated with PIC CARE processing,” Naaden says. Furthermore, the project was completed for less than half the cost of traditional efforts, resulting in a faster and larger ROI.

The automation and integration project achieved flow-through automation of more than 80 percent of the PIC CARE transaction volume, as well as automated exception handling through the use of active exception task workflow and management. This outcome enabled ITS to reduce full-time staffing by 91 percent, and to eliminate outsourced vendor services and associated expenses.

The results of this project indicate the potential value that all telecommunications service providers can achieve by carefully evaluating their middleware or integration strategies.