The 500 Features of Dr. PBXThe 500 Features of Dr. PBX

In the next-gen world of software-driven communications, a feature becomes an API and a platform's value is derived from its ability to integrate with lots of things.

(For non-Dr. Seuss nerds, title explained here)

Over the past few weeks, the Enterprise Connect/No Jitter content team has been trying to figure out how the emerging developments regarding software, platforms, APIs, cloud and collaboration and shake out for the enterprise. (Once we get that done, we'll move on to curing cancer and explaining how Justin Bieber got famous.) I'll say right up front that I think this is futures kind of stuff--but I do think it's a future that we need to understand.

Maybe this is an oversimplification, but Enterprise Connect GM/No Jitter Publisher Fred Knight and I were kicking around this analogy:

The mantra in the PBX world was always "500 features"--every PBX had 500 features, and each vendor had to have them all, because somebody somewhere wanted each of them. Because the PBX was a static hardware platform, you had to give all 500 features to all your customers. What's more, you could never take away a feature.

What if, when we talk about a "feature" in next-gen software-driven communications, the functional equivalent from a development and deployment perspective is an API? For one thing, the job of a communications vendor then becomes to build a platform--probably residing in the cloud--whose value is derived from how many other things with which it integrates.

This notion came up in a discussion I had with Matthew Cutler, director of customer development and strategy for Cisco, at last week's Cisco Collaboration Summit 2014. We were discussing the longer-term vision for the just-announced Project Squared, and the fact that there's currently one announced integration partner for the Cisco Collaboration Cloud that supports Squared. That partner is Box, and that partnership provides Squared with... a feature. The feature is the ability to see content--especially large, unwieldy files like a presentation--in line within the Squared interface, rather than having to download the file to your device.

So it makes sense that the next step is for Cisco to create a multitude of relationships similar to the Box partnership, with the aim of finding the partners that can help enable a multitude of features. Then someone--maybe an enterprise architect, maybe a VAR, SI, or other partner--composes a service for the enterprise drawing upon just the elements needed for what the service needs to do. And maybe this composer crafts one service for one department or division, and a different service for a department with different needs, etc. It's as if, in the old days, you could implement a different PBX for each department, with only the functionality that department needed, plus a whole lot more functionality that your particular PBX couldn't provide but maybe another vendor's could.

The vendor in this scenario does what Cisco had been talking about last week when it talked about Project Squared: It provides the security, the integration capability and maybe some standard set of baseline features and functions.

To me, this all makes a satisfying story. What I don't know is whether it actually matches up with a way that enterprises will ever want (or be able) to deploy communications and collaboration. I don't know how we get from here--PBX world--to there--software communications/collaboration world. But I think the conversation is starting, and we'll be carrying it on at Enterprise Connect Orlando next March.

Follow Eric Krapf and No Jitter on Twitter and Google+!
@nojitter
@EricHKrapf
Eric Krapf on Google+