UCStrategies Experts Debate UC Interoperation

26 Oct 2010
0

Interoperation and interoperability in unified communications was the topic at two recent industry shows in which UCStrategies experts led panel discussions. Today's podcast focuses on this topic, and asks the UC Experts questions specifically regarding slides 10 and 11 from Marty Parker's presentation at InterOp NY. Slides 10 and 11 are shown below; download the entire presentation here.

The expert panel includes Marty Parker, David Yedwab, Russell Bennett, Don Van Doren, Nancy Jamison, Steve Leaden, and Dave Michels.

UCStrategies encourages your comments on this podcast. Please see the "Comments" section at the bottom of this page to contribute.

Slide 10

InterOp NY Slide 10

Slide 11

InterOp NY Slide 11

Slide 3

InterOp NY Slide 3

Marty Parker: Hello everyone, and welcome to our weekly UCStrategies podcast. My name is Marty Parker and I'll be the moderator for today. Today we want to talk about the topic of interoperability or interoperation. There have been two panels, one at InterOp NY last week, which I moderated, and one about three weeks ago at ITExpo, moderated by David Yedwab on this very topic, and so we thought we would ask the UC experts to comment on the topic of interoperability in the context of those presentations, those panels. I will be posting the presentation from InterOp NY on this topic and it basically opens up with the definition of unified communications and leads to slides 10 and 11.

When you look at the slides, you will see slide 10 and 11 describing key points of UC interoperation, describing them as "relatively easy," to "moderately difficult," to "complex." So for example, in the Easy category it's UC or an IP-PBX link to a legacy PBX, audio conferencing, publishing and sharing UC clients to partners and the public.

In the Moderate category we move on to instant messaging and presence, federation between enterprises, and communications enabled business processes. And in the more Complex category, in the InterOp panel we categorized as most video interoperation, because there is such a large installed base of H.323 video in a world that's now moving to H.264, and complexity with mobile device applications because the mobile device makers have so many uniquenesses to their products and not every vendor can integrate to every device. If you are trying to put applications on the devices, it's even more complex. So, we described that range - you can read the list for yourself in parallel with hearing this podcast. What we would like to do amongst the UCStrategies experts today is ask them:

  • what are your comments on the points of interoperation?
  • what are your specific views on the list that I just described?
  • which of these parts of the interoperation do you think deserves the most attention, whether from the vendors or from the enterprises who are implementing things?
  • what should be done about that thing that you think is most important?

So before we move on to hearing the experts' commentary, I told you about InterOp NY, and David Yedwab is going to add a few points about the panel he moderated at ITExpo. David?

David Yedwab: Thank you, Marty. As Marty said, three weeks ago now, we had a very interesting panel with three of the leading vendors in the industry who all happen to be in the upper right or leader's quadrant of Gartner's Magic Quadrant for UC, that's Cisco, Avaya, and Microsoft. And the interesting point to me - or the most interesting point to me - is all three of these vendors were really speaking about interoperability by design. Interoperability pre the deployment, so that the user doesn't have to worry about the interoperation, that the interoperation, the application if you will, the UC capability works out of a box, as opposed to it having to be integrated on-site by the user or the user's VAR or the user's systems integrator or a combination of the vendors. And I believe that's absolutely true going forward. However, we have to remember that within our enterprises, there's an awful lot of embedded technology that may or may not fit the interoperability by design standards, and how far back in terms of legacy solutions are the vendors going to go in creating that interoperability?

Certainly one of the major things that also came out in this discussion, was the number of industry players focusing on interoperability and the UC Interoperability Forum that Microsoft was a member of, and unfortunately Cisco and Avaya have yet to choose to join, but several of the other major vendors and piece part vendors are already participating across the board, all from the traditional telephony side of the house, as well as desktop, as well as emerging and video technologies. Clearly we are going to be seeing more inoperability by design, but I believe the user also has to worry about inoperability around embedded. And I think we're going to have to do something about that and maybe that really gets into the difficult side of Marty's evaluation of easy, complex, and more difficult. More thoughts later if it makes sense, and I will pass it on to Russell for his comments.

Russell Bennett: Thanks, David. I recently was working at Microsoft, where for three years I ran the open interoperability program, so I can probably talk all day about this, but I will try and keep it brief. I think the key point that David already made is that if interoperability is going to work it's going to be interoperability by design. I don't have a lot of confidence and I've seen a lot of poorly implemented solutions onsite and those are very expensive for customers.

The challenge to interoperability by design is many fold. Let me start by articulating a couple of them. One of them is that the standards, while there are many and various standards that people can implement and think that they get automatic interoperability, the standards in a lot of places are quite vague. We're talking about what's recommended, what you should do, what you must do, what you may do, so this creates a lot of confusion. A lot of people interpret the standards differently and then when they try to make their standards-based stuff work with somebody else's standards-based stuff, unsurprisingly it doesn't actually work that well. And so a lot of engineering has got to go into making things interoperate. The key for customers, in my opinion, is asking your vendors if their stuff does interoperate and if it has been tested with the other vendors' equipment and if the vendor will certify and more importantly support the integration and interoperability of those pieces of equipment. If they are unwilling to certify and support the interoperability, then chances are it's some kind of paper interoperability exercise that they did and not actually rigorous testing.

The other thing that I should mention about interoperability is that what call full mesh interoperability, in other words A interops with B and C and D, and B interops with C, D, and A, and so on and so forth...is very difficult and very expensive. These are one-on-one interoperability exercises that have got to be conducted in the full mesh manner across all the various different partners that work with each other. And this is actually reaching the limits of its scalability. If we say for the sake of argument there are 20 or 30 vendors who might reasonably work together in the UC business and that is a very large number of interoperability tests that are going to be conducted and then they have to be re-conducted every time somebody puts out a new release to their equipment. So the only way forward in my opinion, is as David mentioned, the UCIF-the UC Interoperability Forum and the creation of multilateral standards. In other words, everybody taking a look at the standards that already exist and agreeing beforehand which parts of which standard and which interpretation of each standard is actually going to become the interoperability profile. And only by people doing a one-to-one mapping of their interop to a centrally agreed profile, will 30 or so vendors be able to interoperate together.

Like I say, I could probably talk for hours and hours and hours about interop and I've got many years of battle scars on the subject. So, if anybody wants to come back to me later they can. Thanks. Handing off to Don Van Doren.

Don Van Doren: Thanks, Russell. I think your points about having a robust interoperability forum is absolutely right on target and very key. I will say that today we have seen that not all the vendors have joined. I am quite hopeful that that is going to get resolved soon, and then we will see some of the other major players participate in this. I agree with you, Russell, I think it's a very important step forward. But in the meantime, what do enterprises do and how do they address these kinds of issues?

I think it's clear that there are some of these interoperability issues that are more challenging than others right now. There are certainly vendors and not only the suppliers themselves, but also the systems integrators and the partners that are perfectly willing to do some of these kinds of integrations in their operation. It's not a wonderful solution. But in the short-term, perhaps it's a way that's important, IF it's an important enough opportunity. And I think that's really the key. What's important here is that the enterprises really look to understand their use cases for unified communications. Understand where they are going to receive value. Look for places where there can be high value delivered because of the changes that unified communications can introduce. Look for places that are high volume, situations where many, many transactions can be benefited, even if a little bit. And in those kinds of situations it's worth the difficulty or the challenges to go ahead and work on some of these kinds of interoperability issues.

I think that what's key here is, as I say, start with the use cases and then really understand what the risks are, what the high value items are, what the high volume items are, and basically put together a roadmap as to where you are going to get the most benefit. Having a roadmap like that will then allow you to stage these and put them out over time. Because I think it's very clear - and this is certainly building on what Russell said - over time we are going to get more and more of these interoperability standards in place, more of the interoperability testing through things like the UCIF. And so therefore, over time, these things will become easier. So balancing these various factors, use cases, value and volume, risk, and degree of difficulty, and the money that is going to come out of these things, the benefits that the enterprise will realize, that's the way forward, I think. And something that I think all enterprises should be looking at and planning for now. Nancy Jamison, what do you have to say about this?

Nancy Jamison: You said a lot of what I would have said and mine's going to sound a little bit lame in comparison because I was just looking at the slide and I think that this slide is a good one for people in general to look at, because it really puts it all in one place. You said you can lay everything out and do a roadmap, look at the value, do your use cases, but when you look at a slide like this and you see, let's lay those use cases against how difficult it would be. And then cost out how much it is going to cost you if you want to add one of these things first in front of something else. Sort of bringing out all of this issue of how difficult it is, and not, will really help them do that roadmap. If you look at this slide and we're talking about, for example; video desktop clients and integrating them with video conferencing rooms, the more that we use video and the more prevalent it becomes, the more people are going to be wanting to do the desktop in conjunction with the big telepresence-type of rooms and that may not be easy. So then they have to weigh it against the value of how many people in their organization are actually going to be doing that. How much use is going to occur in video, and if it's difficult, then put that farther down the roadmap. Steve, do you have anything to add to that?

Steve Leaden: Yes, I do Nancy, thanks. I am going to take actually sort of the opposite approach, and Marty, I have to commend you on your slides. They really get you to think about the whole interoperability subject at large. There's a couple of things that I am seeing at the macro level that might affect interoperability and may actually maybe even deviate away from it. For example, audio conferencing, which is an easy area for interoperability, also has the fastest return on investment, so therefore would you look at interoperability over a quick ROI with a total replacement of maybe a more proprietary solution we don't know?

There are also a couple of things such as unified messaging and follow-me features that I find that are pretty to very easy to implement, which can be the introduction for UC in a new implementation. The other thing I am seeing also, is this big push by all the manufacturers for this layering technology using Avaya Aura as an example here, but all of the manufacturers from Cisco to Mitel to Siemens to ShoreTel, and NEC and the rest, including Aastra, all offer this kind of layering technology and therefore you can introduce UC for the company literally worldwide, globally, or domestically and introducing UC as an add-on into this layer. I am seeing that as well.

So, what it really comes down to, I think, and I think here's my last point and again it focuses on the cost - but interestingly interoperability has always been a huge issue in the legacy PBX market for dial plans and centralized voice mail versus de-centralized voice mail - it's always been an issue. But then again, UC at the per-person capital cost is nowhere near the cost of a legacy, so therefore its interoperability is more important than potentially just looking at a system from scratch at the price point with the potential ROI that surrounds it. So, again not to say that interoperability is not important, but I think again - I think the most obvious one that Marty has here on his second slide - is the video conferencing which is a lot of legacy H.323 systems that are out there and they are now being modified to a more SIP-based kind of technology. I think that's probably where the biggest investment is for interoperability. Marty, I will turn the microphone back to you here and we can continue.

Dave Michels: I very much agree with what Steve just said, and I think that analog is interoperable, but it's a hundred years old. Digital phones never became interoperable other than T1's. SIP-we're just getting to a level playing field and video is in the first innings of a long game. I think that interoperability is important, it's a nice academic subject matter, but if you really - the cost of systems are getting cheaper and if you want a complete comprehensive solution you have to go get a complete comprehensive solution from a handful of vendors, OR, go with best-of-breed solutions and accept the interoperability compromises. It's amazing how far we've come, but I think it's mostly an academic point when it's used as an excuse for not getting unified communications out the way they should be deployed.

Don Van Doren: Dave, this is Don Van Doren. Let me just comment on some of that. It seems to me that you're correct if you are talking about the kind UC-U implementations where you have a number of capabilities that are all focused on that individual user. But increasingly what we're seeing in our consulting practice is really interesting CEBP UC-B kinds of implementations - unified communications for business processes, where you are not just talking about integrations between different kinds of communications components all residing inside of interactive intelligence or something. But rather, we are looking at how different end points, maybe some are purpose-built for a particular application, need to tie in to the telephony systems, need to tie in with a business application software. So, those kinds of integrations are the kinds of places where you will need the interoperability, and by the way, those are the things that in our experience provide a much stronger and a much greater rate of return for the investment.

Dave Michels: Don, I vehemently really agree with you. There is no conflict there, it's just that I don't expect the vendors to make that an off-the-shelf solution. I think that if I want to have some communications enablement to a number of business processes, it might require me to do a little heavy lifting and it might require me to do a little bit of customization. And I don't expect anything else.

Don Van Doren: Well, that's fine. The whole point is that I think this is going to get a lot easier, too. Again, look at call centers today. We have products that are coming from very different vendors that are getting integrated to provide seamless kinds of operations. And we are going to do the same thing here in UC.

Marty Parker: So, thank you very much, it's great debate. This distinction that we have been discussing came up in the panel discussion where there was some distinction made between those vendors that are trying to provide the entire vertical stack in their brand, versus those whose primary commitment is to working with best-in-class standards in an ecosystem, and you can see both patterns out there in the marketplace. You can see that on the panel at InterOp we had a broad range of vendors: Microsoft, IBM, Siemens, NET, who makes gateways, Polycom, who doesn't make a PBX or voice switch, they basically are making best in class audio and video endpoints and conferencing systems. And we have Research in Motion representing the mobile endpoints; one example of the mobile endpoints. So it was quite a discussion about the open ecosystem model versus the vertical proprietary branded model and what those meant to a customer.

Thank you for the commentary about looking at packaged solutions. Thank you all for bringing this out. Thanks for your comments, Don and Nancy, about how the customers and I think Steve mentioned this as well - customers can basically look at what they are trying to do, look at these kinds of tables, and understand which points of interoperability will be a problem or will be included, I should say, in their intended solution and determine how much they will have to budget and invest in making sure that interoperability meets their needs.

So with that, thanks again for attending and listening to our weekly UCStrategies podcast and we wish you all great success in unified communications.

Comments

There are currently no comments on this article.

You must be a registered user to make comments

Related Vendors