Telruptive

Offerings like OpenVBX, Invox, fonYou, Ring Central, etc. are all hybrid cloud solutions whereby the power of IP and the Cloud is combined with traditional back-office integrations.

These should be a clear low-hanging fruit for operators. Extra revenue from existing infrastructure, often via revenue sharing instead of CAPEX. What more do you want?

The ideal cloud-based telephony system?

Although the aforementioned cloud telephony solutions are all great products, they seem generation 1.0 of Cloud Telephony. What is still missing?

First of all an integration of different aspects would be a first step: OpenVBX has a great plug-in mechanism, Invox a very powerfull drag-and-drop UI, fonYou an easy-to-use consumer focused feature set and Ring Central the same but enterprise-focused. Why not combine this?

Developers should be able to create plug-ins and have open APIs available, like OpenVBX/Twilio. Advanced users should be able to use an Invox-style drag-and-drop UI to create their own services. They should be able to choose from plug-ins that are provided by an open market of developers. Basic applications should be ready to use by end-users (consumer & business) however these applications should have extension points to allow OpenVBX and Invox type-of-extensions to be added. An example would be voicemail whereby custom extensions could create totally new experiences (e.g. update a CRM, write on a Facebook wall, etc.). Ideally there is also an application developer front-end that allows to create applications based on OpenVBX and Invox type-of-extensions and put an easy to use GUI on it. These new applications could then form part of a marketplace from which end-users (consumers & business) can choose. Small extra subscription fees allow for developers and advanced users to get a revenue share to compensate for their work and to attract innovation.

Step two would be to add more and more non-telecom aspects: social network integration, gamification aspects (who is the top communicator among your circle of friends) or even pure telephone games, machine learning aspects both for voice transcription (record your calls, transcribe them and have people correct mistakes and as such teach the system) and as well as other aspects (assign new contacts to groups automatically), etc. 

Step three would be to use more advanced telecom assets, e.g. custom numbering plans and custom VPN (set-up special numbering schema for my family or friends), assign and group numbers (unified experience for my business mobile, personal mobile and home phone), anonymously or via oauth share my call list with others (mobile social graph type of applications) as well as my device and location, etc.

The Big Data elephant just got a well-connected Giraff friend. Putting it differently, Yahoo and LinkedIn have open sourced scalable social graph software. If Hadoop was the Open Source version of the Google File System and HBase the Bigtable version, now it is time for an Open Source version of Google’s Pregel: Giraph.

In Open Source Social Graph Software Not Ready Yet I complained about the social graph not being ready. Giraph should change this.

So why is this important for operators?

Any service that wants to “be social” needs a social graph solution. A social graph links the Twitter followers, the LinkedIn colleagues, the Facebook friends, etc. For operators a mobile social graph can link callers. Who calls who, who influences who, who is going to churn with whom, who might also appreciate this marketing campaign, who should definitely know about this new service, etc.?

The “Hello World” example of Giraph is Google’s Pagerank. Pagerank is the power of Google search and now it is available to everybody that has millions of users. Be sure to  keep an eye on this Giraph because the “Apache Zoo” just acquired a new important animal in its Big Data Analytics department…

If you haven’t heart of GiffGaff, here is an intro video:

GiffGaff is probably the most innovative solution that I have seen in months that has come from an established provider (Telefonica / O2). It uses the community and social networks for support (socialCRM), sales and marketing. By doing so it saves costs and offers this in price reductions, prepaid discounts and hard cash back to its subscribers.

The idea is great and it really uses the latest social networks. Unfortunately GiffGaff is (still) limited to prepaid and pure telecom services (SMS, calls & data). It would be great if they could offer also long tail services.

UPDATE: There is a new social graph player that implements Pregel on Hadoop: Giraph

Lately there is a lot of talk going on about graph databases and its main applications for things like social graphs. Google’s Pregel and the bulk synchronous parallel model are also important hints. Building on the mobile social graph idea, I am evaluating different graph databases. For revenue sharing engagements, cost is critical. As such real “open source” solutions are preferable over expensive licenses.

What open source graph databases are available?

• Neo4J
• Sones
• OrientDB
• Infogrid
• Hypergraph
• Hama
• FlockDB
• etc.

On paper the most promising one was Neo4J. After making some tests with it, I discovered however a quite important limitation: There is no remote thread-safe API. This means that when making a multi-threaded solution you run into problems when updating relationships between nodes. Under stress you are likely to want to update a relationship while another thread has a lock and as such you run into problems.

Sones has a very restrictive open source version, so not really useful.

OrientDB looks very promising for some applications but is not really build to execute complex graph algorithms like large scale pagerank.

Infogrid is extremely complex with a lot of individual components that are all in different stages of development. However there are some promising aspects.

Hama is one of the most promising technology-wise but until you can actually store data in Hadoop and quickly manipulate large sets of matrices is unusable for the moment. However having a group like Apache and more importantly having an Apache license should make it the best option. Especially for businesses that want to evaluate Graph databases and don’t want to spend fortunes on licenses or open source their complete solution when it is only a minor part in a larger solution.

FlockDB is very ruff around the edges (still). It might fit Twitter’s needs but most other people would like partitioning over multiple servers to be transparent and would like to traverse a graph.

In short there is no real solution yet, instead there are a lot of promises. Although commercial options exist, there are too few big ongoing graph projects in Telecom that would justify expensive licenses. Telecom is not a mature graph market yet. It is just starting or graph databases are used on side projects only. Since graph databases are an infrastructure element, having a open-source business-friendly license is preferable. Money can still be make via consultancy, support, administrative tools and a revenue sharing market place for re-usable algorithms. It is now more important to be market-leader in this developing market, then to have the highest sales volume of a niche market.

Why is a graph database important to telecom?

If I call you and you call me then we have a relationship. If I am the key “connector”, “maven” or “salesman” (See The Tipping Point) among my friends or business contacts then I would be the perfect marketing objective. Unfortunately RDBMs are not good at finding those profiles between millions of subscribers.

This is an open invitation for people to join forces and build tomorrow’s architecture, preferably with an Apache License, extremely scalable (billions not thousands) and with support for complex algorithms.

Facebook is rolling out seamless messaging which allows people to focus on what they want to communicate and not on how to communicate.  This is again an example of using the social graph to communicate better.

Under the hood Facebook is using Hbase and Hadoop so there is no reason why Telecom operators could not have launched a unified communication system. True the operators don’t have an advanced social networking platform but they can use the user’s mobile social graph as a substitute. If I call you and you call me then we are friends. In the operator’s systems (CRM, HLR, etc.) there is information about who is who. This information is not perfect so operators would need to add a social address book in which users can update their own information and get other people’s updates, much like Plaxo. Adding SMS, instant messaging and email to voice calls, store it in the Cloud and we would have a seamless messaging solution.

The problem is not how hard it would be to implement but why operators are not focusing on this type of solutions. Focus is on market segmentation to find the right tariff plan and device to sell. However operators that want to be around whenever their call and SMS revenues start to seriously decline, will have to do a large mindset change: “Focus on why people want to communicate and not how!”. Find the why and you are likely to come up with alternative hows that are currently not available. A lot of buzz is being generated around Unified Communications Suites but they are the telecom answer to the how not the why. Facebook is definitely shooting in the right direction. Let’s see if operators can do so as well…

Facebook is hot. Google is trying to create an equal successful social network. There are specialized social networks like Linkedin, Plaxo, etc. focusing on specific social networking aspects.

If you are not social, you are not Web 2.0!

Why are telecom operators not social?

Telefonica launched Keteke and bought Twenti so operators must be social. However launching or buying a social network does not make an operator social and web 2.0 ready!

Social networking is all about the social graph and what you do with it. Operators have had access to one of the best social graphs for years. However they have chosen to ignore it: the mobile social graph.

If I call you and you call me then we know one another. If the both of us call a third person then we have relationship to a person in common. It is true that the operator does not know what the relationship is between two persons that call one another. But that should not stop them from asking!

What can I do with a mobile social graph?

As soon as I provide an operator with the type of relationships I have with the people I call or send a message to, my mobile social graph will become useful both for me and the operator.

There is a whole list of applications that can be build on top of this mobile social graph. Let me give two examples.

A social addressbook

Just by telling which of the calls are business, family and friends, collective intelligence can do the rest. If I have two colleagues that marked a person as a colleague and I call that person then my addressbook can suggest to add this new phone as a colleague. There is a lot of more advanced features that could be added, but the basic idea is that a better addressbook generates more calls and SMS.

Find the influencer

This service is more advanced. The assumption is that if I call on Friday night a restaurant and during the next two weeks five of my friends call the same restaurant then I might have influenced my friends. Knowing who influences others is already used for churn analysis.

In our case the restaurant owner might be willing to pay a premium to contact me about a new promotion. Afterwards he or she can follow up if I or one of my friends made a call in the weeks after the promotion was send to me.

If you want to learn more about the mobile social graph don´t hesitate to contact the author at maarten at telruptive dot com.