inventory system would not allow external inventory data to load back through its API. The activation system could activate equipment on the network, but the inventory system could not take the data "as activated" back into its inventory database. This was an issue with one of the more robust vendor APIs available, showing that even the best APIs can lack key capabilities. A possible explanation for this lack of functionality is a difference in perspective between OSS vendors. The network inventory system took a top-down view of inventory, based on service delivery and provisioning processes rather than network equipment discovery. Yet, much network gear comes equipped with auto-discovery features. The activation vendor utilized this capability taking a bottom-up view of inventory to achieve functionality. The perceived issue, from the network inventory manager viewpoint, is that auto-discovery can tell the physical status of equipment at a given time, but it often does not know anything about how the network is logically configured. The activation vendor believed that the inventory application, with a process view, provided more information about network planning and logical topology, and thus the inventory system should be the system of record. This a great illustration of the issues surrounding integration when two vendors develop applications based on fundamentally different assumptions. 18.4 Service Assurance Company: Managed Services Provider (MSP) providing servers and network access from its own data centers, for customers requiring application and Web hosting. Goal: Subsequent to network alarms being isolated to a root cause device failure and outage, determine, or correlate, which customers are impacted by outage and generate trouble tickets for notification. Technology: Leading network management application, EAI package, inventory application and trouble ticketing system. Challenge: Incomplete APIs. Chapter 6 - Integrating the OSS Platform Scenario: When something fails, be it a database or cut fiber 