 Vendor 1 GUI Vendor 2 GUI Vendor n GUI Northbound interface GUI adaption layer Framework components Framework Data collection Data collection Data collection agent 1 agent 2 agent n Data plug-in NE1 from NE2 from NE3 from vendor X vendor Y vendor Y Southbound interface Figure 34.6 Grouping of functionality in Stage 1. Report: NGNM Framework and Adoption Strategy Vendor 1 GUI Vendor 2 GUI Vendor n GUI Northbound interface GUI adaption layer Published interface agreements Framework components Framework Published interface agreements Mediation layer Data collection Data collection Data collection agent 1 agent 2 agent n Data plug-in NE1 from NE2 from NE3 from vendor X vendor Y vendor Y Southbound interface Figure 34.7 Standardized interaction between framework and data plug-in. provided by a different vendor or supplied by open source can be plugged in to the functional framework (see Figure 34.7). The data collection also needs to be made generic, SO that the data collector developed for a particular protocol can be used across multiple NEs using the same network management protocol. An example of the change in data collection is to remove any hard coding of tables to read when collecting data from the code to xml files. This stage can be split into interface standard, information standard, and reusable data collectors. Stage 3: Split Functional Framework to Services The functionalities in the legacy NMS have a high dependency between modules or a major chunk of functionality end up in the same module. We need to isolate func- tionality into services and make them loosely coupled in this stage. This is similar to the way the functionality is exposed in the user interface where each service is pro- vided by a different option selected in the user interface (see Figures 34.8 and 34.9). Stage 4: Standardize Interaction between Services The loosely coupled functionalities cannot scale easily for new applications and interoperate with a newly introduced service unless the interfaces for the services are well defined an