ic technologies that will generate artifacts on implementation contracts, class instance diagrams, and implementation data models. The deployment view has artifacts on contract instances, run-time specifications, and technology specific guidelines. These make up the NGOSS knowledge base. NGOSS lifecycle knowledge base, which is a combination of information from various views, offers end-to-end traceability. It can be considered as a central reposi- tory of information. It contains three categories of information: Existing corporate knowledge: Knowledge from corporate experience. NGOSS knowledge: Collection of artifacts identified by NGOSS. Fundamentals of EMS, NMS and OSS/BSS Community or shared knowledge: Knowledge common to both NGOSS and corporation. This is represented as an intersection of existing corporate knowledge and NGOSS knowledge. 21.4 SANRR Methodology The NGOSS defines a road map that can be used by current systems to align with the reference models defined by NGOSS (see Figure 21.3). This roadmap is based on SANRR (scope, analyze, normalize, rationalize, and rectify) methodology. The methodology can be used for iteration at life cycle level or view level. The outcome of the iteration is to identify the activities and steps required to align with NGOSS components. Let us look into this methodology in detail: 1. Scope: In this phase the area that needs to get aligned with NGOSS is identified. There are multiple processes spread across customer, service, and network management. A modular approach is required to make changes to Scope Analyze Normalize Rationalize Rectify Figure 21.3 SANRR methodology flow diagram. NGOSS the process, architectures, and contracts. In scope, the organization identifies what module needs to be worked on. Although multiple modules would need to be worked on, each module is considered to define an element of scope. 2. Analyze: In this phase the scoped area is analyzed using cases and maps to identify the current system. This activity is intended to get the current model as 