iginated as islands of automation. They were designed with their own data models, databases and functionality targeted at a specific OSS function. Network activation and billing are good examples. These packages were not, in most cases, designed for integration with somebody else's database. Each package has its own view of the breadth and depth of the data required to meet its functional role. Some packages may house a complex object or data model that stores many attributes and relationships relevant to a customer. Others may only contain very high-level information, such as customer name and ID. In order to build an integrated OSS, it is necessary to establish, for each data subject area within the OSS, a "master" - that is, a system of record for a given data Chapter 6 - Integrating the OSS Platform entity. Without establishing this, it is impossible to determine the event and transaction flows (see below) required to achieve integration. Asking "who owns the data" inevitably leads to the question "what is the data?" What are the entities or objects that should be considered when developing an integrated OSS? The simplistic answer is to develop the "Enterprise Data (or Object) Model" as if the entire OSS implementation were a custom development exercise. A key point to understand here is that in selecting and implementing a set of best-in-breed application packages to form the OSS, one has inevitably selected and implemented the application vendors' data models. So the notion of developing a pure Enterprise Data Model has to be tempered by the notion of alignment with the data models provided by the vendors. Creating the ideal data model may not be useful if it does not map the models provided by the applications themselves. The second major consideration is that the Enterprise Data Model should focus on integration, not custom development. Of primary interest are the data elements that flow among applications. For example, if the selected fault management system has a database that stores information on alar