“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. 🙂
What about your old employer stupid? Now that you are no longer bound by the limits of employee and employer relationship – i was hoping you would be as frank and honest about Mitel as you are about everyone else. Or did they pay you something to remove them from your blogs?
I was in a youth group planning session at our church yesterday, and the big question was how to keep the kids ‘in the loop’ on activities and events we plan, as well as how to guage interest in order to estimate attendance. Not one single attendee suggested that we call the kids or their parents, or even collect phone numbers. Instead, the conversation was about solutions such as leveraging Facebook, or building a special-purpose community network within a hosted social networking site. From a high level, our ‘administative’ community needs to interact with the ‘user’ community, but not from within it. I suspect the APIs you talk about will evolve to support community-to-community interactions. VoIP Peering marks the beginning of this in the IP-PBX space, but richer “audio-free interactions” (AFIs) are clearly in demand.
voipstutter – Do you need to be so hostile in your comments? I will be as frank and honest about Mitel as I am with any other vendor when the situation warrants. In this case you’ll note that I was focusing on the companies and others who are leading in the area of providing APIs and a platform for communication. Mitel’s been one of the leaders in connecting *into* Microsoft’s platform and they have a third-party developer program ( http://www.mitel.com/DocController?documentId=9971 ) but they have not yet moved to provide the level of *easy* API access that others have. They will, I am sure, but given that they haven’t yet I didn’t see the need to list them. When there are reasons to write about Mitel, I look forward to doing so.
Do you see a P2P app like Google Talk taking on these boxed systems? Look at all the functionality Google could put into their client and IT doesn’t even have to install a server.
This is similar to the way of Office apps. Online vs desktop. Do you see a Google Talk blowing away Microsoft’s OCS boxed app.
Good question for a book 🙂 I’ll say this, though. I’m more interested in the long term disruptive potential of GrandCentral+GoogleTalk, combined with and surrounded by Google’s group & personal services, all exposed to web developers thru wide open APIs. The prime disruption isn’t in P2P voice features, or in desktop integration. I think the disruption comes out of Google’s server-side APIs, and the new kinds of APIs they can wrap around Grand Central.
I certainly did not mean to come across as hostile. Thanks for the response. On Asterisk I’ve seen a nice screen pop solution that looks up the callerid on google to provide a name rather than number. Very clever. It would take a lot of work to provide something like that on a Mitel.
Supposedly there is more of an API available on the Mitel 53×0 phones – but this is a fairly expensive ticket to get a fairly limited API.
To both Ricks – I actually meant to include Google in my list because they are all about open APIs and yes, with GrandCentral and their connections into the PSTN they provide some interesting disruption into the space.
To voipstutter, yes, there are those add-ons to Asterisk that do that. Yes, there is an “HTML toolkit” for the Mitel 53×0 phones that lets you develop all sorts of HTML-based screens for those phones which could drive various apps. You really need to contact the Mitel folks for more info on those.
Thanks, Dan, for understanding the true promise of VoIP. Every time I hear someone suggest that an IT department separate their VoIP network from their data network I want to slap them for not “getting it.” Next month I’ll be again giving my VoIP Attacks presentation at CSI 2007, and one of the big points of that talk is that separation stifles the potential value you are getting from using internet telephony. If you haven’t read any conference notes from ToorCon 9 this past weekend, some things you may be interested in which relate directly to this subject are both the VoIPHopper tool (now on the VoIPSA Tools list for your convenience) and Dan Kaminsky’s latest research on using the browser as a network proxy to attack intranets or otherwise disparate networks. Combine Kaminsky’s research with the recent developments in IP Phone Cross-Site-Scripting and SQL injection, and you’ll understand why it’s extremely relevant. You can find my write-up about ToorCon at my personal blog.
PING:
TITLE: It’s about the platform – Google finally answers t…
BLOG NAME: gphone
Bookmarked your post over at Blog Bookmarker.com!