Houses and Windows: Distinguishing between Packaged Applications and Components
As the business necessity for speech-enabled systems gains awareness throughout the contact center, enterprises are burdened with the question of how best to approach the implementation of new applications. The complex issue not only involves an understanding of software and development approaches, but also of skill set requirements, availability of resources, internal IT support, and of course, business requirements.
Everyone is interested in the fastest and cheapest way to automate customer service functions, and not surprisingly, many vendors promote their solution as addressing those issues. Three approaches have emerged as a means to accelerate the deployment of speech applications, promising improvements over the hand-coding method traditionally adopted by professional services organizations. These approaches are:
- Component - A component is a piece of software that can be combined with other pieces to construct a program or application. Components are commonly assembled from other components and are designed to improve developer productivity through reusability and elimination of repetitive programming tasks. Component developers constantly have to balance generic functionality that can be applied to many different problems with overly complex components that try to allow for too many eventualities. Examples of components are list boxes and data entry fields, easily visible on many Web pages.
- Template - A template is a pattern used to replicate objects. Unlike components that implement specific functions, templates usually provide a shell or framework for application functionality. In fact, templates that define global application behaviors and user interface standards are commonly combined with components in the application creation process. Templates are commonly used on Web sites to impart a consistent look-and-feel to Web pages, for example, borders, fonts and general page layout.
- Packaged applications - An application is a software program designed to perform a specific set of functions. Packaged applications are implementations that have undergone the rigor and process required to produce a repeatable and licensable software product. In most markets, the availability of packaged applications - for example, CRM solutions - has eliminated or reduced the need and desire for custom-built alternatives.
It is important to note that some form of configurability or customization will almost always be needed regardless of the approach, in order to make components, templates or applications conform to the requirements of an enterprise. This is especially true for speech systems since highly-tuned user interfaces are often critical to caller acceptance.
The sophistication of the deployment starting point and the complexity of the business requirements dictate the degree of application configurability. It follows that the more generic a component is, the more customization it will require relative to a packaged application – unless the requirements are so different from the packaged software that nearly the entire user interface has to be changed.
A Build vs. Buy Decision
Some people tout the belief that components and packaged applications are simply on a continuum, with richer components approaching the functionality of fully-developed applications. While from a technical perspective this may be true, in most other respects it is not. Consider the following analogy: the decision to build or buy a house. Many house-hunters have two choices:
- They can find a piece of land and build a new house. Commonly this is done using a “template” provided by an architect, and components, such as doors and windows, provided by the local home improvement store.
- They can buy a house that meets, or comes close to meeting their needs and then modify it - by painting or otherwise remodeling.
While the resulting houses in both cases could be identical, the approach to getting there is very different. The “build” case takes significantly longer and requires resources with a wide range of skills. The “buy” scenario can be completed quickly and without the broad engagement of architects, contractors, builders and the like.
Regardless of which approach most “appeals” to an enterprise, it is important to understand when a build or buy decision is most appropriate. It probably makes sense to build the system using components and templates available from various vendors when:
- An enterprise has developers on hand with speech, human factors and programming skills to work on an application
- The application is simple or highly specific to the company
- The enterprise is prepared to maintain and support the application over time
- The enterprise believes it holds specific intellectual property or some competitive differentiation relating to the application
On the other hand, it might make more sense to buy the application off the shelf, assuming it can be obtained in packaged form, when:
- An enterprise has limited resources or skills to work on a speech application
- The application contains functionality common to many businesses
- The enterprise does not want to maintain and support the application over time
- Deployment cost and time-to-market are key decision points
In general, most businesses, especially larger organizations, will have a mix of packaged and custom-built applications in their voice self-service systems—since it doesn’t make sense to only build or only buy every application.
When Components and Templates Do and Don’t Make Sense
As described above, speech components typically consist of several subcomponents – grammars, prompts, and rules – and those can be further broken down into sub-grammars, help and error prompts, and call processing and data validation rules. Common examples of a component are “date” or “money amount” which prompt callers to specify a date or value respectively, and then determine how to process what callers say.
Little question remains that building applications using components versus starting from scratch is a productivity booster. However, component developers continue to be challenged by the following dilemma: If a component is built for too specific a purpose - for example, to capture a money amount in a bill payment application - its usefulness outside of that application instance is limited. On the other hand, if the component is built too generically - such as, to capture a money amount in a wide variety of cases - then just understanding all the complexities of using the component, let alone the customization required to make it work in specific applications, may offset many of the productivity benefits.
In a more generic component for capturing a money amount, the component’s opening prompt might read “please say an amount” and the error and help messages would be similarly generic. The grammar would need to be fairly broad to accommodate the range of ways callers might express a money amount in different instances. Consider using this component in two different systems – one for bill payment and one for mortgage quotes – several issues arise.
First, the prompts need to be changed to something like “How much would you like to pay?” in the bill payment case and “What size of mortgage are you interested in?” in the mortgage quote case. Of course, unless you are prepared to accept a lower quality generic user interface, the error and help messages associated with the component would also need to be changed.
Second, the grammars must be modified and potentially retuned for accuracy and disambiguation. In the bill payment case, the system readily needs to accept amounts that include dollars and cents, while cents are never an option in the mortgage quotes case. Leaving extraneous items in a grammar, such as cents in the mortgage case, can lead to poor speech recognition performance.
Third, the component's rules have to change. The acceptable values in the two systems will diverge and the processing of caller input will be handled differently -- does “three fifty” in the bill payment case mean $350 or $3.50? In the mortgage application, it probably means $350,000.
Unfortunately these types of customizations are a natural byproduct of the intricacies of serial speech interfaces. Unlike graphical components on a Web page which can operate somewhat independently of their context and the other components on the page, speech components must be significantly integrated into the context in which they are used and closely linked to what happened before and what might happen later on in the dialog. Significant changes to a component negate many of the reusability and productivity benefits they offer, and as a result, more vertically-oriented or industry-specific components deliver better results than generic ones.
By contrast, a speech template defines behavior that is common to multiple components within an application. For example, a “menu style” template specifies that the range of responses is limited to a short list and that each response should trigger navigation to somewhere else in the application. It might also specify how error handling and help messages should be presented to a caller, providing a mechanism to consistently incorporate best practices and to make the user interface consistent across the application.
The use of a combination of components and templates aids the productivity of developers building applications, but the fact remains that significant work is required in many cases to modify them to complete the systems. This results in lengthy deployment times and higher maintenance costs over the life of a system.
Table 1 Comparison of the functionality of Reusable Components and Packaged Applications
When Packaged Applications Do and Don’t Make Sense
Packaged speech applications typically consist of a series of components and templates that have been modified ahead of time - usually by the packaged applications vendor - to address a specific need. An enterprise acquiring a packaged application benefits from short deployment cycles, lower total cost of ownership and fewer internal resource and skill dependencies.
The bill payment and mortgage quote applications are examples of applications that can be delivered as a packaged offering. As part of these packaged applications, the aforementioned “money amount” component will already have been modified by the applications vendor to conform to the specific user interface requirements - eliminating the need for a developer to make those specific modifications.
This is not to say that configuration of a packaged application is unnecessary. In many cases, even though the functionality of a packaged application is desirable, an enterprise’s priorities, types of customers, business rules and products influence the wording of prompts, content of grammars and dialog flow. However, assuming the applications vendor has an appropriate architecture in place, these modifications are easier and fewer than modifying individual components.
In fact, if manual modification of prompts and grammars can be avoided altogether, everyone wins – enterprises from a cost and resources perspective and vendors from a time-to-market perspective. An effective model for reducing manual changes is the use of configuration parameters that enable and disable elements of functionality. Using the mortgage application example, a parameter might allow a business to specify whether a mortgage applicant should or should not be qualified based on annual income. Following the parameter, a question relating to annual income could automatically be excluded from or included in the dialog flow – a much quicker and easier-to-maintain result than manual code modifications.
Note that parameter-driven configuration of an application implies a skill set - not of a speech specialist or programmer - but perhaps of a knowledgeable business user. By integrating business and product owners into the rollout of automated speech systems, the typical back-and-forward discussions between developers and their customers is reduced, with the resulting system meeting more customer requirements. Such improvements in business processes lead to successful implementations and make speech more accessible for more applications.
Some enterprises have needs that are so specialized or so simple that buying a packaged application to address those requirements doesn’t make sense. In other words, if the cost of buying and configuring an application exceeds the estimated cost of developing and maintaining it, it may make more sense to build it.
In their own right, components, templates and packaged applications tackle the inherent complexity of deploying speech applications. They deliver value and it is important for enterprises to understand which applications they should attempt to build and which to buy off the shelf. While components and templates are great productivity tools for developers, the strength of packaged applications lies in their rapid deployment abilities and cost efficiencies. Understanding how to best use these technologies can have a significant impact on the quantity and speed of speech applications being deployed by any enterprise.
Steve Ehrlich is vice president of marketing for Apptera and has spent more than 17 years in the software industry. He has been a leading speech advocate for more than six years. Before joining Apptera in 2002, he previously spent four years at Nuance. Prior to that, Ehrlich was with Oracle for 12 years. He is a member of the editorial advisory board for “Speech Technology Magazine” and is a frequent speaker at industry events.