duct 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 transformation augmentation over releases Figure 34.12 Code migration. Report: NGNM Framework and Adoption Strategy the transformation of architecture happens. Each stage can be tested and stabilized without effecting delivery to existing clients of NMS product. 34.6.3 Combining Mediation and Migration Not all clients would require a complete adoption of NGNM framework with mediation or migration approach. Different combinations of mediation and migra- tion can be used based on the system involved. A few examples include: Requires isolation of only a specific functionality: If only a specific functional component in the legacy NMS is planned to be reused, then only migrate the components of that functionality and use mediation for the rest. Requires only reuse of data collectors: Detach functionality from data collec- tion as in Stage 1 of migration and get the generic data collectors. Now write mediation adapters for working with functionality block. 34.7 Analysis of NGNM Framework Attribute Legacy NMS NGNM Solution Usability Multiple GUI interfaces and Converged solution leads applications make legacy NMS to ease of handling and less user friendly, thus bug fixing. increasing the time required to fix a network issue. Modifiability Due to interdependencies in SOA-based NGNM is modules, it is not easy to make made up of self-sufficient changes in a cost-effective modules that make manner. addition of functionality or making changes easy. Maintainability The maintenance cost goes on Easier to maintain and fix increasing with minimal reuse bugs. and dupl