Getting Bigger Reach Through Speech
Developers have a chance to significantly expand the appeal and reach of their applications by voice-enabling their applications, but is that going to be enough?
MIKE VIZARD: Hello, and welcome to another edition of the ACM Queuecast, with your host, Mike Vizard. Joining me today to talk about telephony development in technology such as SIP is Mark Ericson, director of product strategy for BlueNote Networks. Mark, welcome to the show.
MARK ERICSON: Thank you, Mike.
VIZARD: I don't think most people are familiar with BlueNote Networks, so why don't you just tell them a little bit about what it is you guys do, exactly?
ERICSON: Certainly. BlueNote Networks has a product line called Session Suite, which offers IP telephony as a software solution so it can be deployed and managed as software in an IT environment and delivers standard-based IP telephony but also offers web services or standard soap-based APIs for integrating voice as a service into business applications and business processes.
VIZARD: That's kind of interesting because telephony has been almost a force or an environment unto itself for all these years and you had to be a specialist in that area, and yet today we hear about the movement towards web-based standards in that area, and yet, there's not a lot of conversation linking that area or specialty to general purpose service-oriented architecture, development on the Web and all the standard technologies you see there, whether it's things like SOAP or things like Ajax. So I guess my question is, when are these two worlds going to come together, and what are the drivers to make that happen?
ERICSON: That's an excellent question. I think the two worlds are coming together. We certainly hear a lot about people interested in leveraging voice in ways that are better to drive business value in their organization, and see that some application business process integration might provide that. Also, the trend towards service-oriented architecture is a very standard common way to do application integration and building out new application infrastructure, I think we see these two trends converging, and I think the reason it hasn't been widely successful is that part of the problem is that the traditional approach to this is to take traditional telephony APIs and wrapper them as web-services, and traditional telephony APIs are more about the device than they are about the people that are interacting, so you look at some of these APIs, and they're very low level abstraction where you pretty much have to be a telephony expert to leverage those APIs and you have to be aware of the signaling that goes on in telephony and various states that take place, like off hook, and the volume of the device and a lot of details there.
So I think to be successful as Web services have brought up the level of abstraction for application integration is to deliver Web services APIs that are closer to the business application and business processes.
VIZARD: So does that mean then I'm essentially masking all that complexity from the developer community, but then you would get some kind of resistance from the people who are specialists in that area because they would say to themselves, well, I don't want everybody who's anybody who'd be a general purpose developer suddenly be a telephony developer. Are we really talking about a cultural issue versus a technology issue?
ERICSON: I think there are certainly cultural issues, and there are many organizations where there still are islands of the telephony people and infrastructure people that are separate from the applications people or where computer telephony integration is a very special skill that doesn't necessarily bring the application domain experience.
So I think as the business owners in an organization look at this, they certainly see the value of bringing telephony closer to the business problem they are trying to solve, and make it easy to add human communications in the business processes, and again, where this communication is about contacting a person, not ringing a device. So someone needs to be a ... to fulfil their role in some business process, these web service APIs can be leveraged in the application in a way that it'll contact that person over whatever channel, wherever they might be located to ring them to have them fulfill their role in that process.
VIZARD: So ultimately I want to target the person's role or even their identity rather than specifically the device they happen to be walking around with.
ERICSON: That's correct.
VIZARD: I already hear telephony people saying, well, we've been hearing this story forever and a day, but there's still certain core telephony apps that they can't develop on a Web-based infrastructure or even outside of your standard phone infrastructure. Is that still the case, and if so, how long will that be the case?
ERICSON: Well, I think that maybe the case with some of the traditional PBX infrastructure that hasn't been modernized and really still takes approach of a device-centric model and a hardware approach to the problem. I think the emergence of SIP-based telephony and the flexibility of software solutions for telephony are really changing the model of the way deploying both the telephony infrastructure and applications around that are viewed.
VIZARD: How cognizant are the traditional application developers about the implications of SIP in terms of how they build their applications, because even today, there's still what I would call tech-centric versus thinking about integrating voice into those applications.
ERICSON: That's very true. And many of the technologies that are being targeted to the tech-centric developer which include things like SIP servlets and JTAPI are very low-level, and those people, again, have to understand the details of signaling protocol to leverage those APIs. I think our challenge and what we are pursuing is looking to the people that are the business process owners or are looking to solve real business problems and challenges, such as challenges in the supply chain where exceptions can cause great delays and expense if the right person can't be reached at the right time or someone in the right role can't be reached.
So by looking at the business problem you're trying to solve by communications enabling it, it becomes less of a techy issue than it does a real business goal and opportunity to save money or increase revenue through the voice integration.
VIZARD: So if you're looking out into 2008 and beyond, if you're going to start a project today, can you really imagine an application a year from now that doesn't have some kind of built-in support for SIP and voice? Are people just going to look at that application if it doesn't have it and say, `that's kind of yesterday's news?'
ERICSON: Well, I think we'll get to that point. I think it still is an emerging technology and its leading adopters that are bringing in SIP into an SOA environment. And certainly SOA has had a long adoption curve and the early innovators have really taken off with SOA and led the curve. I think we'll see the same thing with SIP and SOA integration. I think as people think about delivering voice as a service, as part of their SOA, leveraging their existing investment in an ESB or other orchestration tools or BPM tools and realize that voice is just an additional service that can be leveraged in those applications, they'll start thinking about new ideas, about how they can solve business problems and people as you suggested will be looking for the applications that have been voice-enabled for business reasons.
VIZARD: What is the history of BlueNote? As I understand it, this isn't exactly something you guys built in a lab as your standard venture capitalist firm. You guys built this as almost customers yourselves and now we're taking this to market.
ERICSON: Well, it's very true that we built this and used our own software, for our own Internet telephony purposes, and our history actually goes back to Fidelity Ventures where Fidelity saw need for a more flexible telephony solution that could be deployed as software and could support the changing workforce that is increasingly mobile and realized that they needed the flexibility of a software-based solution and a standard solution, but we're looking for something that could be a commercial offering, realizing that the open source solutions really do not have the enterprise-class scalability or reliability that would be required by a company like Fidelity.
So in a sense, BlueNote was spun out of Fidelity Ventures to create such an enterprise-class solution for telephony.
VIZARD: And in that model, what you're really talking about then is that the targeted client becomes essentially a universal client. You don't really care if it's a PC equipped with a soft PC or if it's a phone equipped with web capabilities, what you're really on about is that it's targeting the user and being able to track the presence of a user, I guess, when they're actually using whichever device that they have?
ERICSON: Certainly, certainly. A user can be on the road with a soft phone that could be either installed or on their laptop or maybe they're at an Internet cafe and logged onto a PC in a browser with our web caller capability and now they're accessible by phone wherever they might be, and can be found by those business processes that want to reach them.
VIZARD: Now do I have to be a rocket scientist to do this or do you think the average developer can master that kind of integration capabilities?
ERICSON: No, I think the average developer can certainly do this. One example, a customer we have announced, is the Seaport Hotel in Boston, and it turns out the developer who worked on that project was actually a Visual Basic developer and added Rich telephony capabilities to their web portal.
So this abstraction level that we're talking about really truly brings the problem up to the business domain, connecting users that need to communicate on the behalf of some business application or process.
VIZARD: So I'm not really talking about building something from the ground up if I don't have to. I could actually use your technology to SIP-enable or voice-enable an existing application?
ERICSON: That's correct. You can look at Session Suite's server software as a complete IPBX alternative, although we have much richer capabilities than that, for delivering true Internet telephony that spans the walls of the business. So that we provide the complete infrastructure and then the integration APIs, but also what's very important in a situation where there already is an investment in an existing PBX, you can deploy the software along with that PBX and utilize a Session Suite APIs that provide that high level abstraction with existing telephony infrastructure.
That becomes even more important in an environment, an enterprise where they might actually have as a result of acquisitions or other things, quite a variety of PBX's in the environment, and there are sessions we can provide a common API -- Web services API -- independent of the underlying telephony infrastructure.
VIZARD: So what would be your best advice to developers today as they try to wrap their arms around the perceived complexities around telephony and new standards on the Web, and kind of say, where should they start?
ERICSON: Well, I would say start with top-down. Look at the problem you're trying to solve and look for the best solution. Certainly if your organization has adopted web services as a means of application integration or have that knowledgeable, look for solutions that support Web service as APIs. And look for ones that not only provide what we would refer to as the lifecycle API's of managing the call session from start to finish, but also ones that utilize web services for mid-call control, the ability to route calls as they occur or to that capability also would allow screen pop in application.
So look at the business problem, look at the technology and architecture you're using as an organization for integration in contrast to a bottom-up approach that might say, well, JCAPI is out there, let's start with that technology and then look for a problem to solve.
VIZARD: So is that the fundamental takeaway, that for years now, everybody has been working their way from the bottom-up, working on a device level driver or interface and trying to figure out how to plug that into some larger set of applications when today what we're really looking at is, as you said, a top-down approach where we've got a fundamental architecture and then there are abstractions around that architecture that link us to various other devices?
ERICSON: Yes. I think that's a good takeaway, to think about voice as a service in an SOA and about delivering those services for the people that need to interact around business processes, and not have it be about the device or the underlying infrastructure or the actual low-level protocols.
VIZARD: Mark, I'd like to thank you for taking some time to be on the show and we wish you the best of luck in the future and I guess if people want more information about what you guys do, they'll find it at www.bluenotenetworks.com, and we'll talk to you soon again.
ERICSON: That's correct, thank you very much for having me, Mike.
Originally published in Queue vol. 5, no. 4—
see this item in the ACM Digital Library