00657_Integration Challenges

Header 1 Integration Challenges for Triple Play Service Delivery An Artix Solutions Briefing IONA Technologies December 2005 Integration Challenges for Triple Play i Table of Contents Today’s Integration Challenge: Triple Play Service Delivery Business Trends BSS/OSS Modernization BSS/OSS Consolidation IONA in Telecommunications Why is Telecommunications Integration Different? Integration and Service Delivery Artix and Service Delivery Platforms Artix Triple Play Case Studies Enabling VoIP and Subscriber Self-Service Triple Play Problem The IONA Solution Enabling IPTV by Extending SDP Triple Play Problem The IONA Solution Summary 1 2 2 2 2 5 6 8 10 10 10 11 12 12 13 14 Integration Challenges for Triple Play 1 Today’s Integration Challenge: Triple Play Service Delivery Triple Play, the bundling of consumer broadband Internet access, video and fixed voice services from the same service provider, has become a market imperative for incumbent telecommunications companies, competitive carriers and cable operators worldwide. The business drivers behind this market shift primarily fall into the following three areas: 1. New Service Revenues—Competition is having a dramatic impact on the ability to derive revenue from traditional voice services, forcing carriers into new areas for both revenue protection and growth. Increased competition means that service providers cannot simply maintain their share of consumer communications and entertainment spending, they must improve it. The ability to generate new revenues is tied directly to the next generation of communication services which may include basic Internet access, PSTN telephone and IPTV, as well as a host of other services including pay-per-view, gaming, music, home-networking, messaging and mobility. Battle for the customer—Communications companies are facing competition on several fronts. Alternative carriers are joining traditional competitors on the playing field, and incumbent vendors must try to reduce customer churn by extending their sphere of influence to include additional services. Better margins—Next generation architectures based on IP technology will ultimately reduce the capital expense of providing services, and lead to reduced operating expenses. 2. 3. Figure 1: Business drivers for Triple Play strategy Integration Challenges for Triple Play 2 Increased revenues, competition, and customer retention—the reasons for service providers to embrace a triple play strategy are well understood. The question is not whether triple play is a good idea. The question is how to implement these strategies to meet competitive pressures without incurring unreasonable cost. Overcoming the technical hurdles, especially the integration hurdle, can be a daunting task. Service providers have made massive investments in billing, provisioning, network management, and hundreds of other mission critical systems. All of these must be leveraged to migrate existing voice customers to triple service consumers. But how does a service provider reliably bring together video, voice and data services while leveraging existing mission critical BSS and OSS systems? This paper will review some real life examples in which IONA has played a key role in solving the integration puzzle. Business Trends After several years of carefully managing costs, service providers are shifting their focus from cost reduction to revenue generation. They need to introduce services that will make them money, and need applications to support these initiatives that are easy to integrate with existing networks, and back-office OSS/BSS systems. To support the triple play initiative, most service providers are looking at the following two significant trends: BSS/OSS Modernization CEOs and CIOs of large telecommunication carriers are starting to talk about back-office modernization. The stopgap fixes made to the network during the telecom winter solved the problems of the moment, but left a plethora of unconnected systems in their wake. There has also been a lack of Operational Support System (OSS) upgrades for the past few years, and the rising costs of maintaining older versions of these OSSs will cause service providers to seriously think about the benefits of new OSS purchases as opposed to system upgrades. The onset of convergence and the ability to take advantage of the low cost of operating IP networks is also driving the modernization movement. BSS/OSS Consolidation There is little question that service providers’ profitability will come from internal rationalization and higher Average Revenue Per User (ARPU) rather than subscriber growth. The telecom industry will shift toward operational efficiencies as well as the need to understand their customer imperatives more intimately. The Gartner Group predicts that through 2010, service providers who do not aggressively streamline their networks, back office systems, and processes will gradually lose market share and customer loyalty. The need to simplify their network architecture and OSS will become a critical success factor. IONA in Telecommunications IONA has been providing the telecom industry with integration solutions since the early 1990s. For more than 75% of the world's telecommunications service and equipment providers, IONA's technology provides the infrastructure for these mission critical network management systems. Our technology was chosen for its reliability, performance, and adherence to industry-mandated standards. And as new centralized national telephone and wireless networks come online, IONA continues to be the obvious choice to provide the network management infrastructure. Integration Challenges for Triple Play 3 More than 170 telecommunications companies around the world rely on IONA's high performance integration products to connect and support network management, configuration, security, operations, performance, and fault management, and administration systems. Figure 2: IONA integrates applications at different levels of the provider’s architecture While the issues of Operational Support System/Business Support System (OSS/BSS) modernization and consolidation are important, the technical problems in achieving them are numerous. They present themselves at various levels of the network architecture and involve different parts of the company. Figure 2 shows a typical example of the various roles IONA products play in integrating Telecommunications applications. These roles include integration at the following levels: • BSS to BSS—At the business systems level, new business applications such as customer self-service need to interoperate with established systems such as order staging and credit card validation. This paper will examine a case study where IONA’s Artix was instrumental in enabling a VoIP application for one major carrier. Business applications are increasingly using service-oriented architecture and Web services as a strategy to better insulate these applications from change. IONA’s technology is distinguished by its ability to service-enable legacy applications in a wide range of environments from mainframe to mobile devices. Integration Challenges for Triple Play 4 • OSS to BSS—BSS to OSS integration provides the glue that ties the network side to the IT side, and allows business intentions to become network realities. While traditional EAI and BPM integration products are often used at the BSS layer, rarely, if ever, are these products used at the OSS layer. The reasons for this are simple: Many of these systems are specific to a single manufacturer and are used for specific applications at the BSS level. However, at the OSS level, almost every carrier’s network is different in topology and technology, and requires customized OSS applications to operate and manage the networks. This makes it unsuitable for these systems to be used at the OSS level. Another reason is that the volumes of transactions involved at the OSS level are in hundreds compared to volumes of transactions at the BSS level in tens, making a traditional approach to BPM using a process engine completely unworkable. BSS to BSS integration is most often concerned with macro-flows that support long running business processes; whereas OSS and network applications tend to support the kind of micro-flows that enable them to quickly respond to an event. BSS to OSS integration often has elements of both and requires a great deal of flexibility from the integration software. OSS to OSS—Connecting an order management system to an existing service provisioning application is an example of this type of integration. This integration pattern emphasizes the need for high performance, stateless process flows and distributed design while at the same time providing enterprise qualities of service. Successful integration in this environment means pushing much of the intelligence of traditional EAI BPM tools much closer to the network, making it considerably more performant. As standards for network management evolve, IONA continues to be on the forefront of technology in this area. IONA is actively helping standards organizations such as the Telemanagement Forum specify innovative ways to open networks to a broader range of services. For example, IONA is committed to Multi-Technology Operations Systems Interface (MTOSI). MTOSI is a unified, open interface standard for use in allowing multi technology operations systems to interact. OSS to OSS integration directly addresses the business driver for increased profitability and ROI by enabling carriers to quickly weave together new revenue generating services and by reducing operating expenses in deployment and management of these services. • • OSS to NMS and EMS—IONA plays a vital role in providing the link between the OSS and the Network. CORBA has been used extensively in Network Management Systems (NMS) and Element Management Systems (EMS), and therefore CORBA and IONA’s Orbix product continue to be a relevant technology in OSS to network communications. In Figure 2, the provisioning application interoperates with element management systems using CORBA. IONA works closely with standards organizations such as the Parlay Group to establish standards in this area. Parlay's open application programming interfaces (APIs) release developers from having to write code for specific networks and environments, reducing risks and costs, and allowing for innovative new services to be delivered. Integration Challenges for Triple Play 5 Why is Telecommunications Integration Different? In many cases, traditional approaches to integration that were designed to help corporate IT departments assemble their Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) applications are not well suited to a carrier’s telecommunications environment. The three primary reasons for this include: • Performance and scalability—While many corporate applications serve a large base, most do not exhibit the same kind of performance characteristics or scale that a large carrier requires for their operational and business systems. For example, one IONA customer processes five billion transactions a year using IONA technology. Maintaining extremely high throughput requires a special approach to architecture. The peak loads of some these systems will not tolerate the overhead introduced by layers of integration software. Technical diversity—Telecommunications applications have evolved over the course of several decades. These applications have diverse characteristics on a level not found in typical corporate IT environments. Operational constraints—A telecommunications carrier cannot take down their OSS applications to change how they interface to other systems. Any effort to integrate these applications must be noninvasive while not compromising the guarantees associated with the service. • • For these reasons a different architectural approach to integration of OSS/BSS is necessary. Such an approach must have the following characteristics: • • • • • Customizable—Use a plug-in approach that allows users to extend support for new types of integration. Non-invasive—Service-enable back office systems without requiring them to change and without denigrating qualities of service. Technology independent—Provide broad support for multiple application architectures, multiple transports and multiple protocols. Distributed—Leverage configurable and extensible endpoints that can be deployed at the edge of the network close to the applications they support. Carrier grade—Offer high reliability, scalability, and security while incurring little operational overhead. Integration Challenges for Triple Play 6 Integration and Service Delivery To implement triple play with integrated services, a layer is often introduced called the Service Delivery Platform (SDP) to provide for rapid creation, development, testing and provisioning of valueadded services across a variety of network components and back office OSS/BSS systems. SDPs are an enabler for quickly and efficiently bringing together video, voice and data platforms that comprise the triple play strategy. OSS/BSS functions need to integrate using the generic service delivery interface of the SDP. The SDP orchestrates the capabilities of each service platform into integrated services. As shown in Figure 3, multiple vendors offer SDPs and their primary role is to provide both a service creation and service control environment where integrated services can be defined, deployed, and controlled efficiently. This includes the following: • • • Service Management—Creates service catalogs, service definition, packages management, and support for offer management, enabling providers to create discounts and special bundles. Subscriber Management—Stores subscriber profiles and relationships of subscribers to multiple vertical services, resources, serving areas, and other subscriber groups. Service Activation and Suspension—Allows service providers to activate or deactivate subscriber services for multiple vertical services for individual subscribers and groups of subscribers. Many mainstream infrastructure providers such as BEA, IBM and Microsoft offer SDP platform products. Figure 3: Service Delivery Platforms provide Service Creation and Control Integration Challenges for Triple Play 7 Another important function of an SDP is to avoid the situation illustrated in Figure 4. By introducing a platform that mediates between the service platform and existing OSS/BSS systems, an SDP reduces the number of direct interfaces that must be built, not only between the various service platforms, but also between the service platforms and the many OSS/BSS systems. The SDP provides the orchestration that allows each service platform to present the end user with a seamless service delivery. Figure 4: Service Delivery Without a Service Delivery Platform IONA has developed a product, called Artix, based on Service Oriented Architecture (SOA) principles and Web Services standards. Artix is an extensible Enterprise Service Bus (ESB) that was designed in collaboration with some of the world’s largest telecom providers. Artix provides the integration framework for tying in various OSS/BSS systems to SDPs using dynamic and configurable plug-ins, and provides mediation between various messaging systems, protocols, transports and middleware platforms. Artix uniquely offers: • • • • Extensibility due to its plug-in architecture. Comprehensiveness as a result of its broad, mobile-to-mainframe platform support. Reliability and performance due to its support for security, high availability, management and transactions, among other enterprise qualities of service (QoS). Ease of use because of its integration with popular developer tools such as the Eclipse framework. Integration Challenges for Triple Play 8 Artix and Service Delivery Platforms As shown in Figure 5, IONA’s Artix plays a key role in mediating among SDP application and existing systems. While Service Delivery Platforms provide external interfaces, there is often an impedance mismatch between modern SDPs and legacy operational and business support systems that may have evolved over decades. Figure 5: Artix enables SDPs to view OSS and BSS applications as extensible endpoints As shown in Figure 6, a typical Artix deployment involves multiple OSS and BSS applications. Few if any of these systems were originally designed for integration. These systems retain enormous value, but with their incompatible architectures, technologies, and transports, and their security, transaction and data models, they pose enormous integration challenges. Integration Challenges for Triple Play 9 Figure 6: Artix enables applications to plug into the network Figure 7 shows how integration based on Artix aids triple play initiatives by supporting the key business drivers: • • Quest for new revenue—Extensibility and ease of use means integration problems are solved more quickly. This translates to getting innovative services to market in less time with fewer compromises. Battle for the customer—Better integration means a more seamless user experience. By tying new systems to Billing and CRM applications that hold important customer information, service providers can see a single view of the customer. This unified view helps carriers manage a smooth migration of their existing customer base to the new services. Increased margins—Distributed small footprint approach means integration logic can be hosted on the same machine as the application. This means reduction in capital expense by allowing the user to take an incremental approach to integration. • Integration Challenges for Triple Play 10 Figure 7: Artix supports business drivers Artix Triple Play Case Studies This section outlines the following Artix case studies: • • Enabling VoIP and subscriber self-service. Enabling IPTV by extending SDP. Enabling VoIP and Subscriber Self-Service This case study outlines the triple play problem, and then explains the Artix-based solution. Triple Play Problem This large US-based service provider needed to create a new customer self-service application to support their VoIP service. This Web-based VoIP support application, called an eVoIP, allowed subscribers to order and configure VoIP service using the Internet. Because VoIP users by definition have broadband Internet access, eVoIP is an ideal way to automate this business process while garnering higher user satisfaction and lowering cost. The business challenges facing this organization included: • • Time to market—The intense competition in this market meant that the service had to be deployed quickly. Market leadership positions were being established in terms of months, not years. Diversity—Each step in the progression had to tie into the service provider’s OSS and BSS systems. These systems were each developed at different times with very different technologies. Integration Challenges for Triple Play 11 • Scalability—The design goal for this system was support of twenty million users, with the capability to support 1 million concurrent users. The IONA Solution As an extensible ESB, IONA’s Artix provides interfaces for customizing and extending support for security, transport, management, transactions and other aspects of application integration. Artix was able to serviceenable valuable BSS and OSS systems without changing them or denigrating mission critical qualities of service. As shown in Figure 8, Artix was used to integrate disparate application architectures ranging from Web GUI applications written in Java to CORBA applications running as a part of the network infrastructure. Figure 8: The Artix ESB helps integrate OSS and BSS to support VoIP Integration Challenges for Triple Play 12 The following Artix features were critical factors in the success of this project: • Extensible endpoints—Artix can be embedded into an application endpoint, enabling the integration logic to execute on the same hardware as the application. The endpoint is managed and secured using the native mechanisms of the application, without changing native applications or adding additional processing power. Deployment Flexibility—Different endpoints required different models; some required a Web service client to call out to the next system, some required a Web service server to accept Web requests over the network. In one instance, Artix was even deployed as a stand-alone switch, receiving Web service calls and invoking CORBA calls on a packaged application. Language Independence—The Artix interfaces could be deployed using C++ or Java. Artix supports this flexibility, enabling the integration components to adapt to the particular system—without having to change the system or retrain developers in a new language. Multiple Protocols and Bindings—Artix supports multiple transport protocols and message format bindings. Figure 8 shows the multiple protocols required for this project. Artix was used to support Java remote method invocations, Web services interfaces, and bindings for CORBA and custom built messaging protocols. • • • Enabling IPTV by Extending SDP This case study outlines the triple play problem, and then explains the Artix-based solution. Triple Play Problem This large established service provider was moving aggressively to enable millions of its residential phone customers to have services that included: • • • Access to integrated digital TV. High-speed broadband access. Voice over IP (VoIP) services. This company’s platform for Internet Protocol Television (IPTV) was based on Microsoft’s .NET architecture, but their BSS and OSS applications had evolved over several years and used many different technologies. The integration between the two environments was not straightforward. The project needed to integrate their modern SDP platform with their OSS and BSS systems. These applications were developed using a variety of old and new technologies. Integration among these systems demanded carrier grade reliability while optimizing network and system resources. The billing information generated by these platforms has data that does not exist in the wireline world. Billable attributes such as quality of service, bandwidth, and latency that never existed in the wireline world can be captured by Internet Protocol Detail Records (IPDR) used to record information about usage activity within the telecom infrastructure (such as a call completion). Propagating billing events to billing systems presents a challenge for service providers. Integration Challenges for Triple Play 13 The IONA Solution This service provider found Artix useful at several levels in the project. While SDPs play a role linking business processes, they are not well suited to solving some types of integration problem. As shown in Figure 9, Artix played two key roles in this project: • • As a lightweight, highly performant integration layer linking the SDP applications with the user’s BSS and OSS applications. As a high-speed interface between the video platform application directly to OSS/BSS to address low latency integration needs. Figure 9: Artix supports SDP integration Artix’s architecture allows it to fit well in low latency environments. Billing events from the video platform needed to be recorded in near real time by the billing system. Moving the data through the SDP added no value to the process and introduced unacceptable overhead. By using Artix to directly mediate between the Microsoft’s .NET environment and the Amdocs billing system, the user was able to solve these latency problems. Artix enabled the rapid transformation and movement of customer billing events in the form of IP Detail Records (IPDR) from the Microsoft platform to the billing system. Artix also provided the flexibility and performance options required to allow interaction between the SDP applications based on modern J2EE infrastructure with order management applications that used a variety of middleware technologies. Integration Challenges for Triple Play 14 Summary The telecommunications industry is moving to deliver services that will change how we live and work. IONA, with its history of delivering high performance, mission-critical applications, is helping market leaders to repurpose their current investments and incrementally pursue their triple play strategies. IONA customers—including AT&T, Bejing Mobile, BellSouth, British Telecom, Deutsche Telekom, Hong Kong Telecom, and NTT—use IONA technology to integrate existing systems and establish a scalable, adaptable SOA architecture. Many of these customers chose Artix for its broad platform support, extensibility and enterprise quality of service, and today are building new business applications and process flows on common platforms such as Microsoft’s .NET Framework, IBM’s WebSphere, or BEA WebLogic. Looking to the future, IONA's customers can count on IONA as a business partner that will provide them with the best the industry has to offer, today, and tomorrow. Integration Challenges for Triple Play 15 IONA Technologies PLC The IONA Building Shelbourne Road Dublin 4 Ireland Phone +353 1 637 2000 Fax +353 1 637 2888 Support: support@iona.com WWW: http://www.iona.com/ IONA Technologies Inc. 200 West Street Waltham MA 02451 USA Phone +1 781 902 8000 Fax +1 781 902 8001 Training: training@iona.com IONA Technologies Japan Ltd Akasaka Sanchome Building 7/F 3-21-16 Akasaka Minato-ku Tokyo Japan Phone +813 3560 5611 Fax +813 3560 5612 Sales: sales@iona.com IONA, IONA Technologies, the IONA logo, Orbix, Orbacus, Artix, Orchestrator, Mobile Orchestrator, Enterprise Integrator, and Adaptive Runtime Technology are trademarks or registered trademarks of IONA Technologies PLC and/or its subsidiaries. Java and J2EE are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. CORBA is a trademark or registered trademark of the Object Management Group, Inc. in the United States and other countries. All other trademarks that appear herein are the property of their respective owners. While the information in this publication is believed to be accurate, IONA Technologies PLC makes no warranty of any kind to this material including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. IONA Technologies PLC shall not be liable for errors contained herein, or for incidental or consequential damages in connection with the furnishing, performance or use of this material. COPYRIGHT NOTICE No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, photocopying, recording or otherwise, without prior written consent of IONA Technologies PLC. No third-party intellectual property right liability is assumed with respect to the use of the information contained herein. IONA Technologies PLC assumes no responsibility for errors or omissions contained in this white paper. This publication and features described herein are subject to change without notice. Copyright © 1999-2005 IONA Technologies PLC. All rights reserved. All products or services mentioned in this white paper are covered by the trademarks, service marks, or product names as designated by the companies that market those products