5.2. Business and Technological Challenges

The CORE application development team was faced with a number of critical challenges, from both business and technical standpoints. Its ability to handle these challenges was key to the success of the solution.

5.2.1. Business Problem

Major legislative and competitive changes in the telecommunications industry led AT&T Unisource to seek significant reductions in off-net voice traffic costs. To do this, it needed the ability to reconfigure network switched routing tables regularly—monthly or even daily. The CORE system was proposed to provide a real-time routing configuration environment supporting both least-cost routing (LCR) and optimal-cost routing (OCR). LCR is to the voice network routing what Hotspot is to Java technology process execution, an effort to improve the performance of an existing design without altering it. LCR provides improvements, but it is limited by current network design and contractual obligations. OCR provides an approach based on optimizing the design of the network to allow even further improvements by LCR.

5.2.2. Obstacles

In designing and developing the solution, the team was presented with many obstacles, including automation of routing configuration for all switches on the network simultaneously. At the time development began, these operations were performed by highly trained switch engineers and even the smallest changes could take considerable time. Automating the process had the potential to reduce this effort, but would require a solution that could span multiple machines with different operating systems. This made the use of system proprietary technologies untenable.

To meet its design goals, the system needed to provide a software model representing the structure and configuration of the network at any point in time, for both accounting and auditing purposes. Some devices on the network used existing C libraries and interfaces, so CORBA technology (included in the J2EE platform) became a requirement for enabling objects implemented in different languages to interact. While Java Native Interface was also considered for this purpose, the team preferred an object interface around existing libraries for easy, transparent process distribution.

The CORE system also needed to let carriers submit pricing details efficiently, with less human intervention. XML technology was used to supporting this business-to-business communication. A carrier could submit pricing details by posting an XML document to a Web server. A document type definition (DTD) would be provided to all carriers to ensure the validity of the data. This simplified communication mechanism made it possible to speed up data entry of pricing information and turnaround of the routing process. Through its built-in validation mechanism, XML helped ensure high quality of the pricing data entering the system at either end. It also removed dependence on application macros formerly used for this task. These had previously been written and maintained in office productivity applications by the staff, so the CORE system helped to improve efficiency by eliminating this user burden.

5.2.3. Requirements

Because the CORE system was intended to offer a high level of automation, issues of scalability, reliability, failover support, and performance needed to be addressed early in the design process. Though the CORE system didn't initially have a large user population, scalability was important for other reasons, including the high level of user interaction, the required responsiveness of the user interface, and the complex nature of the transactions.

Another requirement was that the system adapt to the needs of several departments, each requiring access to certain information from all areas of the system. At the same time, it had to provide a robust security model to protect sensitive information that might be exposed as a result of this wide accessibility.

To maximize the potential savings and to meet contractual obligations, the system needed to be highly reliable and available. It needed to ensure that pricing data submitted by carriers could be acted on quickly and securely. Actions had to either execute completely or be rolled back completely in the event of system failure. With less dependency on switch engineers, the interface to the network needed to be available around the clock. This was required to allow business managers to monitor network configuration and to ensure that the system was meeting various operational goals, such as quality of service and cost effectiveness.

As in any distributed system, performance was an important factor, requiring early and constant attention. The CORE system needed to quickly create a software model of the network for any user and within any time frame. Along with batch updates to synchronize the database with routing tables in the network switches, transactions needed to be sufficiently fast to provide a “real-time” view of the current configuration. The routing models involve complex calculations, spanning large sections of network elements that needed to be represented persistently for modeling purposes. Optimized persistence would prove to be an important factor in meeting performance objectives.

The level of automation introduced to the network configuration process made it critical that the underlying architecture be robust and reliable. If any of the requirements specified here had not been met, the result would have been reduced confidence in the system, from both business and network engineering perspectives. This would have meant reduced reliance on the system and an end to future development. With this critical factor in mind, mature technology implementations were assessed.