Speech on a Network

"The SOA will be led by core business applications, and speech will have to be led by those applications as well," Cramoysan says.  "It’s a fine aspiration to get [speech applications into] an SOA, but until the back-end systems are there, it may not be possible."

Early Engagement
That’s why Cawn and many of his colleagues recommend involving as many rungs of the corporate ladder as possible before deciding how an SOA should be structured. "As you start to look at expanding and growing your application base, don’t do it in a vacuum. Get linked into the entire enterprise, IT, and business organization," Cawn says. "Get engaged early with the IT architects who are in touch with how the entire enterprise is structured."

Cawn also advises the same for call centers. "To build it as an island unto itself is a recipe for disaster in this modern, connected world," he says.

At the same time, though, it is not wise to leave the speech application development solely in the hands of the company’s traditional Web developers. "You should still have your VUI designers build your speech systems," says Ken Rehor, an independent consultant specializing in open-standards telephony, voice, and multimodal applications. "One of the benefits of an SOA is that you can separate out your applications and build them independently."

Simply involving all the key corporate players is not enough, Rehor adds. "Make sure everyone agrees on the goals you’re trying to achieve," he says. "Just rewriting a program is not good if you do not have set goals and not everyone understands why you’re doing it."

Similarly, embedding applications and functions or tying them into specific customer interactions is no longer a good idea, according to Roberto Pieraccini, chief technology officer at hosted IVR provider SpeechCycle. "You want to be creating a universal interface for Web services. That’s a good idea," he says.

Furthermore, building a truly effective SOA means "having access to information and processes outside the core phone environment," notes Beatriz Infante, CEO of VoiceObjects.

In getting back-end systems ready, network security has to be priority number one. "You need to put in a secure infrastructure," Infante says. She notes that creating an SOA where everything is housed on a networked server or the Internet opens the stage for hackers.

Unlike previous closed-loop systems, more open SOA environments are subject to the same kinds of viruses, spyware, denial-of-service attacks, spam, and phishing as other data networks and Web-based systems. They also, therefore, require the same levels of protection, including firewalls, filtering software, encryption, and network traffic monitoring. "Security, logging, and even analytics are needed more in an open-source environment," Infante maintains.

"In an SOA environment, monitoring and managing every application is critical," adds Brian Gollaher, product manager of the contact center business unit at Empirix. "You can’t deploy anything that can’t be managed and monitored. You can’t put anything on your network that you can’t secure."

But IBM’s Cawn is quick to point out that an SOA doesn’t necessarily have to involve the Web; even though SOA has taken on a heavy Web orientation, many SOAs have been built using legacy mainframe applications. "Anything can be adapted to an SOA framework. We’re still living with a large number of legacy applications out there," he says.

Slow Down
Once a business does start down the path to an SOA and has made all the necessary back-end systems adjustments, the tendency is to try to do too much at once. Many even think they will have to rip out all of their existing applications and start from scratch, something that Koloski and others think might be overkill. "It’s not about building new apps, but bringing a new level of interdependence to existing apps," he says. "Most organizations are doing it in incremental changes. Most enterprises tend to [build an SOA] as incremental improvements to existing applications."

While companies certainly can build an SOA from scratch, starting from the ground up can be a big, expensive job. "For the vast majority, you can’t ask to do a full rip and replace because of the time and money involved," Koloski says, noting that most often the approach is to "wrap existing applications around an integration layer with newer interfaces."

Gartner analysts have even predicted that more than 70 percent of all services deployed through an SOA will be built using existing systems and technologies.

Along the same vein, early on many businesses sought out and expected vendors to deliver an SOA in a box—something they could buy off the shelf, open, plug into a network, and go. Not only do such products not exist, but analysts and consultants would urge companies to avoid them if they did. They strongly caution against jumping into an SOA too fast or on too big of a scale all at once.

To do so would result only in many things being overlooked because most modern speech deployments involve a combination of parts from many vendors. "One thing to pay attention to is multivendor integration," says Infante, who notes that many companies are still trying to adjust after spending the past 25 years in a closed environment where they only had to deal with one vendor.

"You have to layer in your budgeting to be a phased implementation. Because you’re doing this in a multivendor environment, you have to work with [all the vendors] to make it happen and debug the system across multiple servers if each component is going to be worked into the system," she says.