ure 34.2 without any specialized NMS functions. The NGNM framework suggested in this report supports the following: a. SOA for architecture: The functionalities in the NMS are designed as sepa- rate services with standard interfaces for interaction and an XML file for any customization. There is no hard coding of network element specific informa- tion like table names. New functionalities can be added as separate services without disturbing or making changes in existing functions. For example, the performance module may interact with the fault module but is independent of the implementation of the fault module. With this technique, when open source components like an independent subscriber provisioning functionality is added to the NMS that interacts with fault or performance module, retest- ing of existing functions is not required. SOA leads to smooth integration and functionality rich NMS. Fundamentals of EMS, NMS and OSS/BSS Specialized NMS functions Generic NMS functions MTOSI adapter OSS/J Unified NMS framework Architecture Adaptation components Information model N/W management functions Interface model External applications Figure 34.2 NGNM framework. Advantages of using SOA in NGNM framework: More reuse Reduced effort and risk in implementation with independent services Faster development Ease of enhancement Reduced development and test cost Bug fixing and maintenance is easier b. SID (shared information/data) as the information model: The different mod- ules that make up the NMS and the communication between applications and NMS need to use a common format of data and information for interop- erability. SID is currently the most popular information and data model for use in telecom management. The same is adopted for the generic framework development. With SID, first the object in the management framework needs to be identified. This is followed by identification of object attributes and relationship with other objects. Advantages of using SID in NGNM framework: Information in standard format leads to re