elopers are making their products compliant to MTOSI or OSS/J interface standards. In current industry, compliancy to standards is more a necessity. Let us take a simple example of a simple fault management module. Now the network provision- ing module might request active fault alarms using the interface call "getAlarm- List ()," the inventory management module might request active fault alarms using the interface call "getActiveAlarms ()," and the event management module might request active fault alarms using the interface call "getFaultLogs ()." On the other end, the fault management module might be exposing the interface getActiveFault () for other modules to query and get the active alarm list as response. One solution to fix this problem is to write an adapter that translates the call between modules, like getAlarmList () from network provisioning module to getActiveFaul () that the fault management module can understand. In the example Fundamentals of EMS, NMS and OSS/BSS we are discussing, the solution of developing adapters will result in three adapters for the fault management module alone. So in a service provider space where there will be many OSS solutions, the number of adapters required would make interop- erability costs huge. Again when a new OSS solution is introduced, a set of adapters needs to be developed for the modules it is expected to integrate with. So adapters are not a viable solution that would be cost effective to the service provider. Another option to fix the problem of interoperability is to have standard inter- faces. Let us look into how this works for the example we are discussing. If it is decided by the standardizing body that getActiveFault () is the standard interface for getting active alarms from the fault management module, then the service pro- vider can request compliancy to standard for modules that interact with the fault management module. That is the fault management module that will respond only to getActiveFault () request and any module compliant to standard th