Are you going to Enterprise Connect this year? I am, and not only do I look forward to attending breakouts, listening to the keynote speakers, perusing the vendor show, and hanging out with my communications peers, I am excited to be moderating a session on interoperability (Interoperability: Has Anything Actually Worked).
Interoperability is something I deal with every single day of my working life. Just today I spent a significant amount of time researching which session border controllers successfully interoperate with which call recorders. While it might seem like a fairly straightforward task, this level of detail is rarely found in marketing brochures or product bulletins. You have to make phone calls, send emails, and call in favors to get the straight scoop. Even then, one man's definition of "interoperate" isn't necessarily mine.
Levels of Interoperability
Interoperability is many things, and I look for it at a number of different levels.
At the lowest level, I define it as not breaking the other guy. Technically, this is really more compatibility, but sometimes all you really need is two products to play nice with each other. You don't hurt me, and I won't hurt you.
Higher up the food chain, I want to be able to send information between two devices or systems and have that information be properly acted upon. For example, an Avaya system supports SIP, and Polycom makes SIP telephones. Interoperability at this level means that a Polycom SIP telephone can connect to that Avaya system and a user can make and receive calls.
Moving even higher up, I look for feature parity. For instance, a Polycom SIP telephone can successfully connect to an Avaya system, but it doesn't deliver the same feature set that a comparable Avaya telephone will on the same system. That's because the firmware in an Avaya SIP telephone does things that are outside the expected behavior of a "standards-based" SIP telephone. That doesn't make the Avaya telephone better or worse than the Polycom set, but it is a factor in the level of feature parity you can expect from third-party products.
I love having a single management interface to configure and maintain a communications system, and interoperability plays a role here, too. Some components play nice together as well as speak to each other, but have nothing in common when it comes to setting them up. This divide leads to complicated work flows, errors, wasted time, and unhappy users.
Web services plays a huge role in interoperability. While this often requires custom programming and is rarely an out-of-the-box installation, a good Web services interface can be used to blend together two outwardly dissimilar products from competing vendors.
Interoperability can also be one system telling another system that something is wrong. While all too often overlooked when making product decisions, I always ask a vendor about the SNMP MIBs (Simple Network Management Protocol Management Information Blocks) its product supports. These MIBs are integrated into management tools that can be used by the customer, a managed service provider, or both to identify, troubleshoot, and resolve problems. The more complete the definitions, the better the information gathered and ultimately acted up.
New technologies bring a unique set of interoperability challenges. Sometimes the challenge lies in bridging the divide between new and legacy, but it can also be a factor between different forms of new.
WebRTC is the poster child for the latest upheaval in communications. Not only are enterprises working on integrating WebRTC into their existing call flows, but they are struggling with integrating a WebRTC solution from one vendor with a WebRTC solution from another vendor. Both the newness of the technology and the still solidifying standard keep life interesting for everyone involved.
Standards Rarely Are
Just because something says it follows a standard doesn't mean that it can interoperate with a product that claims to follow the very same standard. Avaya SIP is different from Cisco SIP, which is different from Microsoft SIP. Sometimes the differences are significant while in other cases they are simply annoying.
Interoperability sometimes requires a "man in the middle" to fix things up. Session border controllers are often used for this task. SBCs support an adaptation layer that makes the SIP from one vendor look like the SIP from another vendor. This fools everyone into thinking they are talking to their own kind.
Please Come to Orlando
If this is the kind of talk that excites you (and why shouldn't it?), make time on your Enterprise Connect calendar to attend my session. Yes, it is 8:00 in the morning on the last day of the conference, but I promise you an hour of lively discussion, horror stories (hopefully not too many), and advice on how to make all the piece parts of your systems play nice with one another.
Trust me, you don't want to bring me in after things go south.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Register for Enterprise Connect Orlando 2015 with code NJSPEAKER to get $300 off Entire Event or Tue – Thu pass.
