e 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 that interacts with the fault management module is expected to use the standard interface. When a new module is introduced that is compliant to standards interoperability with fault management module, this will not be an issue. This chapter explains the fundamentals of MTOSI and OSS/J SO that the reader can understand the significance of interface models and how an interface model can be used in developing applications that are compliant to standards. The com- mon terminologies used in the standard documents on interface models are also discussed in this chapter. 25.2 MTOSI Overview Before we discuss MTOSI, let us first give a brief overview on MTNM the prede- cessor of MTOSI. MTNM was for