application and publish them in other applications necessary. For example, it may be necessary to "publish" customer account updates captured within the customer relationship management (CRM) application and post them to the OE/OM and billing systems to maintain data synchronization. THE INTEGRATED OSS PLATFORM There is no generic, one-size-fits-all, integrated OSS architecture. The correct integrated OSS architecture is derived from multiple factors inherent The Ultimate Guide to Building and Delivering OSS/BSS in an IIC's business model. The principle factors that shape the integrated OSS are the targeted customer base, the product and service offerings, the proposed sales model, the network architecture, the supply chain and the competitive positioning of the IIC, as discussed in Chapter 3. Therefore, a discussion of exactly how one achieves an integrated OSS is highly dependent on the individual IIC. Later in this chapter, we present case studies that illustrate how specific categories of IICs might achieve integration. To begin, we will make some fairly generalized assumptions about the structure of the OSS. We illustrate some of the major integration points and challenges an IIC will face. To do this, we will set up a fairly typical IIC's business model, and assume that it has selected a sales force automation/CRM package, an order management and provisioning application, a network activation package, an LSR gateway, a network monitoring application and a billing system. We will also assume that the IIC wants to provide a Web portal for customer self- care and that it wants an integrated data warehouse for reporting. With this example as a backdrop, we can begin to consider what is entailed in integration. WHO OWNS THE DATA? Complications arise when we consider which application "owns" what data. This question sometimes puzzles newcomers to the OSS integration space. Why, they ask, can't all the systems use a common database? The answer lies in the fact that most of the popular, contemporary OSS packages or