necessity. The key is having integration middleware that can derive and associate related data as it flows across the OSS from any and all of the applications we have discussed. The actual need for any of these transactions described above and the direction of flow in each case is highly dependent on the set of application packages that define the OSS, and on the decisions made earlier regarding the master application for each data subject area. Once these transactions have been defined, the actual task of technical integration can begin. How technical integration is achieved is the subject of the rest of this chapter. WHY IS INTEGRATION SO DIFFICULT? Application Integration is nearly always more difficult, more expensive and more time consuming than people anticipate. Some analysts estimate that organizations spend up to 35% of development time creating interfaces and points of integration for applications and data. Moreover, most problems that pop up when developing software have something to do with integration. Why is this the case? The answer is as complex as the task itself. The devil truly is in the details of the task, however, at a high level, three basic root causes can be identified: Application Package Flexibility. While a good thing, and probably an inherent reason for the success of the packaged application industry, the way flexibility is achieved in the application packages often provides a tough integration challenge. Process and Data Assumptions. Flexibility is not limitless. Typically, application package flexibility is achieved within a framework that contains inherent assumptions about the process that is being automated and the underlying data. When the assumptions of package vendor A do not meet the assumptions of package vendor B, conflicts often arise that can only be resolved in the integration layer. Application Programming Interfaces. From the outset, few vendors took the view that their package would become a part of an integrated OSS. As a result, many began retrofitting APIs onto th