Disruptive Telephony

"Phone systems" are dead. PBXs are dead. IP-PBXs are dead.

Well, okay, not really... people will still be buying "PBXs" for quite some time. Just as there are certain communities out there who still buy horse-drawn wagons. But the reality is this:

"Phone systems", PBXs and IP-PBXs without easy application programming interfaces (APIs) are a dead branch on the evolutionary tree.

The future of communication belongs to mashups. To quick and easy ways to interconnect disparate systems. To integration of communication systems with business processes and other applications. In a world where voice is no longer always the primary mode of communication, we have to stop thinking about "phone systems" and take a larger look at how "communication" in general fits into our infrastructure. More than just how we use the system, we have to look at how we can get data in and out of the communication system. To borrow from the 1992 Clinton campaign:

It's the platform, stupid!

As you look at communication choices, the question is really about who has the "best" APIs... whose system is easiest to integrate with.... who lets you get data out of their system easily - and also lets the data back in... who lets you control the communication experience through an external application (and does so securely, naturally).

There's a good number of players out there who "get it", and either have or are in the process of developing a strong ecosystem of application partners, but let's take a quick spin down the list of some of them:

• Microsoft - Duh! Everything about Office Communication Server and all the other components is all a platform play. The goal is integration of communication into the rest of your IT infrastructure (which they would of course like to have you run entirely on Microsoft products).
• IBM - They don't usually get as much mention as Microsoft, but IBM's been back there making Sametime a communication platform play similar to OCS (only it has been out there for several years). With their latest move to OEM components from Siemens to make their Universal Telephony Server to allow interconnection with many different IP-PBXs, they very clearly see the value in integration.
• Digium/Asterisk - The name Asterisk also refers to the "*" wildcard character which in UNIX-land basically means it will match on everything. Asterisk has always been about being a platform for telephony/communication from its very beginnings.
• Skype - With its "Extras" gallery and the developer program they have been working to promote, Skype is trying to be an applications platform and currently does have many applications now available (use the "Do More" link to get to the Extras Gallery).
• Oracle - They don't get as much coverage, but I would watch what the folks at Oracle are doing, because they are building communication solutions that move around Oracle's database solutions.
• Social networking sites - Facebook and MySpace don't immediately come to mind as "communication" choices, but the reality is that they are becoming that - and they both understand the need and value in an API ecosystem. How well they will execute remains to the be seen.
• The IP-PBX vendors... to a degree - I hesitate on this one a bit. Some of the vendors get this. Avaya has been running around with their SOA toolkit. Siemens has been doing a good bit of work in this space (so much so that IBM OEM'd product from them). Cisco has been running around buying up companies. But at least to me it seems to be somewhat half-hearted. For the others I've listed, communication is a platform, while for the vendors it seems to be something else they need to do. It's a different mindset which, I think, reflects the IT focus of the ones I've listed previously.

There are certainly others out there ... and more will undoubtedly enter the space in the time ahead. The key question I think we all in general need to be asking:

How well does your communication system provide a platform for applications? (or for integration with applications?)

P.S. And yes, my new employer is one of those who understands this... although ironically I wrote the draft of this entry about 3 weeks ago before I'd even heard of them... but more on that later today. :-)