ion to framework Plug-in can be introduced from standardized the data collection layer and display layer Bring in full standardization for interaction based on SID and OSS/J to have minimal to nil dependency between framework and data collector. Now data collection and display systems provided by a different vendor or supplied by open source can be plugged in to the functional assembly. (Continued) Fundamentals of EMS, NMS and OSS/BSS (Continued) Stage Description Business Benefits Stage 3: Split framework components to Easier to fix bugs and easier to services maintain code The functionalities in the framework are More reuse and return over now highly coupled, hence introducing investment with a service new functionality or adding an open assembly source module is costly from integration perspective. We need to isolate functionality into services and make them loosely coupled. Stage 4: Standardize interaction Can introduce new services with between framework components minimal change in code The loosely coupled functionalities will Easily roll in and out of services need to interact based on standards. Framework can be used for multiple networks Enhancements A full-fledged NGNM address a This includes having a centralized multitude of issues in the registry, repository, and components telecom NMS domain. supporting publish-subscribe architecture. We can enhance it to have a MTOSI adapter. The staged migration can also be performed as a single stage activity where the single stage represents a product release that ensures that the legacy NMS product transforms to NGNM framework. The migration can be performed in line with existing product development merging the changes with the main code base after changes are made for each stage (see Figure 34.12). This way the product functionalities can be augmented while Main code for NMS Check point 1 Check point 2 Check point 3 Stage 1 Stage 2 Stage 3 Stage 4 migration migration migration migration submit submit submit submit Product functional Product architecture transfo