UC Interoperability and Standards, Who Needs Them?!UC Interoperability and Standards, Who Needs Them?!

A robust "communications middleware" market is a more likely direction for this industry than interoperability.

Over my three days at Enterprise Connect this year and throughout past VoiceCons, one of the big themes that always seems to come up in every conversation, panel and speech is the need for interoperability and standards. The thought being that once we have interoperability and standards all of our unified communications systems will work harmoniously together and we will have an almost "plug and play" like environment. Sounds great? Well I say bollocks to that!

Not that this isn't a nice vision, but it's just not realistic. When has that ever happened in any market ever? Also, if we actually had that, much of the value would be commoditized and innovation would slow down as all solution providers would be following the same path.

So if standards and interoperability aren't meant to be, does this mean that we’re destined to always struggle to get our unified communications solutions to work together and things like CUCIMOC (shouldn’t this be CUCI-Lync now?) are more the norm than the exception? Well, not necessarily. And to get an idea of how the industry could go, let's look at the computing world.

In the "old days" we had things called mainframes. These were integrated systems with all the applications residing on them and the terminals were connected with dedicated cables. Hmm, seems like a PBX. Decades later, we haven’t managed to create a world where we have applications that are fully interoperable and standardized so that everything works together perfectly. Despite efforts years ago to move that way, the market didn't really evolve in that direction.

Instead, what we have is a big mix of stuff. An enterprise could have, say, two internal development platforms such as java and .NET. They could also be using a mix of cloud based applications and some departmental applications that are standalone in nature. What helps create efficiencies across these applications is an underlying services layer for things that are common across applications. This could be things like directory services, identity or authentication. Some vendors choose to use these where it makes sense and others do not, and it's up to the enterprise to determine whether this works for them or not.

Do these application silos mean that the applications can't talk to each other and pass information between each other? Of course not. What does this though isn’t "standards and interoperability" but something called middleware. Middleware is a layer that sits above the applications and is able to abstract common information up, translate it and pass it back and forth between the applications. All information isn't abstracted up to the middleware, only the information that’s required. This allows applications to live in silos but still allows organizations to have the necessary interactions between the applications to get business done.

Now, this path wasn’t easy. The middleware market wasn't invented the day after client server computing was. It's been a long march to get to where are now but it did evolve that way. In fact, initially the industry spent a lot of energy trying to make PCs look like mainframes with things like 3270 emulators. We did a similar thing with VoIP. Initially we spent a lot of energy, maybe too much energy, trying to make IP look and act like TDM. It's only recently that we started re-architecting our voice networks to be more IP oriented and using things like SIP trunking to extend the value of IP as far as possible. So, just like in the computing world where it took the better part of a decade for the middleware market to start to develop, we can expect a similar timeline for communications and, in fact we do have some niche examples of "communications middleware" today.

Avaya's ACE suite of software allows Avaya Aura to interoperate with non Avaya systems and end points. IBM’s Sametime Unified Telephony creates an abstraction layer above the voice layer to allow for vendor interoperability. Acme Packet can translate between different versions of SIP in the network, acting almost like a SIP "rosetta stone" for communication service providers. VOSS is a great example of a vendor that allows for hosted voice providers to easily migrate dial plans and other provisioning tasks relatively easily as they move customers from TDM to IP.

The "communications middleware" market is certainly in its infancy today but there are enough examples of it to make me believe that this is a more likely direction for this industry than creating a set of universal set of standards that will allow for full interoperability. Perhaps this will be a bigger focus of future Enterprise Connect conferences? Stay tuned!