Wrap It Up
Each year during the most popular speech conferences, the same two questions seem to arise: • Why is the adoption rate of speech so slow? and;
• What should vendors be doing differently to propel the industry forward? Years ago, these questions could easily be answered by pointing out that speech recognition was an emerging technology whose business benefits were largely unknown, Today, however, it is clear that these questions are typically born out of pure frustration. The business benefits of speech are now obvious and have been proven repeatedly across the enterprise. The answer could lie in the fact that, despite best efforts, speech is still extremely complex to implement and “get right.” This almost always translates into an uncertainty and risk that many businesses are not prepared to undertake. Today, the industry is seeing the emergence of some interesting solutions that could change this thinking. These solutions have the potential to significantly lower costs, complexity and time-to-market. And interestingly, they are starting to uncover what has traditionally been known as the “hidden application backlog.”
THE HIDDEN APPLICATION BACKLOG
The theory is this: Since it takes so long to deliver a single system, users only ask for one system at a time because they know they won’t get more than that anyway. There is no bandwidth or money to create additional systems and the risk and costs associated with the current effort is too high to justify multiple projects. However, when new alternatives emerge that lower complexity and dramatically reduce time-to-market, users see the potential and suddenly reveal all the applications they’ve been hording. This goes beyond theory. Industry analyst James Martin discussed the hidden application backlog in his book “Application Development Without Programmers” (Prentice Hall, 1981). While describing the backlog caused by the complexities of COBOL and similar languages available at that time, three technologies emerged that changed this way of thinking: • First, a standard was determined. In the 1980s case, it was SQL;
• Second, fourth generation languages (4GLs), which introduced a graphical approach to application creation;
• Third, packaged applications that eliminated the need for custom development, especially of routine business functions. After seeing how quickly an application could be created in a 4GL, it was fairly common to hear a business user say: “If it is that easy, here are all the other applications I’d like.” Hence, the hidden application backlog revealed itself and the database industry experienced tremendous growth. This phenomenon was repeated when client/server fever broke out (SQL and ActiveX were the standards, Windows GUI tools were the enabling technology and systems like Siebel were the packaged solutions). And it happened again when thin client Web solutions became the call of the day (Java and HTML were the standards, applications servers and Web development tools the enablers, and browser-oriented packaged applications completed the cycle). In all cases, until all three of these technologies emerged, the sub-industries they were related to were crawling along. But once the three technologies became available, those sub-industries enjoyed explosive growth. And if history is anything to go by, the speech industry is on the cusp of that same upsurge. If one compares the speech equivalent of the three technology breakthroughs with other industries, the similarities are striking. VoiceXML and SALT are widely accepted standards and there are many platforms to choose from. A number of companies now offer VoiceXML development tools and reusable components that reduce the rocket-science nature of speech. And packaged speech applications have started to appear on the market in a variety of sectors and for a range of business functions. Another observation that supports an upcoming trend is that the number of speech self-service systems being contracted out today roughly equals the percentage of Web self-service systems that are either acquired as applications or developed with in-house skills. Yet when the Web was in its infancy and HTML and Web design skills were hard to find, the percentage of outsourced applications was not much different from where speech is today.
THE BENEFITS OF PACKAGED APPLICATIONS Packaged applications may require enterprises to relinquish a degree of familiarity and fit. But the rewards are overwhelmingly significant. Here are some of the expected gains:
Lower cost of ownership. The upfront cost and ongoing maintenance of a packaged application will typically be well below the cost of a custom solution.
Faster deployment. The time to configure a packaged application to business needs will generally be a fraction of the time to specify and custom implement the same application.
Greater savings. Since deployment cycles are shorter, contact centers can start reaping the financial benefits of speech automation much sooner.
Lower risk. The quality, functionality and fit of packaged applications can be assessed very early in the evaluation cycle. They virtually eliminate the uncertainty of lengthy custom projects.
Quality and completeness. Applications vendors are motivated competitively to deliver the most well-designed, comprehensive and quality offerings. Typically, application software will go through extensive usability testing, tuning and quality assurance processes before it reaches a customer’s server. In addition, incremental versions of the product will improve in functionality and effectiveness based on customer feedback from earlier releases. For example, a typical services bid to create three self-service applications of average complexity would be between $500,000 and $1 million, with a development timeline of six months to a year. By comparison, packaged applications with equivalent functionality that are configured to business needs might cost $100,000-$300,000 and be deployed in two to four months. These figures do not include the hardware, telephony and speech technology costs that would be common to both implementations.
DEFINING A PACKAGED SPEECH APPLICATION The next question might be whether packaged applications are really viable in a speech context. To determine the answer, let’s first examine the attributes of a true packaged speech application. Packaged applications are software products. To some, this may seem an obvious statement, but in reality very few of the companies promoting “applications” specify or ship them as products with documentation, functionality and compatibility upgrades, technical support and bug fixes. Packaged applications are platform-independent. This means that they will work with different telephony platforms and different speech engines, as well as allow businesses to change platforms without having to re-write the applications. Implicit in this attribute is support for standards, such as VoiceXML, or emerging ones, such as SALT. Figure 1 shows how the architecture of a packaged application might provide for platform independence and support for standards. By separating the application itself from the telephony environment (e.g. an IVR system), the dependency on that platform is reduced. This architecture also models that of Web systems and allows for easier integration into existing infrastructure that may already be in place for Web selfservice. Of course, custom applications may (and will increasingly) adopt a modern application architecture, although the majority of these have historically not been deployed this way. Packaged applications work out of the box. They are not templates that require a professional services effort to fully implement. They should function without modification. These applications must be configurable. While they should work out of the box, the ability to configure applications to meet specific business requirements is essential, especially in a self-service environment. Again, if professional services are required to modify the packaged applications to the extent they are no longer recognizable or maintainable by the applications vendor, the benefits of packaging are minimized.
WHY THESE ATTRIBUTES ARE IMPORTANT 
What if the application you buy doesn’t contain all these attributes? If you’re buying an application that isn’t really a software product or doesn’t work out of the box, it is likely to be nothing more than a starting point for a custom project. And that’s not to say custom projects are necessarily ineffective, but if the majority of applications continue to be custom-built, the opportunity for broad and rapid adoption of speech is limited. If the application is not platform-independent, that means a lengthy and potentially costly commitment to the platform vendor of choice. Even if an application is created using open standards, that does not necessarily mean it will be portable to other platforms due to variable implementations of those standards. If a self-service packaged application is static and cannot be easily modified or extended, it will probably be of little value to an enterprise. Every company has different business rules, different data interfaces and different personalities, among other requirements, that they might want to apply. Furthermore, these requirements will undoubtedly change over time. Enterprises will also need a standards-based interface (for example, through XML) to integrate the applications into their backend data and may also want to add dialogs to them. Today, managing these changes is an expensive proposition for most enterprises, and configurability is vital to bringing those costs under control.
PACKAGED APPLICATION OFFERINGS Today, a number of vendors offer applications. But as described above, not all applications are created equal. Let’s review the types of solutions and then see how they compare against the requirements for a packaged application:
Application solutions or components. Some vendors describe their offering as application “solutions.” This typically translates into pre-built templates or components that will be used in the process of delivering a custom solution. These components help reduce time-to-market and initial costs. In most cases, enterprises will own the completed system and maintenance of it will be managed internally or through a services contract. Some components are licensed as products; others are templates that will only be used during services engagements.
Configurable applications. These are fully developed applications that usually include an environment for configuring and managing the applications over time. They ensure rapid deployment cycles and low total cost of ownership. The applications give enterprises the flexibility of platform independence and on-premise or hosted configurations.
Shrink-wrapped applications. These are fully-developed applications, but have limited customization abilities, generally because they are not required. These applications are more common for non-selfservice functions and where great flexibility is not critical. These applications are also licensed from vendors with upgrades and new features being available as part of an annual software maintenance agreement.
Applications-as-a-service. These applications are available as part of a hosted service offering for which a regular hosting fee is incurred. They typically require a low initial investment but offer fairly limited configurability options since the hosting provider is incented to run the same application for multiple customers. These applications are available on a service basis only and rights to use and access the application end when the service is terminated.
ATTRIBUTES OF PACKAGED APPLICATIONS The preferences of each enterprise might drive the decision to implement a certain type of solution. For example, most of the alternatives can run on-premise or as hosted solutions except for the application-as-a service offerings. If a high degree of flexibility and control is required and the expectation is to change applications on a regular basis, then configurable applications might be the best approach. Some companies prefer to own all the intellectual property for their systems (which will frequently be driven by a negotiation with a professional services provider), while others favor the idea of another party maintaining software that is outside of the enterprise’s core business (which implies leaning toward packaged approaches).
As for the viability of packaged speech applications, the bottom line on all of the alternatives mentioned is that they will invariably be more cost-effective and faster to deploy than custom built solutions. They also significantly reduce the uncertainty of today’s lengthy system rollouts by allowing enterprises to evaluate and understand what they’re getting before they get it. And while not every application is available in a packaged format right now, based on the number of new offerings in the market in 2003 alone, it will not be long before many of the bases are covered across a wide range of industries. As these packaged application offerings emerge, the question for most enterprises will become not whether to implement a speech system, but which of the 30 applications they haven’t even talked about yet, to use first. And vendors should be preparing for the transition to a time where those speech adoption questions are a thing of the past, and keeping up with high customer demand is the main topic of conversation.
Steve Ehrlich is VP of marketing at Apptera. Recently he has been consulting for companies in the speech industry and prior to that was VP of Marketing at Nuance. He can be reached at
sehrlich@apptera.com.