UCStrategies Experts Discuss Multi-Vendor UC Interoperability

UCStrategies' Marty Parker and Russell Bennett presented a session entitled "UC Interoperability" at Interop New York earlier this month. In this Industry Buzz podcast, the UCStrategies Experts tackle the topic. Regarding multi-vendor interoperability, vendors say they have it, customers say they don't. So which is closer to the truth-how much interoperability is really out there? Which different vendors' UC elements work together, and how much integration work has to be done to make products work together? Where (if anywhere) there is true interoperability. Marty and Russell lead the discussion, and this podcast also includes UC Experts Kevin Kieller, Phil Edholm, Don Van Doren, and Art Rosenberg.

Marty Parker: Hi, this is Marty Parker with UCStrategies and today, I'm joined by a number of my fellow UC experts to talk about interoperability. Russell Bennett and I had the great privilege of working together at Interop New York, where we presented a one-hour session on interoperability at the request of the Interop team, people were asking for that from the prior Interop sessions and we were just so happy to present that. (Slides are included below.)

One of the things we emphasized is that interoperability is essential for unified communications in many, many cases. There's only one case where you don't interoperate, and that's where you rip everything you have out and put in some new brand and that one brand is everything you use. That's pretty rare. Almost never is that a good idea economically, let alone a good use of time. It's much better as we've already shown in Enterprise Connect 2012 in the spring in Orlando, that overlaying UC or making selective investments in UC on a roadmap is almost always a better idea.

So, we actually categorized into five categories, ranging from "it just works out of the box," which is the best, to "we the vendors have made it work bi-laterally," to "we, one vendor have made it work unilaterally," which isn't as good. You'll find one vendor says, "we can interoperate with the other vendor," but there's nothing on the other end - that probably works but you don't have assurance that it will be well supported.

And then there's a category called, "We can make it work - gee look at all the application program interfaces and software development kits we have, APIs and SDKs." "Hey you can make it work, or your system integrator can make it work..." That's kind of next to worst because it's going to take some custom time, custom development, you won't be sure it's going to be proven and tested, and the support will be local.

And then we had a fifth category: "it doesn't work at all." And sometimes that's true. But what we did say is that you don't have to have everything interoperate with everything else. We actually had another topic we brought out and you'll see the slide here that talks about the top five areas of UC interoperation. Very often, you will be able to accomplish the application that you want or the applications that you want before UC, by just using one or two of these five areas of interoperation. You can see them - presence and instant messaging, voice sessions, video sessions, conferencing, sharing desktop apps and documents...

And we went on to show diagrams - Russell has a very exciting kind of graphical approach here - I thought it was very useful where he's color-coded from green to yellow to red. Green means everything works; it interoperates on both ends. The two party idea, where we go from one vendor to themselves or one vendor to another and they both agree it interoperates. Yellow means that it's a unilateral interoperation. We didn't put any reds on these charts, but there's one in here about federation that you can see; multi-modal, meaning presence and text plus voice and video or just instant messaging and presence on the other side of the slide.

We did have slides about what's available now for federation of UC with the PBX or with the PSTN - which mostly talked about gateways and about SIP trunking. And then Russell went into a few other examples. For example video MCU interoperability where he, as you can see, displays documented bi-lateral and unilateral interoperability across many brands, ranging from Microsoft to IBM to Polycom to Cisco, Jabber, Skype, Alcatel-Lucent, Lifesize and Radvision, quite an interesting one.

Not shown here is the idea of the cloud-based service. We are finding more and more people like Vidtel and Blue Jeans and Vidyo, are putting services in the cloud that will form a conference of diverse video services or video devices and video MCU's. So that's another option that we did discuss, but we aren't going to complicate this conversation here with that discussion.

So with that, we felt that it was well received. People came up to us with many questions, they wrote in a couple examples in the Q&A period, and what we began to see was that our assumptions were correct, the interoperability problem is usually limited to one or two things in order to make a UC application work. And that means that it's going to be possible to get this done, now that the state of deploy is as advanced as it is, there's plenty of room to grow. But there are plenty of options available. So with that, I'm going to call on Kevin Kieller, who has some additional thoughts he wants to provide on the topic. Kevin?

Kevin Keiller: Thank you very much, Marty. Certainly yourself and Russell have put together, I think, some great models, and models that organizations would do well to take a look at. A couple of comments; I want to share what I'm seeing out in the marketplace.

With regard to the bi-lateral and unilateral operability, one of the challenges that I've found is that customers really don't understand if a solution that they are being pitched or that they are expressing interest in, is a bi-lateral - where the vendors are working together - or an unilateral solution. And it would seem that it would be easy because you would ask the vendors, but what I've found is even the vendor's sales reps - they haven't been properly educated and some cases, I'm going to give the benefit of the doubt. I don't think they are trying to mislead the customer, I think they just don't really understand. So for example, like the Cisco cookie Lync integration or Avaya's Ace Lync which is the respective integrations with the Microsoft Lync product. Both of those really are unilateral integrations but depending on who you ask, you'll get different stories.

And then the API and SDK integration model, which is a very true one and certainly I'm happy to put on my developer's hat, but the thing is, they require very, very specific skillsets. So I think, Marty, you put it very well when you said the APIs and the SDKs, they can potentially allow these things to interoperate, but you've got to really find the people that have the skills. And even if you find those people and get it to work, ongoing operational support of that becomes very challenging. So really, the three interoperability lessons that I want to share from the field are, I certainly see a great desire for many, many organizations to integrate the desktop with the PSTN and the traditional voice systems.

The first option then that most customers explore, because it makes logical sense is, let's take our desktop and office apps and integrate them with the traditional PBX. The one thing that I would ask you to keep in mind is that even though that's a logical first step, that may not be the best option. Specifically it may be that this is a case whereas Marty pointed out - you don't have to integrate everything with everything. So you really have to figure out if the costs of doing it the one time and then supporting it over time, makes sense given the business benefit it's going to provide.

Secondly, I really believe that for an interoperable solution to work and to continue to work and to continue to be supported, there has to be something in it for the organization providing the interoperability. So that means either for the vendor or if you are dealing with a systems integrator, there has to be something in it for the people that are making it work. And not only must there be something in it, but they must have the capability to do so. So even though a systems integrator has the desire to make things work, that's not enough because if they don't, for example, have access to the source code. Or if they can't actually influence the product evolution, then they may have a great desire but they still might not be able to get it to work at the end of the day.

So the third lesson then becomes, always involve the fewest number of vendors possible. Define your business requirements and then obviously, as Marty pointed out, it's not often when you find one vendor that does everything. But certainly strive to use the fewest number of vendors if possible.

And unless you are really are going into it as a proof of concept, where it's just a pilot, make sure that whoever is leading the implementation, can show you ahead of time that they've gotten this to work, and even better yet, let you play with it or go talk to the organization that's using this interoperable solution ahead of time. Because otherwise you find that you are in a proof of concept mode, and that wasn't your intent. You just wanted an implementation and all of a sudden, you do a lot of R&D for multiple vendors. So those are really the three things I've learned through hardship and various projects, and with that I'll turn it back to you, Marty.

Marty Parker: Thanks, Kevin. That's really helpful commentary and it reinforces what Russell and I are saying about this. We actually had a definition of interoperability as "the minimum set of connection points of methodologies between the UC platform client, and any other system or network element necessary for the UC application to meet the user's or the business' needs." So the minimum set, this idea the mathematicians call "elegance," what's the most elegant way to get this done?, which usually is the minimum and simplest.

Now Phil Edholm has some commentary for us, and I'm sure from your architectural experience, Phil, you are going to have some great insight. Thanks.

Phil Edholm: Thanks Marty, I think this is actually a very challenging area. I think it's challenging because when we talk about interoperability, it actually covers very broad ground. I think in the presentation you did, you actually begin to really touch on that broad depth of different parts of topics.

The first thing is, I'll make the argument in the enterprise, if you think about it from a UC collaboration solution, you really have inoperability on four domains, four dimensions. The first is you have with the other user systems, user productivity tools, the video system, the voice system. You have into the IT department, how do you interoperate and integrate into the business processes, the social communication, places that store and do document management, other traditional IT applications? You have device interoperability. We now have between the devices that enterprises are buying and of course the whole BOD, there's a huge set of interoperability at that level.

And finally then, there's what I call...it's a special sub-case of interoperability, which is federation. And in federation, you have to think about three kinds of federation. There are, I'll call it for lack of a better word, your general open business federation, your tightly held federation with people who may in fact be dependent upon you, and then more general consumer customer federation.

So if you kind of look around that, there are those four - kind of call them facets or boundaries of interoperability. And in each of those you have to think about how does this solution interoperate with the things that users need it to interoperate to deliver value. And I think this is fairly complex and thought out. The area we focus on a lot, because a lot of the people involved in this come from telephony, is the telephony interoperability. And having been in that space I can tell you that it's been a real challenge. Whether you look at a system like Lync or a system like Sametime, getting those two together and I think that actually brings us more and more to a more interesting way of being able to look at interoperability in a very different way.

And I think that's where - as an industry going I think for end customers, it's actually a time to begin to think about that. A lot of the talk we have in interoperability, is how do I get two servers to talk to each other? A server that represents users doing one service and another server doing another service, how do I get those two servers to interact with each other and do the right thing? And this is where we get into are there published APIs? Can I integrate to your API? Is your API stable? I mean I agree 100 percent with some of the comments Kevin made - the unilateral, having been in a number of times in the unilateral side of things of trying to unilaterally integrate with another vendor. You use their APIs and all of a sudden a new of the products, the APIs have changed dramatically. Or potentially they've actually disappeared. And the thing your customers were dependent upon is now not there, and the way you were doing integration goes away.

So a lot of times, if you want to do interoperability like that, you have to choose lowest common denominator elements. I mean some of those people are actually looking at interoperation strictly driven around SIP, where if you're dealing with the low level SIP functionality, because it's a standard, you can't change it.

So the interesting question I think that we're beginning to see is a question that companies are asking, which is, do I really need interoperability at that level, or is interop really defined around the communication event? Interestingly enough, I was doing a panel that had both Vidtel and Blue Jeans on it at ITExpo a couple of weeks ago. The interesting thing about both of those companies and their product offers is, they have defined interoperability by including devices, and you have absolute interoperability, but only for that event, only through that system. And I think that's actually going to become a very interesting trend, in where we are as an industry and where we're going. And I think technologies like WebRTC actually begin to make this really possible. And it's the concept that says, "I don't need to worry about trying to build interoperability between server 'A' and server 'B,' because when I need to communicate with people and it's defined around server 'B' - I just connect my device to server 'B.'" Which is exactly what Vidtel and Blue Jeans will tell you is, use your video device inside your company with your company's video system. But when you want to have an outside communication with other video devices, use our service and we'll make sure that everything connects together. But it's really connecting devices together through device interoperability, and by doing that, guaranteeing inoperability during an event. And I think if we stop and think about it for a moment, this is really something that communications is beginning to do that actually follows exactly what happened in IT 20 years ago. Twenty, 25 years ago, we had servers talking to servers. Back in the late '80s and around 1990...what we were trying to do is figure out how do I have server "A" talk to server "B" because I need to get my information from me to somebody who's supported by server "B;" because we were all connected to servers.

Email is really the last real implemented technology that came out of that period because what happened was, when the browser came along, we stopped trying to have servers talk to servers. We stopped worrying about server inoperability on behalf of users. True, there's a lot of back end inoperability in servers... I'm not belittling that. But the reality is, users pointed their browser or their device where the information was that they wanted to get from.

And I think this is the interesting thing that people need to think about. If we're focusing a lot on interoperability today and it seems really, really hard - is in fact the easy way to do it what people like Vidtel and Blue Jeans and other companies are showing us - which is, don't worry about trying to get your server to interoperate with somebody else's server, just make sure that other people can come to your server when they need to communicate with your employees. And I think that begins to really change the future.

Marty Parker: Yes I agree with that, that's great insight, Phil... the neat things about these things is that they are at hand today, so if you want to talk about Vidtel, Blue Jeans - if you want to talk about Lync Federation, or you want to talk about ... let's see, what was the other federation service Russell?... the next plane for IM and presence federation. I mean these services are one of the ways the cloud can help solve problems and we definitely agree with you, Phil; figure out what problem you are trying to solve and then you can probably solve it with what's at hand today. And then it can get better in the future as you point out with WebRTC and so forth.

So with that, Russell, what would you want to add to what we've said so far as you've been listening along? Probably a couple of things you want to tweak here.

Russell Bennett: Thanks Marty, I think we've got some great insights from Kevin and from Phil. This continues to be a challenge and what started you and I down the road on this is the notion that people were delaying their UC implementation or their UC rollout because they couldn't figure out the interoperation thing.

So the question is, do we have to help people see the way forward on interoperation before we can get more general implementation? And I think this is a real challenge for people.

Admittedly, some of these things are very messy. In fact they are messy, they are not plug-and-play, in many cases. I was speaking to a CEO of a UC vendor the other week and I challenged him on the bi-lateral versus unilateral thing whereby vendor A will say they interoperate with vendor B but vendor B doesn't agree. And I said, "When do you see a time when bi-lateral interoperation is the norm?" And he said, "Frankly, I don't see a time when that will be generally available because the UC vendors do not have any incentive to solve this problem. And that what we are going to be facing is unilateral interoperation for some considerable time."

Now there is a way to resolve this. The vendors of the MTUs whether they're in the cloud or the premises, the vendors of the gateways or the enterprise session border controllers, are making headway in getting endorsements from the individual vendors for their intermediation product. So the intermediation product, no matter what it is, is a lot like the electric adapter that we all take when we're traveling. It plugs into one end and we know that works and it plugs into the other end and we know that works.

And so I think, in terms of bi-lateral interoperability, you should be looking for an intermediation solution that's got the vendor endorsement on both sides. And if you've got that, I think that's probably the best case scenario right now. And then we either have to wait for the vendors to figure out the interoperation thing, or as Phil suggests, we have to start looking to a different model for vendor-to-vendor communications. Those are my thoughts. Thanks, Marty.

Marty Parker: Great Russell, thanks a lot. So obviously we're really putting our head around this puzzle and in the transcript of this podcast, you'll see a Contact Us button, if you'd like to be in touch and talk about it further for your specific business or enterprise. And I know we've got a couple of other experts who may want to comment on this. Don Van Doren - do you want to comment upon the topic?

Don Van Doren: Yes, Marty. I think it's a really interesting issue and frankly it's heartening to see that there is some good progress being made in all of these areas. Fits and starts, two forward and one back, and all that, but I think that's something that's going to be critical as we move forward. Especially, I think, as we move away from just the sort of UC-U kind of capabilities where we're really focused on sort of personal, individual user productivity. Granted, the kind of interoperability that's necessary to extend some UC-U capabilities, say either within the domain or even outside the domain to customers and partners. I mean obviously, those are going to be important issues.

But I think the thing that I think is really going to be important in the long run, is having a good mechanism for supporting what we call UC-B, that is, the business process integrations, where you're really embedding communications within other kinds of business processes and software applications. I gather that today, most of that is being done through API kinds of approaches. Say, if you are on SalesForce, having a link back to whatever telephone or voice communication system you've got, is done in that kind of a fashion.

The point was made earlier by Kevin that API approaches are challenging. And it was also stated that you can get into trouble with vendors changing their APIs and that sort of thing from one release to another. So I guess I'd pose a question back to our group: just how do we see some of these things working from a UC-B perspective, and some of the ways that that's going to go forward?

Marty Parker: Well, that's a great question and I think the answer is, we'll see it work like most of the rest of the industry; it will be coin operated. When there's money to be made, people will build it. For example, Enabling Technologies has built a connector between Microsoft Lync and CRM Dynamics. A number of companies have built voice plug-ins for automatic dialing and inbound call management with SalesForce.com, but I think we'll see more native connections there. We see things like Microsoft building their Duet connector to SAP. I think we will see people commercializing what they learn, maybe by starting with the APIs as you mentioned, Don. But they'll figure out, "okay, now I've got a pattern, and I'm going to build that and put it up on the market."

So that's one of the ways, I think. Does anyone else have a comment on Don's question?

Phil Edholm: This is Phil, can I just make one quick comment on it?

Marty Parker: Please.

Phil Edholm: I think one thing that's very interesting, Don, to think about is, we are training people to think about communication being not tied to a single device, but being across multiple devices and more and more I think we think about our communications as being...I'll call it "device optimized." In other words, I use my phone for certain communications, I use my cell phone for certain communications. I use my PC for certain communications. And actually what's really interesting, I'm using one of the savvy Plantronics headsets, and it actually connects to my phone, my PC, and it uses Bluetooth to connect to my cell phone. So I have one headset and what becomes interesting after you use something like that, after a while you begin to realize that you're much less concerned with how a communication was instantiated, and it's just a communication. I think that actually opens up a very interesting question with CEBP, which is, will the software vendors, the Oracles, the SAPs, those vendors that build software, will they actually begin to see that the communication is something they offer from within the software?

I think one of the challenges we've always had in CEBP is we've seen it as an integration between the software vendor and the communications platform. If in fact the users are beginning to be used to and willing to use multiple communication methodologies, whether it's Skype, cell phone, desktop phone, is in fact a communication that's instantiated totally from the software application - now going to be acceptable? So in other words, my phone doesn't ring when I need to talk to Bob about something we're doing in SAP, it's actually through my computer. But it's still realized through the same headset that I use for my phone. And I think that's going to be a very interesting question for organizations because I know from past interactions with companies like Oracle, they've actually had for a number of years relatively complete, not telephony solutions, but real time communication solutions. And so I think this is going to be a very interesting question for CEBP, again, is it really about an integration, or is it about a separate communication event structure that actually happens and essentially in parallel with what we think of as normal telephony? I think that's just a very interesting consideration for companies to look at. Because as the telecom people ... that conversation with your IT compatriots, I think needs to be very in-depth around, not so much around starting with integrating technologies together, but understanding what's the experience you're going to give to the end user and how are they going to manage it? Are your users going to be comfortable with having potentially a duality of event experiences, i.e. the phone experience is different than the real-time communication for your business app? So that was just my thought.

Marty Parker: And I think people are starting, in terms of your device-centric communication, I think we're starting to see that. We've been seeing it for the last five years with apps on mobile devices. Whether it's the Blackberry experience, 10 years worth, or more recently some of the Apple experiences, many, many of the apps on my new Android phone have communication built into them, specific to the app. So that may be what happens, building on what Don said. And Kevin, I understand you have a comment on Don's comments as well.

Kevin Kieller: One of the things that I think I'm very interested to see how it plays out is, I think with Microsoft and some of the announcements, like Windows 8, what you end up with is a communication platform that already, for the past probably four or five years, there's been APIs, you could do some communication enabled business process application integration work on the desktop and now on the Windows phone and on the Windows Surface tablets and even on the Xbox, using the same code base, using very similar or the same API's. It's just that my observation is, people are still working with getting the plumbing in place, but once that happens, specifically in the Microsoft ecosystem and the growing ecosystem now that they brought in Skype and the Messenger and Xbox and Xbox Live. There's lot of pent-up platform deployment where programmers using skills that they already have, .Net and all the wonderful programming things that they've already learned... Can start to very easily - with 10-15 lines of code, communication-enable business processes for a line of business applications. And the only reason I believe that that hasn't happened yet, is because the organizations are still just - as I said - getting the plumbing in place. But I'm working with one global consulting firm that has 186,000 people using Lync worldwide. So to your point, Marty, then there's money in it when somebody says, "Hey, I'm going to build this little add-on on top of that." You start speeding up the lives of 186,000 people on a daily basis, there's some real good returns.

Marty Parker: That's right. Yes, that's exactly right, and Art Rosenberg, I think you had a few thoughts you wanted to share, too.

Art Rosenberg: Yes. It's all coming together as I had expected, the question is just how long would it take and that is, mobility, which is bringing in different kinds of devices and different kinds of multi-modal needs. is driving the needs who have things, have applications be much more flexible and as previously described, if the tools can now be developed at the application level. Think of mobile apps. What do you think they are? They are going to exploit UC all over the place. And they all have to be designed at the layer of the user interface. And this could be, thousands and thousands of different applications - rather than one big fat one that does the same thing for everybody. It's going to be personalized, it's going to be customized, and those applications have to - although they'll be easy to develop - they have to be easily managed and so on. And the experts will have to come in to do that for the end users, the end users don't do it for themselves; they just want to use the technology, they don't want to develop it, they don't want to own it, they just want to use it.

So I think what we're saying is, it's just a matter of time that we're going to see the level of interoperability and integration be taken care of by the people supplying the basic technologies so that the end users and their different devices and their different applications can benefit from using them.

Marty Parker: Great - thank you, Art, for those comments. And with that, I'll wrap this session up. It's been a great conversation, thanks to everyone for contributing. Russell and I would love to hear from you, if you want to click on the Contact Us button, and all of us would be happy to respond but Russell and I are taking the lead on this topic, so come on and ask your questions. And we will be back with some more topics in the coming weeks.