ts. These challenges, by and large, exist regardless of the technical approach to integration one selects. The application vendor's interface does not (currently) support the required function or data exchange. This can be a major roadblock when it comes to implementing some desirable integration transactions. The best example of this is the product catalog. It is highly desirable to have an integrated product catalog across all OSS components. The reality today, however, is that many OSS applications do not provide capability or function to import an externally defined product catalog. Individual OSS applications are implemented initially in a "stove- pipe" fashion with no view to future integration. This approach leads to functional overlaps and data misalignment across package applications. The net result is that functions and data models need to be normalized and aligned across applications that have already been deployed. This in turn presents cost and training issues. A potential solution is to create more and more intelligence in the integration layer in order to resolve these misalignments. This approach leads to the integration layer becoming more complex and in itself becoming a maintenance headache as the rules and transformations need to be continually maintained and updated. Integration presents another point at which things can go wrong. The lack of facilities for handling error fallout and recovery of messages can often lead to a perceived failure of integration. A final challenge is the difficulty of creating integrated test data and scenarios to validate operation of integration across multiple environments. At the time of writing, it is probably true to say that no IIC has achieved total enterprise integration for their entire suite of OSS applications. This does not mean that integration is not possible. It means only that total The Ultimate Guide to Building and Delivering OSS/BSS integration is not possible today. Many IICs have achieved partial integration, and in the process have derived tr