Whitepaper. Considerations When Migrating Legacy IVR Applications. Integrated Voice Solutions. Automated vs. Manual Re-Development.

Transcription

1 Whitepaper Considerations When Migrating Legacy IVR Applications Automated vs. Manual Re-Development This document covers the thought process pertaining to the migration of legacy IVR applications to new open standards-based systems. Commentary and recommendations are based on experience with both manual and automated migrations. July 2012 Integrated Voice Solutions

2 Whitepaper Table of Contents In order to maintain competitiveness and deliver greater value to customers, businesses need to implement technology that continues to push them one step ahead of the pack. Introduction 3 IVR Business Issues Facing Enterprises 4 Vendor Consolidation 4 New Technology 5 High Support Fees 6 Are You Migration-Ready? 6 Hosted Solutions vs. On-Premise and Hybrid 6 TDM vs. VoIP 7 Vendor Choice 8 Data 8 Reporting & Analytics 9 The Case for Application Conversion 9 Specification 9 Risk of Disruption 10 Timescales 11 About Arca+ 11 Arca+ Features: 12 Using Arca+ to De-Risk Change 12 About Integrated Voice Solutions 13 IVS offers a free, no obligation migration cost analysis. Please contact us today to get started! 13 page 2

3 Considerations When Migrating Legacy IVR Applications Introduction Today, enterprises of all sizes are faced with IVR platform endof-life issues. Over time, the applications that run on these platforms have been highly refined to reflect specific client and customer needs. Because these legacy applications were developed in a proprietary environment, platform endof-life also signals end-of-service for these applications. In order to maintain competitiveness and deliver greater value to customers, businesses need to implement technology that continues to push them one step ahead of the pack. Social media, location-based services, and hosting options are forcing businesses to take an innovative approach to telephony self-service. Spending money and cycles to redesign and re-develop legacy IVR applications precludes businesses from taking advantage of newer automation methods that will cut cost and increase delivery. IVR platform consolidation due to acquisition is increasing. Even platforms that remain supported have become secondary to the newest Next Big Thing that the IVR technology vendor provides. While some of these systems are officially still supported, typically no more than a skeleton crew exists to assist customers. A new technology platform can open avenues for the delivery of more innovative services, yet the cost of deploying a new system and re-developing applications is exorbitant. So far, enterprises have had to choose between remaining on unsupported or poorly supported legacy technology and pay high annual support fees, or to pony up, purchase a new platform, and incur high redevelopment costs. VXML is mature and the most frequently adopted development standard in the telephony industry today. But what is the best way to quickly move proprietary legacy applications to VXML? And more importantly, how can enterprises ensure they won t be locked in again? So far, enterprises have had to choose between remaining on unsupported or poorly supported legacy technology and paying high annual support fees, or to pony up, purchase a new platform, and incur high redevelopment costs. page 3

4 Whitepaper IVR Business Issues Facing Enterprises Understanding key business issues helps enterprises save money, reduce risk, decrease timeline, and maximize resources during migration projects. Vendor Consolidation Enterprises enjoy free reign when selecting technology from a large, open marketplace, and therefore have the benefit of choosing the platform that best suits their needs based on their unique criteria. In today s challenging economic climate, there has been much consolidation in the IVR market. As a result, some industry leaders actively support as many as four different IVR platforms. It is logical to predict that their next step will be to reduce their supported product set and consolidate their clients onto a single platform selected from their bulging portfolios. It s a hard reality that some enterprises find themselves operating their businesses on a platform that has less than a year before endof-support, or that their system is next on the obsolescence list. Enterprises need to discuss their IVR solution with vendors in order to properly expose how much life an existing platform realistically has left. Some questions to consider include: Is an incentive being offered to move to another of that vendor s platforms? Has the quality of support declined, or been sent offshore? Are there longer periods than usual between version releases? As a new release comes out, what is the content? Does the release include new exciting features and support for new technologies, or does it include platform changes designed to drive adoption of their new technology? It s also inevitable that the best system may not be the one that wins through a vendor s selection process. Enterprises enjoy free reign when selecting technology from a large, open marketplace, and therefore have the benefit of choosing the platform that best suits their needs based on their unique criteria. A vendor that has consumed its competition may have other loyalties when deciding which platform is to be continued and which is to become obsolete. Oftentimes, the final choice is not which is the most robust, which has the best development tools, or which is the most extensible; other factors are in play. page 4

5 Considerations When Migrating Legacy IVR Applications New Technology Organizations are typically faced with enduring a forklift upgrade when it comes to moving to a newer version of the same technology. Traditional IVR platforms include a hardware solution (racks, servers, and telephony cards) and a software solution (port licenses and support), which are bound together and used primarily in TDM telephony environments. Legacy telephony platforms tend to be very robust but the technology is proprietary and highly inflexible; scaling is limited to the confines of the hardware s capacity and application development requires specific knowledge. Legacy IVR development staff comes at a higher price point than open standards development staff. Cloud computing has become a reality and IT platforms have become more open. Whether through offering open standards, operating on open source, or allowing integration through industry-standard interfaces, the high-tech world is becoming more connected. VXML based IVR applications live in an open environment, so businesses who use them are free from VXML IVR solutions resemble distributed web applications and as such, leverage existing web infrastructure. Web servers are used as application servers, allowing voice and web applications to run on the same server. With the bulk of the required infrastructure now industry-standard, administration and operations can be supported with fewer specialized skills. VXML was once a mysterious, new open standard that threatened to tear the IVR world apart. Vendors and clients alike courted this new innovation with a conflicting mix of fear, excitement, trepidation, and above all, hope. However, in only a few short years, the issues with VXML have been resolved, the expertise has evolved to enable effective deployment of the technology, and the differences in various vendors interpretations of the standard have evened out. In one form or another, VXML is now the most accepted standard for deploying an IVR application. Most importantly, deployment of a VXML system does not require proprietary platform expertise. Because IVR applications now live in an open environment, businesses are free from the bonds that legacy IVR platform vendors had built into their systems. As the bonds that legacy IVR platform vendors had built into their systems. page 5

6 Whitepaper newer technologies and services arise, enterprises are now able to incorporate them at will. Adoption drives technology forward. Oftentimes, the investment in moving from a legacy platform to an openstandard IVR can be recouped in less than two years. An IVR solution implemented using VXML enables automated telephone services to embrace new technology and market trends at the pace of corporate needs and not that of an IVR vendor. High Support Fees Older IVR platforms typically connect to IT systems that have become non-existent or have seen very limited market share in the last few years. Enterprises have continued to pay vendors for support of these unused interfaces, which is a primary reason for the significant cost differences between proprietary IVR systems and newer open standards. Because they utilize existing web architectures, open-standard IVR systems do not carry the connectivity to older IT infrastructures and therefore, the cost of support and maintenance is significantly lower. Oftentimes, the investment in moving from a legacy platform can be recouped in less than two years. Are You Migration-Ready? Many considerations contribute to the decision to migrate IVR technology. Hosted Solutions vs. On-Premise and Hybrid Moving IVR technology to a hosted solution involves several types of fees. These include one-time step-up charges, per-minute fees, transfer fees, and monthly fees. Some hosting providers charge a different per-minute rate for DTMF versus voice recognition applications. Additional fees may be charged for each additional language supported in the application. When enterprise applications generate spikey traffic, such as during product recalls, outbound notifications, ticket sales, or alerts, hosting is an ideal option. The provider s additional port capacity can soak up peaks in activity and cost is only incurred as surges occur, eliminating the need to provision for the busy hour. page 6

7 Considerations When Migrating Legacy IVR Applications A cornerstone of the decision-making process for hosted versus onpremise is the move from a Capital Expenditure Model (CapEx) to an Operational Expenditure (OpEx) model. In moving IVR to a hosted model, the need to invest in expensive hardware and software licenses is eliminated. Those costs can then be amortized on the vendor s books, not the enterprise s. Some enterprises find it makes more sense for expenses to fall under OpEx, as hosting is an accepted financial model. Specifically for speech applications, many enterprises do not have the necessary internal expertise for tuning and support, making the hosted model the more attractive option. Hosting also allows companies to manage large incremental growth (for example, due to acquisitions and mergers). The OpEx model allows companies to contain costs while maintaining focus on their core business rather than on keeping IVR systems operational. It is also important to consider how data interactions may change by moving to a hosted model. Data interaction timing needs to be considered as well. Hosted models typically include a Service Level Agreement, provided by the vendor. As such, application modifications made by an organization may require approval from the vendor prior to rollout. A cornerstone of the decisionmaking process for hosted versus onpremise is the move from a Capital Expenditure Model (CapEx) to an Operational Expenditure (OpEx) model. Some suppliers also offer a hybrid model. This enables deployment of an on-premise system under a hosted payment model. The vendor s cloud-based services can also be utilized for handling peaks in traffic. By combining hosted and onpremise solutions, the hybrid model allows businesses to take advantage of the positive aspects of both deployment models. TDM vs. VoIP Many customers have made the move to VoIP in order to reduce carrier costs and provide better data access over telephony channels. These changes involve the PBX, if onpremise, and can require the use of a gateway if the path of VoIP all the way from the PBX to the IVR system does not exist. page 7

8 Whitepaper Adding VoIP infrastructure may involve VoIP licenses for the IVR and telephony switch, as well as other considerations: Will VoIP cut cost? Will the current phones work on VoIP? Will there be any Quality of Service issues in the current environment? Will any new networking or telephony equipment need to be purchased? Will the existing carrier support VoIP? Vendor Choice The choice to move to another platform supplied by the current vendor involves many elements. Are open standards offered by the current provider? Is IVR technology a core business for the current vendor? Does the current vendor s new platform implement a proprietary runtime (another lock-in)? Legacy IVR systems continue to connect with outdated systems. This is usually due to inertia, rather than a lack of better alternatives. How involved is the vendor in the W3C, VXML, and CCXML forums? Does the vendor s new platform fully comply with these standards? What is the corporate direction and financial stability of the vendor? Does the proposition make financial sense? Can payment for the migration project be recouped through savings in maintenance fees? What type of reporting does each provider have? Can reporting and analytics leap forward by moving to the new platform? What type of training is needed for each platform and what is the cost? What is offered as part of a package migration? What models are available from the vendor: on-premise, hosted, or a combination of both? Data As discussed, existing IVR systems continue to connect with outdated systems. This is usually due to inertia, rather than a lack of better alternatives. When many IVR systems were initially deployed, the only way to retrieve data from a mainframe was a page 8

9 Considerations When Migrating Legacy IVR Applications screen scraping solution. Today, SOAP/Web Services is a widely deployed alternative used by many corporate systems. Therefore, an evaluation of all interconnectivity within the existing IVR is required. The goal should be to implement modern-day alternatives for older interfaces that are not inherently supported within web architecture. Host Mainframe Access through screen scraping is a primary example. However, businesses should also consider replacing DLL and COM interfaces. Operating system command line processes need to be checked during a migration as well. These may need to be modified or replaced in order to operate with a new operating system or within web architecture. Many third-party systems provide means for interacting within web architecture. Reporting & Analytics When it comes to reporting and analytics functions, many variables need to be addressed. The goal should be to implement modern-day alternatives for older interfaces that are not inherently supported within web architecture. Is the reporting in real-time, and on what channels (phone, mobile, SMS, or web)? Can reports be accessed by a business intelligence software package such as MicroStrategy, Cognos, or BusinessObjects? How many out of the box reports are available? Can data be imported to an existing database? Is customization of reports available? Can new reports be created? Does the platform supply a means of personalization based on analytics? The Case for Application Conversion Applications written in VXML can be moved between open standards platforms with minimal re-work. Applications running on legacy IVR systems are written in a proprietary language and can only be run on that dedicated system. Until recently, the only method available for moving applications to a new platform was to re-develop from scratch. page 9

10 Whitepaper Specification A challenge facing many enterprises is the specification of a new IVR application. Applications were usually deployed against a set of requirements defined for the new system, yet rarely are projects deployed exactly as they were designed. Code modifications are inevitable. Functions are added or removed as business needs change, or as back-end services are modified. All of this usually happened before the system had even taken a live call. Business logic and procedures are completely preserved and protected. Another challenge facing enterprises is ensuring that documentation keeps pace with these changes. Rigorous project methodologies are required so that: Changes to the business requirements (and as a result of the features and functions of the application) are managed through a change control process. Any incidental changes that occur during development and implementation are passed back through that change control. The first point is usually easy to manage and control. However, when project timelines and budgets are under pressure, it is typical for deployed applications to differ, sometimes substantially, from the original requirements; or that features do not operate as intended or required. Upon entry into a project involving the migration of applications to a new platform, the first step should be to verify that the existing design documentation is correct. If this has not been kept up to date, then a complete review and re-documentation of the production applications is required. This can be costly and time consuming. When not completed properly, a manual re-development project will deliver different code from that which currently exists in production. When using an automated migration tool, this verification is not a requirement. The live code is the basis for the translation and therefore, the final result will be an exact match for the application that is currently in service. Business logic and procedures are then completely preserved and protected. Risk of Disruption In a manual re-development project, there is a much higher risk of disruption to a business. A manual re-development page 10

11 Considerations When Migrating Legacy IVR Applications entails changing 100% of the code in place, since the applications are created from a clean sheet. There is a much lower risk in migrating than rewriting. While rewriting requires changing 100% of the code, automated application conversion entails manually changing only between 10% and 20%. The risk of disruption is therefore 5 to 10 times lower. In practice, risk is reduced even further as the elements that must be coded by hand are predominantly data access components and speech engine grammars. While these modules are critical to the operation of an application, the success of their migration is binary. They either fulfill their function or they don t. If they are not migrated correctly, their non-operation will cause a failure rather than a change in feature or function. Also, since an automated migration versus a re-development effort takes far less time, enterprises experience significantly less disruption. A typical automated migration project saves between 75% and 85% time versus a same-effort re-development project. This statistic becomes very important for companies that have technology freezes for holiday rushes or other reasons. Timescales Enterprises are continually under pressure to deliver technology projects quickly in order to meet business and customer objectives. Manual re-development of applications is entirely resourcedependent, and even with the largest projects, there is a limit to how many developers can be used to shorten a project s timeline. An automated project does not need application documentation or specification; this alone saves considerable time and cost. Using automation, code can be converted to the new platform in the time that it would take to re-document the applications in preparation for a manual re-development project. The entire migration can typically be delivered in 25% of the time that it would take to manually redevelop existing applications. This provides significant gains in allowing corporations to address the requirement to move away from existing end-of-life IVR platforms and to new open standards-based platforms. Using automation, code can be converted to the new platform in the time that it would take to re-document the applications in preparation for a manual re-development project, saving time and cost. page 11

12 Whitepaper Arca+ is a powerful translation medium for IVR applications. Because it separates the application from the platform that the application runs on, applications are futureproofed and do not have to be recreated every time technology advances occur and platforms reach end-of-life. About Arca+ Arca+ is a powerful translation medium for IVR applications. Because it separates the application from the platform that the application runs on, applications are future-proofed and do not have to be recreated every time technology advances occur and platforms reach end-of-life. Through powerful Function Point Analysis (FPA) processing, Arca+ determines exactly how much of the application will be migrated automatically to the new platform. Arca+ knows what it cannot process, and delivers a complete list of the work that needs to be completed manually. This serves as an accurate benchmark for a project completion schedule. The output of the FPA process also yields a cost analysis of manual redevelopment project versus automated migration using Arca+. The Arca+ design tool is an Eclipse-based rich client plug-in that suits both administrator and developer needs. The tool allows rapid application design by minimizing the clicking and typing transitions found in most IVR design tools. The workflow diagrams serve two purposes: Providing design-time documentation and establishing the runtime workflow. This also removes the typical over-the-wall handoff when the project moves from the design to the development stage. Arca+ Features: Arca+ imports proprietary application code from legacy IVR platforms and exports source code for the next platform. Arca+ is the first tool that delivers a high automation rate for converting proprietary IVR applications to open standards. Different technology-specific channel adaptors are deployed according to the browser, platform or gateway that acts as the conduit to the outside world. The abstraction of the business logic from both the channel and the interaction platform provides Arca+ with total independence from proprietary IVR languages. Import adaptors allow existing proprietary IVR applications to be imported into the Arca+ design environment. No license or annual support costs are associated with an Arca+ conversion. The cost is based on the effort necessary to redevelop applications from scratch and the savings incurred by using Arca+. page 12

13 Considerations When Migrating Legacy IVR Applications Using Arca+ to De-Risk Change Utilization of Arca+ from Arca Software provides enterprises with a risk-free approach in moving from aged proprietary IVR systems to new open standards-based IVR solutions. Automated Migration using Arca+ ensures that: Applications are converted one-for-one. All existing features of the legacy application are included. The need for redesign and re-documentation is eliminated. The project is completed for at least 50% of the cost of a manual redevelopment. The project is completed in at least 25% of the time of a manual redevelopment. Using Arca+ to migrate to new technology can cut significant cost. These cost savings may be put to work for your organization by adding new automation channels, new application features, personalization, additional reporting/analytics, social media, or location-based services. About Integrated Voice Solutions Integrated Voice Solutions (IVS), a Boston-based company, was founded in 2004 with the goal of coupling a world-class professional services team with a belief that through the acceptance of open standards, clients can maintain technology on their own terms. IVS has core experience in data access methods, application design and development, and multi- channel implementations. To learn more about IVS please visit us at Using Arca+, you can migrate from legacy end-oflife platforms at 50% of the cost and in 25% of the time of a new development project. IVS offers a free, no obligation migration cost analysis. Please contact us today to get started! Contact Information Lyndell Gibson, VP of Business Development Integrated Voice Solutions sales@integratedvoicesolutions.com (p) page 13

14 Integrated Voice Solutions Copyright 2012 Integrated Voice Solutions. All rights reserved.