leg or whatever, the network management application must sort through multiple alarms to discover and identify the impacted customers. The MSP, using the network management system to monitor its servers and network links, wanted to be able to notify customers proactively when their services are affected by a fault. This required another level of correlation, namely associating the outage to affected customers. This challenge is especially complex because, as in the previous case study, the network manager understands the physical network, but not its logical constructs. In this case, the network manager can monitor a server, but it does not necessarily know to which customer it belongs. The MSP's integrator, to meet requirements, had to create integration that could take root cause data from the network manager and use the inventory system's API to interrogate network/server inventory and determine to whom the failed server belongs and which customers were affected by an outage. It could then take this information and put a notice on the network management GUI to announce the problem and whom it affected. The MSP decided to allow the staff in the network operations center to decide whether a trouble ticket should be opened automatically. Fully automated trouble tickets are not necessarily the best idea. The applications cannot always prioritize them correctly and cannot adapt to "special" situations where certain failures require no immediate action. A network operations center still needs people that understand when to react to alarm, and when to just "smack the television" until everything works right. Another issue the MSP faced was how to close trouble tickets automatically in the network management system. In this case, the APIs were not sufficient to allow a backward mechanism in which trouble tickets that were closed in the trouble ticketing application would automatically close out and clear alarms in the network manager. An EAI connector was necessary both to support integration and to enable the "backwa