Tag Archive | "API"

A Full Carrier Lobotomy


I had the pleasure of speaking at the recently revived VON show in Miami yesterday, and had the greater pleasure of sharing the stage with Voxeo’s Dan York, where we had a conversation about the carriers and applications. I’m not sure if our moderator, Suresh Bhandarkar from Tech Mahindra, was ready for the level of (pick one: anarchy, candor, swearing) that Dan and I can whip up, and whip it up we did.  Alec Saunders was supposed to be on stage as well, but was unfortunately held up in the airport. Good thing, as I’m pretty sure he would have been the match to our gas.

During the conversation, I had yet another frontal lobe failure where the unvarnished truth all comes spilling out of me, this time documented by Khali Henderson:

Howe said he thinks the biggest issue is carriers’ mindset. “They need a lobotomy,” he said. “Carriers feel they need to bring end-to-end service and QoS, etc. But for the reasons we have been talking about they can’t do that anymore. They don’t know the end service. …They have to say, ‘We are going to care up to this point.’ And, after that, they have to stop caring.”

Let me amplify that.  I really and truly believe that a fundamental issue that stands between solving long standing problems with communications technology is simple: the wrong people are trying to do it. For me, the reasons are obvious: you can’t solve problems you can’t see, don’t know about or simply don’t care about. Solving problems is hard, and takes investment and work, and efforts often fail.  The real recipe for solving problems is this: give the people who understand and care about the problem the ability to solve it and get out of the way.  Applications are, in essence, solutions to problems.  Carriers, and by that I mean both the employees that work there and the organization they belong to, fundamentally fail in this respect: they can only understand problems that apply to people in general, not roles in particular.  For instance, a carrier can solve the problem of connecting two people to have a conversation. Every person has this problem; carrier employees are people.  A carrier has a snowball’s chance in hell of solving the problem of auditing a drug trial’s results using phone technology; medical researchers are the only ones who can express and understand the problem to a significant degree.

Hold on, you might say: you can assign a domain expert (a medical researcher) to a development team, can’t you?  Yes, of course you can – but there’s another problem.  Even though problems like this can be solved with communications, they simply don’t represent enough revenue to become interesting to any carrier, anywhere.  Even if there were enough medical researchers to make a decent addressable market, the cost of sales would be wicked (New England Yankee here).  Game over? For carriers interested in making these applications, yes.  For programmers with access to APIs… not at all.  Which is why APIs are so important for solving those small problems using communications – there’s no other economical way of addressing it.

But, why is this important to the carriers?  That’s a simple one too: if you are a person with a problem that can be solved with communications, and if your carrier doesn’t provide an API, you’ll find one that does.  This officially exists today, and a developer like me has several excellent choices for API providers.  If carriers don’t see increased revenue with APIs (and I firmly believe they will), they will see increased churn soon without them.  Either way, APIs are coming to a carrier near you.

The existence of an API provides a challenge to the long held mindset of carriers.  They started, they grew and they exist dedicated to providing services to end customers, both business and consumers, and guaranteeing their proper operation.  When carriers expose the core of their networks through APIs, a very scary proposition to anybody in the carrier, they lose the ability to guarantee QOS, functionality, stability… In short, everything that they used to guarantee.  That’s why they need a lobotomy, because that mind set will forever keep them from providing the tools that problem solvers need.

But hey, as they say, I’d rather have a full bottle in front of me than a full frontal lobotomy.  Alec, what do you say? Doing anything tonight? Dan and I will be waiting at the bar.

Posted in Lead StoriesComments (6)

Verizon and Open APIs


At today’s VON show in Miami, I had the chance to question key note speaker Fred Briggs of Verizon on their plans to open up APIs into their network.  Unlike most large carrier speakers, I really enjoyed hearing him.  During his talk, Fred mentioned two aspects of Verizon’s forward looking business plans: Unified Communications and Communications Enabled Business Process (CEBP).  Needless to say, I was quite excited to hear that Verizon could spell CEBP, never mind that they would even talk about it on a stage.  As you might recall, Verizon announced over the summer that they were offering a new computing as a service offering (which, although flawed in the practice, was excellent in theory). I thought to myself, “Wait! Maybe they’re going to open up the APIs to the core too!”  Anyone involved in the CEBP game knows that an API to the core services was fundamental to success. Period.   But for Verizon? Ummmm, not so much.

Well, what Fred said was that Verizon was making a commitment to open up it’s network with API access, but that there were equipment issues that might cause delays. (Alex Doyle from Broadsoft was in the audience, and I wish I had taken the opportunity to ask Verizon to commit to further purchases of Broadsoft equipment simply to hurry their API efforts along.  A missed opportunity.)  When I mentioned that Deustche Telekom, BT and Orange all had open API efforts and that Verizon was lagging behind them, Fred took some exception to that. I had to run back to my computer to double check the meaning of “lag”.

Did Verizon say that they were going to open up their core APIs? Yup. When I asked for a schedule of when that might happen… well, I’m still waiting.  And so is every other over-the-top and Telco 2.0 developer.   I think Don Thorson of Ribbit is right – in the near future of OTT telephony, there’s two sorts of carriers – the quick and the dead.

Posted in Lead StoriesComments (1)


Twitter

    Got an idea?

    If you have an idea on how to improve how businesses are run using communications, have a nifty product or service, Tell us about it!