More than IVRs

"OK, so let me understand this... you guys do IVRs, right? I don't really understand what's new here. We've had IVRs forever."

To live in the real world means to live with constraints. I am unable to jump over a tree. I will live less than 100 years. I am unable to add numbers as fast as my computer. I cannot fit three cars in my bedroom. As we move through our lives, we make decisions based on these constraints so often, we no longer understand that we do it. Good thing too, because if we did have to run through the list of what we couldn't do all the time, we would be paralyzed. (I have to be in the Cape Cod office in 90 minutes, so there is no time to swing by Paris for breakfast.) Our minds are honed to consider the possible by a clever method: we tend to construct our understanding primarily based on our current knowledge, giving rise to an endless series of deltas. I remember an English class where we were working on a dictionary entry formula : you define a noun based on two parts, the first being what the noun is like, the second is how it's different. A tiger is a 1) CAT that 2) has stripes, a big body and large fangs. You define a tiger using what you know (a cat) and then describing why that first thing is insufficient (which can eat you for lunch.)

Of course, engineers are no different, except that when we design, constraints are quite at the top of our attention. I would even posit that we understand and describe our designs through constraints. Like a sculptor, removing the stone to reveal the statue, we draw boxes on whiteboards to explicitly limit the functionality of what we design. We understand that, unless we limit our tasks aggressively, we will be unable to see our design come to life. It why we cringe when the marketing man comes in the room, as his motivations are quite different than ours. They make us draw more and bigger boxes, removing our constraints and adding to our worries.

What might not be apparent from the outside is that an amazing has happened recently in the world of technology. The combination of web services, lightweight programming models and Internet architectures based on open source tools radically reduces the constraints on hosted application development. The advent of Web Services means that you can publish your functionality to the Internet in a controlled, standard way. Since the cost of publishing is so low, the amount of customer traction you need to break even is low, making the amount of web services that are available to you as a designer to be much larger. An example would be a web service that verifies that a person's name matches an address, and will be valuable to any company looking to avoid fraud. Lightweight programming models radically reduce the cost to create web applications by reducing the skills required to write them, and the number of people required to author and maintain them. Internet architectures are naturally resilient and scalable, removing many of the stability constraints that dog other forms of software development. As a concrete example, I would have you consider that both Yahoo! and Google run their infrastructures on off the shelf hardware and open source software, versus Verizon who runs their infrastructure on gold plated, multi-million dollar telecommunication switches. The difference is in architecture, which removes the constraint of having each element be bullet-proof and stable. In the Internet architecture, servers can go down because there are multiple paths to your web page. In telecom architecture, the phone on your wall is connected to exactly one central office.

The combination of these forces makes the development and delivery of hosted services much, much less expensive, for services of all kinds. My career interest is in telecommunications, thus, I am looking at how the constraints of typical voice services are lowered. IVR is a good example, of course there are many others. Using an online service from a place like Voxeo, I can draw a box on my white board called IVR that I can implement quickly and inexpensively. How might I use it? In any way I wish, blended into any sort of application I wish. I am no longer constrained by having to purchase equipment, or by having to learn an esoteric language to run it, or to be locked into a particular vendor, or to have troubles interfacing it to my software. It is no exaggeration to say that I am now able to make function calls that retrieve data from an IVR script as easily as I can that retrieve information from a database. In fact, given that it takes me a couple of hours to setup a database, the IVR might be easier. I can tell you the same thing about a whole host of telephony services, like SMS. I could also make the same argument about any other web service used from my IVR, like I could call a phone number and make my google maps on my screen do things if I wanted. I could - any up-to-date software engineer could.

So, given that these constraints have fallen through the floor, what does my company do? We are figuring out exactly which hosted solutions, especially those that use real time communications, work inside businesses to make the business faster, more efficient and makes their customers happier. Then, we work with businesses to implement these new services into their business process. IVRs are a part. So is SMS. So is Google Maps. So is.... you get the point. What is different is not the functionality, but the constraints. The implications are endless.