 most cases, the documentation explaining the system is also poor. In this case, the Web portal was built in stand-alone fashion. The developers did not entirely understand the processes they would ultimately need to support. The portal was thus more focused on data Chapter 6 - Integrating the OSS Platform capture and user experience than on back office processes. So a time consuming issue became deciphering and upgrading the Web portal's data model, and mapping it to the OM/provisioning application. Again, with some foresight, the model could have been developed to meet back- end application requirements. In this case, it required intensive analysis to configure the mappings into the integration layer, and required some trial and error due to inaccurate documentation that did not necessarily agree with the actual data model. The trade-off, however, is that many OSS applications are still struggling to adopt the Web paradigm, SO custom Web development can be necessary to gain needed functionality. What is required is that the IIC understand where the new portal fits into its processes and with which applications it will need to communicate. SUMMING UP INTEGRATION It is important when approaching any integration project to anticipate it being more complex and time consuming than one might first believe. The complexity and detail involved with OSS applications and processes can make the process less predictable than would be liked. The good news is that significant OSS integration is achievable. With properly managed expectations and clearly defined business goals, the rewards gleaned from integration can far outweigh the pains. Significant business value can be achieved even with shallow integration of some fundamental processes. Though we have highlighted EAI as perhaps the best current approach to OSS integration, it is not a panacea. The integration process is difficult and complex regardless of the approach or technology set applied. With changing business demands driving increased application flexibility, int