Keeping ahead of customer growth and delivering on new services is a priority for most organizations. Legacy systems--some dating back decades--impose technical barriers to proactive change that prompt savvy thinking about ways for keeping the service infrastructure more than a match for the job.

These are clearly pressing issues for telecommunications providers. Carriers are engaged on several fronts at once, dealing with local number portability, VoIP 911, and wireless E-911 Phase II with more precise automatic location information. Increasing volume of E-911 calls--industry watchers expect a 14% increase in 2004 to more than 250 million calls--combine to put adaptability and operability of service infrastructures squarely on the critical path.

Many carriers responded 10-plus years ago to public needs for basic E-911 services by outsourcing critical data management, number and location identification, and call routing to public safety answering points (PSAPs). In a third-party role, Intrado built a state-of-the-art service infrastructure, and it's still correct to think of the infrastructure that way, having developed a practice of keeping it up to date and adaptable to new service requirements.

In an effort to increase data flexibility and throughput of emergency services infrastructure, the company's Software Development Group began evaluating a managed evolution of systems to meet business needs. The emergency services infrastructure was originally based on K-Series NonStop servers from Tandem Computers (acquired by Compaq in 1997, preceding HP's acquisition of Compaq in 2002). These servers were sophisticated enough to withstand single point failures and achieve real-time transaction processing with a proprietary flat file system, Enscribe. Trouble was, the database prevented straightforward file conversion without completely rewriting the application software. Nor did it lend to the greater flexibility in accessing the database that next generations of services applications required. The group's research pointed to numerous operational efficiencies of NonStop SQL, which had become the de facto industry standard relational database for NonStop servers. For one, NonStop SQL and its relational database architecture are built for dealing with huge amounts of data. The choice had positive implications on the company's ability to meet SLAs and quickly develop new emergency services.

NonStop SQL also allowed the ability to open applications by using modern industry standard methods including ODBC, JDBC, XML, and JavaScript. While changing an Enscribe flat file required considerable programming resources and expertise just to change fields or add columns to a file (implicitly involving months of programming and then shutting down the system for an hour or more), the same operation with NonStop SQL is performed online in moments.

Developers know there's a limit to what can be squeezed out of a flat file database system before giving serious consideration to using more efficient relational databases. But technical issues surrounding any migration must be addressed. In fact, the company was already quickly making NonStop SQL a practical reality. Even as the software development group studied the merit of transitioning existing E-911 services to NonStop, new products and services were developed using NonStop SQL. These enable, for example, PSAPs and county coordinators to use new SQL-based applications when they request verifications and extracts of the Master Street Address Guide (MSAG) via the Internet. PBX 9-1-1 location service, which involves complex querying, became far more efficient when implemented with the relational SQL approach.

A key question remained, however. Was a transition that seemingly involved re-writing all of the legacy E-911 applications to use relational SQL structures really feasible and achievable? The group's view of a traditional migration was that it would require years, even using automated parsing tools to convert individual code statements and test.

"Development groups that maintain a clear view of the big picture, particularly in the emergency services world, ensure success in the details," said Stephen Meer, Intrado chief technology officer. "As such, a key requirement was to change the legacy application database without interrupting services or introducing extraordinary risk. Secondly, system performance had to be enhanced without new hardware or overly complex software change." The two requirements eliminated any kind of big-bang approach to transitioning. However, EscortSQL from Carr Scott Software afforded another approach that was immediately appealing as initial testing confirmed.

The idea was to set up a bridge between the new database and the legacy E-911 service applications, thus retaining successful service logic. To test this, the group used EscortSQL to convert the E-911 database and 10 of the most important tables. This enabled use of a NonStop SQL database instead of an Enscribe database, while continuing to use legacy application code written for Enscribe.

EscortSQL emulated Enscribe operations as SQL statements against the SQL tables. The goal was to confirm service orders were received from carrier customers and the data saved through the bridging was entirely complete. Therefore, tests and benchmarks validated that the service order data was still being verified for correctness, including address, service provider and routing information.

First stage benchmarking was completed in five days. The next stage, implementation, was accomplished in about two months using existing hardware and without touching the E-911 application source code. During a third stage lasting several years, services operated using EscortSQL to support the mix of SQL-based services with some legacy Enscribe. During that time the software development group wrote dozens of new emergency service applications (previously mentioned).

A hallmark of the overall approach for updating the service infrastructure was the relaxed window of opportunity it afforded for the last phase: completing the migration from all Enscribe to all native NonStop SQL, as well as addressing any possible Y2K data issues.

In accordance with time and priorities, the remaining legacy code was reviewed and then changed to use NonStop SQL natively. By 2002, all 200 of the original object modules were rewritten and ran in native mode, thus increasing the efficiency of the applications. In many cases, the development group implemented the new modules as a normal part of the maintenance process. The group subsequently consolidated hardware, replacing the K-Series servers with a single HP NonStop S-Series server.

The benefit of time and developer savvy should not be underrated. When the company discontinued the bridging with EscortSQL May 2003 and used all native SQL-based applications, the comparable code base had been reduced by 15%. Service processing was also improved, which is extremely significant for its impact on services that carriers' see (i.e., validating the MSAG/address, number owner, switch, and corresponding PSAP). These operations are now accomplished on a transactional basis at any time. As such, data records at any given moment are more accurate.

David Oberto is Intrado's director of systems engineering.

For more information about EscortSQL, see http://www.carrscott.com.