SYSTEMS? Having established our Integration Data Model and determined the master for each subject area, we can begin to discuss transactions. We use the word "transaction" to describe the events and their associated data elements that are exchanged among applications to achieve the desired integration effect. To achieve the desired integration, many transactions must be defined and mapped among the different applications. As with many aspects of integration, the best approach to design is both top down and bottom up. The bottom up element encompasses the actual application programming interfaces (APIs) that the vendors have provided to their individual packages. Ultimately, integration is achieved by flowing transactions between the APIs of the individual packages. This is why it is necessary to develop a detailed understanding of the functioning and behavior of these APIs and to match their capabilities with the transaction model that is developed in a top-down fashion. The top-down approach starts with the highest-level business goals, e.g. flow-through provisioning. The next level breaks the overall goal into smaller sets of initiatives, e.g. flow-through provisioning for new orders. The subsequent level then takes into account the actual application packages that are being implemented then overlays them with the appropriate business transactions. For example, in order to integrate the sales force automation or CRM front-end package with the order management/provisioning system for "new order flow-through," several business transactions may have to occur, such as checking service availability, scheduling installation date and passing The Ultimate Guide to Building and Delivering OSS/BSS the completed order. The list below provides an overview of some of the high-level business transactions associated with achieving our hypothetical IIC's business goals. These goals include: - Order Flow-Through - Service Assurance Flow-Through Deriving Integrated Business Intelligence - Business Goal: Order Flow-Through The ov