The S-Word and Building Glass Towers
Last year, in a vacant lot by the Hudson River in Greenwich Village (where I live), they broke ground on not one, but two 15-story glass "residences" designed by architect Richard Meier. It was rumored that Calvin would take one penthouse and Martha would take the other.
That was a year ago. Today they stand completed, with floor-to-ceiling glass walls. (By the way, you can rent one of the apartments for about $25,000 a month.) Let’s just say that in the current economy, the moving vans aren’t exactly double-parked out front. That brings me to the point of this month’s column. Not too long ago, while scrambling to meet a client’s latest 24-hour deadline connected to yet another full-tilt-boogie procurement, I had a scary thought. That was, "We’re working with VoiceXML and speech on this project, but are we building another glass tower – one that looks like, dare I say it, another silo?’
It was then that the "S word" reared its ugly head. Just because we’re working with open standards and speech recognizers that promiscuously romp with agnostic voice application frameworks, driven by commercial Web servers running VoiceXML or SALT scripts, does that really provide insurance against developing a silo app that eerily resembles the IVR we’re replacing? You might respond, "Quit being so paranoid and define what you mean by silo." Glad you asked.
Way back in the 20th Century, we defined silos as separate proprietary implementations (often on multiple platforms) by different departments within a large organization. IVR was a great silo technology because it was sold on the premise that you could sidle up one of these refrigerators next to the mainframe and the glass-house guys couldn’t tell it from a 3274 front-end processor. So what defines a 21st Century silo? It sounds something like this: "We have identified an initial application that we think can deliver significant cost-reduction through higher automation rates than our legacy touchtone/live agent treatment. We want to develop a pilot and then aggressively cut over traffic to the ASR solution to generate an ROI in less than a year. Along the way, we want to rip out our network prompts, which cost way too much money, and deliver further cost savings. We want to do this in four months or less."
In other words, it might sound a lot like your customer. But do we really have the fortitude to say, "Wait a minute, we need to take a holistic look at this?" And at what point in the post-sales process do you say to the hup-hup project team: "We need to have a larger context, which is a multi-channel solution that plugs into a common XML/SOAP/WSDL data access layer shared by Web and wireless delivery channels. So let’s go talk to those guys" (Those guys, by the way, are spending a whole lot of money on EAI.)
Is that what a full-tilt-boogie implementation team wants to hear? Maybe. But if not, do you tell them what they want to hear? That’s how silos get built. So what’s wrong with all this? Here are three candidates:
- Reusability: Because we didn’t take the time to identify the core objects and grammars that can be applied to multiple future applications, we can count on having to redo that later and lose cost reduction from reuse.
- Geometrically decreasing time-to-market: Because we totally focused on our initial applications, we didn’t build a replicable process that allows other business units to get through their audits and requirements definition steps faster.
- Ultimate customer experience: Because we didn’t take the time to do a true multi-channel audit and built this "speech thing" separately, we missed the opportunity to drive Web and wireless experiences from the phone channel.
If you’re still with me, you’ve either got time on your hands or you really want to "do the right thing." So how do we avoid paying $25,000 a month to have other people gawk at us? The basic "STEPs" (a pun on SpeechWorks’ structured discovery process) are:
- Good process: One that captures actionable information that crosses business units and yields, for example, reusable components.
- Good discovery: You can’t achieve what you can’t measure, and measurement starts with strong auditing and objectives definition.
- Good frameworks: There are two choices here. You can go to the customer’s Web site and copy what they did there in VoiceXML or you can code it so that it actually does use the same data stores and business logic, in which case it’s not a silo.
In an industry built by geeks and PhDs, that still measures itself in terms of technical prowess all too often, real success is based on 50 percent technology and 50 percent good marketing. Getting customers to "do the right thing" is good marketing, whether it’s pre-sale or post-sale. If that sounds critical, hey, I don’t live in a glass house.
Mark Plakias is a senior vice president and managing director of communications and infrastructure for The Kelsey Group. He can be reached at (609) 921-7200.