In-Depth
Case Study: From the Back Office to the Internet
The greatest area of concern for an enterprise’s IT department is whether their proposed Web-based sales channel will effectively interface with the legacy or modern resource planning systems. In a world where interoperability standards are honored mostly in the breach, the key to implementing an enterprise-based application is flexibility. Real-time links often must be combined with batch operations in fashioning the right approach for each particular deployment, and cookie-cutter solutions rarely apply in the real world. This case study illustrates these points.
In late 1997, Primus Telecommunications, the world’s fastest growing long distance carrier, found itself embracing continual rapid growth with a manual, paper-based process for order provisioning (processing) that inhibited the company's ability to keep up with high-market demand. There was an urgent need to upgrade the order entry process, which was labor-intensive, and required a prohibitive amount of time and staff resources. In only a few weeks, Primus needed to shift from their old system to a whole new model.
Their old system involved filling out manual order forms, faxing them if necessary to headquarters, and then repeatedly entering the data from those forms into each of the legacy systems in the path of the workflow. The new model was a system where some sales agents could enter data while taking an order within a call center. Others could use the Internet to enter orders directly from remote locations, and still others could fax or mail in their orders to a central order-entry pool. Once the order had been entered from any of those sources, the system would manage the entire life-cycle of that order, providing a common link to the billing system, telecom switches, the offnet provider and other legacy systems in the chain.
Primus made the decision to embrace the Web and automate its business processes. It selected the SpaceWorks OrderManager product as the framework for their new solution.
This article highlights how SpaceWorks and Primus worked together to solve the integration issues, exemplifying one end of the enterprise integration spectrum: the use of batch strategies within the context of a high-availability, online information system.
Many lessons were learned from this project. First, timing issues. In less than four months from the beginning of beta test, Primus had shifted its operational model irrevocably to the OrderManager application (private-labled as Primus Order Entry Management System or POEMS), featuring the application to investors as a critical differentiator in the firm’s potential for rapid and profitable growth. Behind the scenes, OrderManager's ability to act as electronic glue for the network of legacy systems was a crucial component of that differentiation.
The other general lesson was a matter of serendipity, one of those side-effects that takes on a life of its own. To make sense of this lesson, remember that the Primus implementation of OrderManager was designed as an order entry system. In the original blueprint, most users were sales agents (in-house and remote) and order entry personnel. Equally obvious from the beginning was the need to support users in each role of the workflow involved in provisioning an order. And it was clear that administrative utilities, which took more than fifty percent of the development effort expended to build the system, would also be required.
What was not obvious was that a great deal of information carried within the system in order to support order management was also of value to others outside of that process. Soon after deployment, requests began to reach the administrative desk to establish logins with strange new combinations of read-only privileges.
Web-Based Drill-Down
Let’s take a look now at the actual interfaces, not in workflow sequence, but rather in order of significance to the enterprise. First is the interface between OrderManager and the legacy billing system in use at Primus and many other telecom firms, IXPlus. As you might expect, this is a two-way interface. On the OrderManager-to-IXPlus side, two families of transactions are supported: new orders, and credit for referrals (an important marketing tool for Primus). On the IXPlus-to-OM side, Launch Pad-triggered searches locate and initiate processing of response files, which contain account changes and any new orders entered into IXPlus independently of the OrderManager application.
Another important interface connects OrderManager to the communication switches operated by Primus. Here, again, we see the importance of flexibility of approach, because automated interfaces for communication switches are not only proprietary in general, but are non-existent in some cases. With interface specifications in hand, an automated feed was designed in short order, providing online screens for manual switch activation where necessary without adding much staff time.
Closely related from a workflow standpoint was the interface between OrderManager and Primus’ offnet provider (used for services outside the domain of Primus’ own switches). The batch interface consists of a nightly PIC-change file from Primus for dial-1 service, and a response file back to Primus providing complete daily ANI/AUTH changes, plus a number of additional transaction types. Programming for both sides of the batch interface combined was completed in about one week, but as with many such interfaces, it has needed to be changed several times to keep up file format changes.
In addition, the response files coming back from the offnet provider contain data not strictly required by the original Web-based concept, information which was difficult or impossible to use effectively in the pre-Web era. But when the Primus/SpaceWorks team built the automated interface to those response files, they had the foresight to load that additional data into the POEMS database as well, and to make it available online via the Web-based interface. It turns out that some of that data is quite useful as a corporate resource, even though it has no direct bearing on the order process. This helps to explain some of those extra login accounts that sprouted up at Primus after the system went into production.
There are several other batch interfaces integrated into the Web-based application, and the system could not function as well without them. For example, loading the Local Exchange Routing Guide (LERG) into the Web-based system is a complex, 15-step process that deals with the subtleties of connectivity and tariffing. The loader was implemented in about a week, and again has required ongoing maintenance. LERG data allows the OrderManager implementation to provide a good bit of intelligence in the order entry interface, but here again there was serendipity. Once the LERG data loader was completed, in order to support the order processing department, OrderManager was also able to provide some useful business reports for use in other parts of the organization.
Another example is the ZIP code file, which provides real-time validation of city/state/ZIP code combinations. OrderManager also uses the data to provide a warning if the billing or service ZIP code doesn’t match the ANI (area code) of the billing phone number. The ZIP code data converter itself was implemented in less than a week, but it led to an interesting piece of Web technology. By use of dynamic HTML pages loaded into invisible sections of the browser’s screen and containing only JavaScript code, the data entry user need only enter ZIP code in order to have the city and state automatically filled in, instantly, by the software.
Somewhat peripheral to the order process is the interface between POEMS and a fulfillment house Primus uses. Every night a file goes out for preparing welcome kits in various languages. (Primus’ niche is the international market.) The OrderManager application also generates files for in-house printing, such as PIC-freeze letters and rejection notices. Building the fulfillment house interface was a relatively big job, more than three staff weeks, and here’s the reason: No formats existed for expressing the required data until the implementation team developed them, and an awkward BBS protocol, rather than straight TCP/IP, was the means for transmission. That kind of analysis needs to be included in your project planning when you’re building a new interface from scratch.
About the Author: Lindsay Ridgeway is Senior Vice President and Chief Technology Officer at SpaceWorks – a provider of Internet-based business-to-business sell-side commerce solutions, headquartered in Rockville, Md. Mr. Ridgeway has more than 30 years of experience in software development and is an expert in computer languages and compilers, communications, client/server computing, and Internet commerce technologies.