Author: Philip Jung, yohaim@gmail.comBlog: http://telcoconsulting.blogspot.comTitle: Telecom Integrated Services Architecture

New Way to View ServicesBefore introducing solutions to address the operational challenges of a converged, multi-service network, carriers must first rethink the way they actually build and manage services.

The industry currently model products and services in a very silo’d approach. The introduction of a multi-service network requires a more flexible Service Building Block model for building and managing services. Ideally, new services should be constructed from common, reusable lower-layer service building blocks. To provide a common understanding of how services are constructed and managed across the entire enterprise, [SI] introduces the concept of a Services Catalog. The Services Catalog provides a framework in which new services are constructed and operationalized based on modular service building blocks. This Services Catalog framework is shared across the entire organization, promoting the reuse of processes and systems – dramatically reducing operational costs.

Although related, a Services Catalog is not a traditional Product Catalog – which is typically found in CRM and billing systems and models what you offer and sell to customers (i.e. which services you can sell to which customers, pricing, etc.). Ideally the two catalogs are provided in a single set of tools to simplify the relationship between products that are offered and the underlying services that construct those products.

The following diagram illustrates the relationship between a Product and Services Catalog.생략Figure 1.2-A: Relationship Between Product and Services Catalog

As the next diagram illustrates, the Product and Service Catalog should also model how Service Building Blocks should be constructed to create new, aggregate building blocks and products.

생략Figure 1.2-B: Services Building Blocks

In this example, a Consumer DSL (Internet) product is constructed from a general Internet Access service building block (which is part of a broader IP suite). In this case, the Internet Access service uses ATM as the L2 Services and includes an Ethernet NIC that is provided to the customer. The ATM L2 connection is provided over the DSL access method, which includes the Copper Facilities and a Modem (ATU-R). By breaking the model into modular building blocks, the same ATM model, and associated order entry screens, could be leveraged by the BellSouth ATM product.

The Services Catalog provides a number of major benefits to an integrated OSS architecture:

By describing services in such a way that they are created by elementary building blocks, it promotes reuse of processes and systems. For example, the same ATM provisioning processes and systems can be used for DSL Internet access as BellSouth ATM services. Without decomposing products into their basic building blocks, it becomes very difficult to reuse processes and systems to support new products and services. In addition, a CRM or provisioning tool can generate order entry and provisioning data capture screens derived from the Services Catalog. The same ATM data entry screens can be used for Internet DSL as BellSouth ATM services, providing conditional logic for what parameters can be edited. This avoids having to reproduce ATM process and system functions for each way in which ATM is used in constructing a service.Systems leverage the Services Catalog to model new technologies and services. The modular nature of the Services Catalog makes it easy to extend the model to introduce new technologies, services, and their relationships. To facilitate this extensibility, each operations support system should be able to model the Services Catalog using its own services and technology models.Systems leverage the Services Catalog to determine how a service is constructed, provisioned, and managed. For example, by understanding how a service is constructed, a Next Generation Integrated Order Manager (IOM) can decompose a customer order into related service orders and route them to the appropriate workgroups, inventory and provisioning systems, and external service providers. It also can manage dependencies across Service Orders. The Services Catalog simultaneously models how services are built on top of one another and the relationships between layers of technology. These relationships form the foundation for inter-domain network and service management. By following the same model as the Services Catalog, operational support systems can understand how one layer of services or technologies interacts with another.By modeling how services are constructed in consistent model, data can easily be shared across systems, dramatically simplifying integration. The Services Catalog becomes a key enabler of an integrated OSS architecture.

To leverage the Services Catalog to simplify the operations of services, the tools that implement the Services Catalog should be able to:

Model some degree of inheritance between components at both the product and service building block level. For example, most data services require some form of network Access By creating a base Access class, specific services such as Dial, DSL, Ethernet, and SONET can be derived. Higher layer services (e.g. ATM) can also reference the base Access class to model additional solutions. This avoids having to create a separate ATM DSL and ATM SONET product set. Instead, the application can pull in only the desired order entry or provisioning screens without having to display detailed information for other access mechanisms. In addition, integration may only require that the service understand the concept of Access, rather than having knowledge of each specified access method. This inheritance can also be leveraged to better manage attributes. Attributes that are common across all specified services can be included in the base class. This means that port speed information that is common to ATM, FR, and SMDS, can all be modeled and stored in a single location, L2 Service, without having to model port speed for each specific service. It also means that integrations, such as flow-through activation for Bandwidth on Demand, can act on the L2 Service level, and can potentially be reused across all three services.Model the relationships that exist between components. For example, the Voice service building block may have a number of related Features (e.g. CLASS) associated to it. These relationships can either define how a product extends another product, or can group products into bundled solution (e.g. VoIP consists of Internet, Voice, and UC/Features products).

Just as the multi-service network uses a modular approach to construct new services, the Services Catalog drives the same set of disciplines into the processes and systems required to operationalize the service.

At the core of the Services Catalog is the Shared Information Model, which provides applications a common data model to describe information. In addition, our Market Offerings utilize the Services Catalog model to promote re-use of functional capabilities and services.

Integrated Best-of-Breed Philosophy and ArchitectureOver the past few years there has been a drive in telecom to find a single vendor operations support platform to provide all of the capabilities required to operationalize a converged, multi-service network. Theoretically, this single-vendor platform would provide Infrastructure Planning, Service Delivery, and Service Assurance functions for all technology domains and services across multiple vendors’ equipment, all under one roof. Unfortunately, as recent history has repeatedly demonstrated, no single platform has been able to address the breadth and depth of capabilities required for Next Generation networks and services. In fact, even simpler technologies and services have proven illusive due to the complexities of managing service offerings.Failure of Monolithic SystemsBased on our experiences with telecom carriers and knowledge of commercially available Operations Support Systems, [SI] believes that no single vendor is capable of providing a complete solution to support a Next Generation network. It is our experience that when vendors try to provide a single solution that addresses all functional OSS capabilities across the entire domain of technologies and services, they typically do not provide the appropriate level of depth in each functional area. They also do not provide the breadth to manage each of the network technology domains. The end result of these “Best in Class” or single vendor solutions is a “monolithic system” that does nothing well.

The CLEC world provides an excellent example of the difficulty of using a single OSS platform to manage all functional and technical domains. A leading software vendor (termed Vendor A) developed a monolithic product (termed Product A) that was built from the ground up to provide “CLEC in a box” OSS capabilities to support a telephony oriented CLEC. As a result, it dominated the CLEC market.

Although Product A provided a strong platform for order management, inventory, and provisioning to support POTS services, it did not provide full functional coverage. For example, separate products were required to activate telephony services, and a completely separate suite was needed for Service Assurance. Despite focusing on a very narrow niche –CLEC’s, Vendor A could not provide the full range of functions needed to operationalize POTS. Given the drastically different requirements for Service Assurance, Vendor A had to team with System Integrators and other vendors to provide a complete functional solution.

In addition to not being able to provide a complete set of functional capabilities, Vendor A had a difficult time addressing new technologies. As CLECs started to offer data services, the product had been so focused on operationalizing a single set of services (i.e. telephony), it was not able to evolve beyond a TDM voice environment to model data services (e.g. DSL, ATM, IP). As a result, most CLECs either acquired new or built their own inventory and provisioning systems to support data services. As Product A had been designed to be a monolithic system, it did not have the APIs required to integrate with these new applications. As a result, it was very difficult to provide an integrated solution that could leverage the voice/TDM strengths of Product A and the data capabilities of the new inventory and provisioning systems.

Product A also had a number of other technical limitations. As a monolithic system, Product A was not able to scale with the enterprise. As a number of CLECs grew to provide a national presence, the two-tier architecture built on PowerBuilder and Oracle resulted in unacceptable performance across a wide area network. Service Providers with

multiple provisioning and support centers were forced to use applications such as Cytrix to allow Product A to be used from distributed geographic locations.

While the benefits of having all technology, service, and functional domains supported by a monolithic OSS platform is desirable, as the Vendor A example illustrates, no single vendor has been able to successfully provide the wide range of functional capabilities even within a single technology and services domain. There are a number of other similar examples in the industry.

[SI]’s “Best-of-Breed” PhilosophyFor this reason, [SI] believes that the best way to operationalize converged, Next Generation networks and services is to create a tightly integrated OSS architecture that federates “best-of-breed” operations support systems that specialize in particular functional areas. Our continued success implementing and integrating solutions that incorporate “best-of-breed” products for our clients, validates our belief that an integrated OSS architecture is the best way to operationalize converged optical, TDM, FR, ATM, IP, MPLS, VoIP and other services.

When combined into an integrated OSS architecture, “best-of-breed” products have a number of key benefits:

By focusing on one or two functional areas (e.g. configuration management and provisioning), these systems typically provide a deeper or richer set of functionality addressing many of the operational challenges outlined above.Individual systems usually can simultaneously support multiple technologies and services, although more complex tasks such as activation may requires systems that specialize in one or two technology domains (e.g. FR/ATM, IP/VPN, Optical).Because these systems specialize in one or two functional domains, they typically are designed in such a way that they are easy to integrate and fit into a broader integrated OSS architecture. As a result, they usually have a rich set of programmatic interfaces that facilitate rapid integration, allowing us to federate them into a comprehensive integrated OSS architecture.

By federating “best-of-breed” systems into a broader architecture, the combined systems provide an integrated solution that supports all of the functional and technical requirements needed to operationalize Next Generation networks and services.

[SI]’s Proposed Integrated Services Architecture (ISA) and Approach[SI]’s proposed solution is built upon a “best-of-breed” approach based on our Integrated Services Architecture (ISA). This architecture, illustrated below, and our proposed solution set have evolved through numerous successful client engagements. In addition to the solution, [SI] is proposing a comprehensive approach or methodology for introducing the architecture to minimize risk and maximize the benefits.

Figure 1.3.3-A: Integrated Services Architecture

The proposed solution and approach has the following benefits to BellSouth:

Provides a complete, integrated solution covering all functional and technology domains. This avoids the introduction of a new set of Network and Element Management Systems each time a new technology or service is introduced, eliminating silo’d sets of solutions.

Integrates “best-of-breed” products that have been proven in the marketplace. Each of the recommended applications has a proven track record of successfully operationalizing similar functional capabilities at other Service Providers. They have also proven their ability to scale in production environments. [SI] has been through lengthy selection processes for each application, balancing their overall capabilities with the ability to fit into an integrated solution. [SI] has experience customizing and integrating each of the proposed applications.

Wherever possible, [SI] have minimized the number of applications in the solution by selecting applications with broader capabilities.

The solution uses an Enterprise Application Integration (EAI) engine to simultaneously introduce new systems and leverage existing systems in a single, coordinated architecture. This allows BellSouth to continue to leverage the return-on-investment of legacy systems such as Broadband NMS (BBNMS), eliminating the need to replace these applications.Outlines a clear approach for building and migrating to the Integrated Services Architecture. By leveraging EAI to integrate legacy applications into the integrated solution, BellSouth can gradually introduce new applications to support Next Generation services while maintaining support for traditional voice and TDM services using existing systems. This “cap and isolate” strategy allows you to stop or minimize investments in legacy infrastructure as you introduce new services. In time, traditional voice and TDM services may be migrated to the newly introduced applications, gradually retiring legacy applications. This approach is in stark contrast to a monolithic solution, which requires a “big bang” deployment of the entire Next Generation OSS platform.

Mitigates risk by allowing the substitution of components. In the event that a system cannot evolve to support functional or technical domain requirements, the system could be replaced with an alternative “best-of-breed” solution without impacting other applications in the architecture.

Provides centralized control of processes that span multiple organizations and systems. At the core of the Integrated Services Architecture is Integrated Order Manager (IOM). By building the IOM on top of an EAI architecture, the solution provides end-to-end visibility into the entire service fulfilment processes. It also provides integrated worklist management for consistently handling exceptions and order fallout.

Leverages a variety of pre-built [SI] assets or Market Offerings to provide “Jump Start Kits” that accelerate the deployment and integration of the individual systems. These pre-built and integrated solutions, or “Jump Start Kits,” can reduce the implementation time and cost by as much as 40 to 60%.

Supports a common view of data across all systems. As described in the Services Catalog above, the Integrated Services Architecture has been constructed in such a way that applications share a Common Data Model.

Provides a single point of contact responsible for the entire solution. [SI] is proposing a complete, Integrated Services Architecture that will be customized, integrated, and supported in BellSouth’s SOE. [SI] will stand by each application in addition to the integrated solution and will manage the relationships with the vendor partners.

The remainder of this white paper briefly discusses our [SI]’s Market Offerings.

[SI]’s Market Offering Assets[SI] has a long history of helping Service Providers develop integrated OSS architectures. These solutions leverage a combination of “best-of-breed” and legacy applications to operationalize current and future Next Generation networks and services. The Integrated Services Architecture has evolved from our experience building and integrating similar integrated OSS solutions for multi-service networks on numerous client engagements.

Utilizing successful Integrated Services Architectures and solutions from multiple client engagements, [SI] has invested a significant amount of capital to procure the assets and intellectual property of these solutions. These solutions get packaged into reusable Market Offerings, or customized, pre-integrated solutions that can be used to provide the basis for a “Jump Start Kit.” Our “Jump Start Kits” consist of a number of core assets, such as the methodology, program plans, design documents, database and directory schemas, services models, business and engineering rules, EAI connectors, utilities, and other software assets that can be leveraged for client engagements. The “Jump Start Kits” allow us to implement and integrate these solutions in a fraction of the time and cost that would be required to build from scratch. It is our estimate that the “Jump Start Kit” assets would save 40 to 60% in development efforts of an integrated OSS architecture, allowing BellSouth to rapidly implement the solutions and minimize the costs. In addition, by leveraging solutions that have proved successful on previous engagements and already proven to scale in production, BellSouth will significantly reduce the risk and complexity of the proposed program.

As outlined in this white paper and our Integrated Services Architecture, [SI]’s proposed architecture and solutions are intended to provide a common platform for managing a converged, multi-service network (e.g. IP, ATM, FR, Native Mode LAN, and TDM) based on an IP/MPLS and optical core. The flexible components that have been included in our solution are extremely extensible, allowing us to rapidly model and manage new services and technologies. Our approach also provides a smooth migration path to support BellSouth’s “cap and isolate” strategy, by leveraging an EAI platform to integrate legacy systems and enabling their potential substitution at a later date.

Integrated Services Architecture (ISA)RFP Question #1This section will address Question #1 as stated in Attachment 1 of the BellSouth Next Generation OSS RFP Scope Document:

Architecture: Please describe your anticipated solution at a high-level. Please cover the following points: The architecture, both functional and technical: the components used, their interconnection and relationships to each other. If you have not finalized your selection of components (if you choose to use 3rd party components for instance), please indicate as such. (20 pages or less of text and diagrams)

IntroductionBased on years of experience and numerous successful client engagements, [SI] has developed a comprehensive framework and approach that addresses the challenges of building and operationalizing Next Generation services. At the core of this framework is [SI]’s highly flexible, component based Integrated Services Architecture (ISA). The Integrated Services Architecture has been designed to address the complexity of managing multiple layers of technologies and services using a common infrastructure by introducing an integrated OSS environment that:

Treats your product set holistically and avoids stovepiped (silo) solutions Leverages reusable building blocks and components (including existing legacy systems) Enables the management of processes that span multiple organizations and systems Continually increases automation through a phased implementation and integration approach Bring customers nearer to the network through service control and management functions Allow inter domain management functions at every step of the service lifecycle

The following figure illustrates [SI]’s Integrated Service Architecture.

Figure 2.1-A: Integrated Services Architecture

To manage the complete range of technologies and services on a common platform, the Integrated Services Architecture builds on the following design principles:

Integrate best-of-breed Operations Support Systems (OSS) Establish process-oriented base architecture/framework

Introduce an Enterprise Application Integration (EAI) bus that supports process automation Support many-to-many interfaces Allow the reuse and integration of legacy Operations Support Systems Permit substitution of OSS products Integrates human workflow and worklists to support manual tasks

Provide common view of data Translate all data to common, normalized object/data model Leverage common information (unified directory) wherever possible

Leverage reusable components Support multi-vendor and technologies with same infrastructure Abstract services and capabilities Abstract lower layer services to upper layers

Introduce web portal and try to leverage standardized APIs (J2EE, XML, WebServices, etc.) to support customer self-service

Seamlessly integrate with Business Support Systems (e.g. CRM and billing) and Service Control infrastructure

Integrated Services Architecture (ISA)The diagram below illustrates [SI]’s Integrated Services Architecture. The ISA has been designed to allow clients to easily extend the base implementation and infrastructure to rapidly introduce new products and services, while simultaneously reducing operating costs. It is intended to provide a complete set of solutions for building, selling, and managing Next Generation services, including all of the business and operational support systems. The primary areas of focus as outlined in the RFP are the functional areas presented in the red and orange boxes. However, it is also very important to identify the relationships and interfaces to other areas of the broader architecture to provide a complete solution for the business.

Figure 2.2-A: ISA Functional Decomposition

Infrastructure PlanningInfrastructure Planning consists of the organization, processes and systems required to plan, model, design, optimize, and build networks. It includes the tools needed for engineers to perform Capacity/Network Planning functions, in which the forecasting of future capacity needs is determined based on marketing demand projections and existing traffic analysis. Demand and forecast information is correlated with in-service and planned inventory,

and translated into network build requirements. The tools are also used to perform network optimization and “what if” analysis in the design of the network. Infrastructure Planning also includes Traffic Engineering functions, designed to simultaneously optimize network utilization, route traffic, and respond to performance degradation feedback, insuring that the network meets a set of performance objectives defined in Service Level Agreements. Infrastructure Planning uses the Service Delivery systems to implement the prescribed changes to the network and services infrastructure.

Service DeliveryService Delivery consists of the organizations, processes, and systems required to actually build the network infrastructure and to provision and activate services for a customer. It includes an Integrated Order Manager (IOM) that receives a customer order from a CRM or external system, decomposes and routes the order to one or more provisioning and fulfillment systems, and manages the complete lifecycle of the order including status, jeopardy, and fallout. The Integrated Order Manager leverages a process-oriented Enterprise Application Engine (EAI) with integrated workflow to coordinate the rest of the Service Delivery functions. It also includes a worklist manager for manual tasks.

The Configuration/Provisioning system is used to manage and maintain hardware and software configurations, topology, and logical resources in the network. It also performs the design and assign provisioning functions required to allocate resources to a customer and to configure their service. The Configuration/Provisioning system interacts either directly with the Element Management Systems (EMSs) or with a variety of Service Activation systems to configure the network and service elements. These Service Activation systems translate an abstracted configuration of the service into the vendor and device specific commands required to configure service. They also provide transactional semantics to insure that the service is correctly configured in the network. The interaction between the Configuration/Provisioning systems and the Service Activation systems is typically controlled by the IOM and traverses the Application Integration Plane described later. The Configuration/Provisioning system typically will interact with one or more Inventory Management systems, which are used to manage physical inventory and perform traditional asset management functions (e.g. sparing, bar coding, etc). These systems may also provide GIS capabilities required to support inside and outside plant. In addition, the Configuration/Provisioning system may interact with other Inventory Management and Provisioning systems that are used to manage legacy services (e.g. TDM, voice, etc.).

A Workforce Management system is used to coordinate, schedule, dispatch, and manage technicians that must go to field locations and customer sites to perform manual tasks that require an on-site presence. The Partner Interface Management system, which is typically an extension of the core Application Integration Plane and tightly coupled to the Integrated Order Manager, provides B2B interfaces to external customers and suppliers to provide the complete management of the service fulfillment processes.

The Network/Service Discovery system periodically polls the network elements or element management systems to determine the configuration of the network and services. Once discovered, the system passes the information to other systems (Configuration/Provisioning and Service Assurance) that require topology and configuration information. Discrepancies between the expected results and the actual network and service configuration is either reported or automatically corrected based on a well-defined set of business rules.

Service AssuranceService Assurance consists of the organizations, processes, and systems to ensure that a service is available and the customer is receiving the appropriate level of service. Alarm Surveillance monitors network and service elements to insure that they are available and functioning properly. Correlation & Root Cause Analysis uses its knowledge of the service and network topology to analyze alarms to isolate the root cause of a failure. This helps avoid costly operator time required to troubleshoot a problem. Fault Management & Impact Assessment aggregates alarms originating from multiple domains of management into a centralized repository and creates a series of views that can be used by operators to focus on a particular service, technology domain, customer network, or geographic region. It also will query one or more CRM or Configuration/Provisioning systems to determine which customers or services may be impacted by a particular fault. Once the affected customer and services are identified, the Fault Management & Impact Assessment system may interact with one or more Business Support Systems to open and prioritize a trouble ticket, and notify the customer. It may also include a notification function that sends an email, page, or SMS message to an operator to notify them of the problem.

Performance Management polls network and service elements to collect usage and traffic information to monitor how well the network is performing. Performance Management provides a variety of network and service performance reports that can be analyzed by operators or customers. The reports can also be used as inputs into the Capacity/Network Planning. They also provide a key input to the Service Level Management system described below. In addition, performance threshold violations can be forwarded as alarms to the Alarm Surveillance and Correlation & Root Cause Analysis systems to be analyzed by as part of the fault monitoring processes.

The Service Level Management system manages the complete lifecycle of Service Level Agreements (SLA) that are contracted with the customer. It helps negotiate the Service Level Objectives and QoS parameters that describe the availability and performance characteristics of the agreement, activates monitoring, aggregates performance

data, and compares the data with the objectives to establish SLA compliance. SLA violations are then forwarded to the appropriate Business Support Systems (e.g. Trouble Management, CRM, and potentially Billing) to rectify the problem and compensate the customer.

A Test & Diagnostics system provides a centralized suite of utilities to validate and ensure proper function of network services and resources. These utilities may be used to help operators troubleshoot a network or service outage. The same tools may also be used to pre-qualify a service or test the service during the Service Delivery processes.

A Usage Collection/Mediation system gathers network usage data from the Performance Management system or directly from the network or service elements. This data may be used for decision support functions (e.g. what types of traffic are traversing the network) or as a feed to the Billing system (e.g. usage based billing). In addition, this usage mediation data will also feed into a Security & Fraud system that analyzes the data to determine if an unauthorized user is accessing the network or service or it is being used in a malicious manner. The Security & Fraud system may also include proactive functions such as virus scanning and intrusion detection. Note that both Usage Collection/Mediation and Security & Fraud are outside of the scope of the current RFP.

Service ControlJust as the Intelligent Network (IN) split the service intelligence from the actual network and service elements that executed the service, Service Control provides the intelligence for controlling services and service features for the integrated, multi-service network.

A Service Control architecture should provide a framework for constructing new services or extending existing ones in such a way that you could reuse the same basic building blocks. Signaling consists of applications and servers that communicate directly with network and service elements to control the execution of a service (e.g. call agent, media controller, etc.). Service Applications provide some additional features or capabilities above and beyond basic element control (e.g. messaging, session management, collaboration, content/storage, routing, VPN, etc.). A shared set of Common Services provides the Service Applications, Signaling, and network and service elements with additional information and capabilities that can be used to create new services or enhance existing applications. Examples of these Common Services include presence, registry, policy, address management, and Personal Information Management (PIM). Common Services interact may interact with other Service Control components or directly with the network and service elements.

As the control and management of services move closer to the customer through web-enabled Customer Network Management portals, the Service Configurator provides an integrated view of subscriber and service data that that wraps the various Service Control applications to expose consolidated graphical and programmatic interfaces. These interfaces can be incorporated into the Integrated Customer Portal described below. They also provide a common set of application programming interfaces that simplify interaction with the Operation Support Systems, acting as a key enabler for Service Delivery and Service Assurance.

The Service Configurator incorporates service logic and may leverage a meta-directory utility to consolidate subscriber and service information into a Common Data Model which Service Control accesses through a Unified Directory.

Shared InformationTo coordinate “best-of-breed” and legacy applications, the entire Integrated Services Architecture is built around a Shared Information model. The Shared Information model, which is based on the Services Catalog, provides a common way of describing customers and services. This provides a consistent view of User Profiles & Security and Service Profiles across all of the applications. By describing customer, service, and network information in terms of a Common Data Model, applications can easily expose and share information with one another – a key enabler for integration.

It is important to understand that the Shared Information model is a “virtual” construct. While each application may represent its version of subscribers and services in its own format which is optimized for a particular task, the Shared Information model primarily manifests itself in the Application Integration Plane described below. Rather than translating data from one application’s internal format directly to another, the EAI application with translate into the cananonical format as described by the Common Data Model so that other applications can understand the data. In this way, the Shared Information model exists primarily in events and messages that traverse the Application Integration Plane or EAI bus.

However, there are a number of entities where the Shared Information model resides in a physical construct. For example, an Operational Data store may be used for sharing information between applications. One example of this is a reporting database that is leveraged by the Integrated Order Manager described later in this document. Another example would be a temporary database that stores discovered network data to be reconciled against the Configuration/Inventory Manager. These Operational Data stores will use the Common Data Model. The shared Transaction/Logging service and data store that tracks information that traverses the Integrated Services

Architecture will also use a direct representation of the Common Data Model. Finally, the Unified Directory that is used by the Service Control infrastructure will also have a direct representation of the Common Data Model.

Although each application may translate the Common Data Model into its own internalized view which is optimized for its specific functions, it is interesting to see the major functions where a large portion of this Shared Information model is found. The Integrated Order Manager uses the Common Data Model (in its normalized view) to decompose and route service orders to the appropriate provisioning systems, external gateways, and other fulfillment systems. It also uses the Common Data Model to exchange information between systems describing subscribers and services.

The Configuration/Inventory Manager has a complete model of the services and network topology, providing the primary System of Record (SOR) for the service and network configuration. Although this model is internalized to its own format, external interfaces and data exchange all use the Common Data Model.

The Network/Service Discovery engine will translate discovered information into the Common Data Model. The Correlation & Root Cause Analysis system will import and internalize the service and network topology information in such a way that it can be used for correlation and isolation. The Service Level Manager will also describe SLAs in such a way that they are understood by other BSS and OSS applications.

All other applications translate data to and from the Common Data Model in communicating with other applications through the Application Integration Plane.

Other ComponentsAt the core of the Integrated Services Architecture is the Application Integration Plane. The Application Integration Plane provides the glue that links each of the applications into a cohesive system in which processes span multiple organizations and systems. The Application Integration Plane will vary based on the function and data transformation requirements of the systems that it integrates. For the Infrastructure Planning components, the Application Integration Plane will consist primarily of batch XML interfaces. The Integrated Order Manager coordinates most of the integration for Service Delivery, leveraging its integrated process automation, workflow, and manual task lists to provide end-to-end management of the Service Delivery processes. As a result, the EAI platform is used for most Service Delivery interfaces. However, a variety of other interfaces including LDAP, JMS, XML/HTTP, SOAP, SQL, and CORBA may also be used for specific integrations. These may be either direct interfaces or accessed through connectors to the EAI bus. The Service Assurance applications often extend these protocols to include SNMP as a vehicle for inter-application communications.

The Infrastructure Plane represents the actual network and service elements, including Equipment and Application Servers. The lower level Network Management Systems (NMS) and Element Management Systems (EMS) that abstract a particular device or service to the higher layer systems have been included. The Service Management Plane provides the integration between Service Delivery, Service Assurance, and the Infrastructure Plane, using network management protocols to configure and manage services. Management protocols in this plane include CORBA, Java, SNMP, CLI, Telnet, CMISE, XML, FTP, LDAP, COPS, etc. In addition, a Signaling Control Plane is used by Service Control applications to coordinate network and service elements in the setup and teardown of a service. The Signaling Control Plane will use industry standard protocols such as SIP, MGCP, SS7, LDAP, COPS, RADIUS, and DIAMETER to communicate with the Infrastructure Plane.

As part of our goal is to leverage the architecture to enable Customer Network Management or Self-Service, an Integrated Customer Portal is provided to expose Service Delivery, Assurance, and Control functions directly to the customer. The portal provides web enabled views to Service Configuration, Order Handling, and Resource Inventory functions for Service Delivery, using the Application Integration Plane to expose partitioned capabilities directly to the user. The portal also exposed Service Level Management, Performance Management, and Fault Management reports to the customer. In addition, it provides a common look and feel for managing the Service Configuration and Service Administration functions for Service Control, allowing the user to dynamically configure and manage their services (e.g. change follow-me number, different mapping of applications to Gold, change in link speed, etc.). The portal pulls in Client Application graphical interfaces directly into the portal, providing a single place the customer can go to configure and run services. The Integrated Customer Portal also provides a comprehensive layer of security and profile management, including delegated administration and single sign-on functions. The same portal is also used to wrap Business Support Systems to provide the customer with web interfaces to Trouble Management, on-line Billing, and other applications.

Although not in scope for this RFP, the Integrated Services Architecture provides a consist way of interfacing with Business Support Systems including CRM/Sales, Sales/Order Handling, Billing/Accounting, Customer Care, and Trouble Management systems. This integration is facilitated through the Application Integration Plane, provided a completed end-to-end architecture.