ms, thresholds and actions, it may be unnecessary to consider the entities and attributes of a threshold in the Enterprise Data Model. It may be more important to consider those attributes of the alarm that must be transferred to the trouble management system in order to open a trouble ticket. The level of granularity to which an IIC must develop its Enterprise Data Model is dependent on the entities being modeled. For those entities (objects or pieces of data) such as customer or order, which are key to achieving greater business objectives like flow-through provisioning, it is necessary for the model to be fairly granular. On the other hand, for entities such as tax information, which may only exist in the billing system, it may be unnecessary to model them at all. Once we have developed an Integration Data Model, we can try to determine which application in the OSS architecture should "master" what data. The capabilities, or more often the limitations, of the selected packages in any given situation drive such decisions. In constructing an integrated OSS architecture based on vendor packages, the next question becomes, "Given that I cannot totally craft my own database design, and that data redundancy will likely exist among packages, how do I select the best package to house or master my data?" As a broad guideline, it is probably best to select the vendor package that contains the broadest coverage of a given data area. For example, the system The Ultimate Guide to Building and Delivering OSS/BSS that does provisioning probably has the broadest view of assignable network inventory. Some subject areas, such as customer and product, are more difficult. In fact, determining which application should master the product catalog often becomes moot as we will see later. In some cases, the decision on which system is the "master" is based on legacy issues, i.e. which system came first and has the better (or worse) level of accuracy. In other cases, where no clear answer exists, this decision can be based on the imple