 An immature application-programming interface that evolved along with the integration process. Mapping orders from the OM product catalog to billing system catalog. Scenario: The CLEC faced a classic problem. A significant amount of data was being re-keyed manually in the billing from the OM systems. It would often require 20 to 30 minutes, for example, to add a new customer into the billing system. Automation would save an enormous amount of time and reduce error - a priority for any IIC. The CLEC had not bought into an EAI philosophy, but it did not want to preclude the approach in the future either. It decided to build a point-to- point bridge, but wanted one that could be replaced without too much difficulty if an EAI solution were implemented. The systems integrator, faced with a complex challenge, decided to use some EAI concepts, such as messaging, to get the applications to communicate. Each system was outfitted with an API, one based on Microsoft's COM technology, the other on CORBA. Rather than just link them with some C code, as is often done in point-to-point integration, the integrator used the Java Message Service, part of the Java standard, and some Java utilities to emulate an EAI approach. The main difference was that messages would flow out of the OM and into the billing system across a bridge instead of an actual EAI backbone. Another issue, and one IICs face often, was that the billing system's APIs were new at the time and being developed simultaneously with the integration project. This resulted in a trial-and-error approach and constant rework. IICs must keep in mind that if they are not working with Chapter 6 - Integrating the OSS Platform a well-proven connector or API, an integration project could turn into a full-scale development project. In the end, the bridge/messaging solution worked well, and was a relatively low-cost approach. The long-term problem, faced from the beginning, was synchronizing the product catalogs. It was not possible to automatically synchronize them, SO logic ha