Telruptive

For the last year and a half Telruptive focused on trying to save operators from becoming bit pipes and with it trying to save employment in the telecom industry. This has been a major limitation for the type of blog posts that could be published. Starting today Telruptive’s focus has been extended. Any innovation, disruptive technology or business practice that has to do with communication between people as well as machines is valid. Communication is not seen as pure telecommunication but is seen in its widest interpretation, moving information between one or more parties.

Why is saving operators no longer a priority?

There has been no proof in the last year and a half that most operators will not become bit pipes. Most operators will either become bit pipes, consolidate or worse. Telecom solution providers will either shrink, consolidate or worse. Only real innovative operators will have a chance to be active outside of communication infrastructure. Unfortunately there are very few of those. LTE will seriously disrupt the operator’s monopoly on voice calls. iMessage, Whatsapp and similar services already crossed the tipping point and are disrupting the SMS business. Operators ‘ answer has been nothing or too-few-too-late. The telecom industry resembles the titanic more each day. It was once the most luxurious cruise ship of its time. But disruptive icebergs are making it sink. Instead of building lifeboats with material found on board, the operators seems to have taken the decision to play music and await what will happen.

Telruptive wants to inform innovators about new ways of communicating, new disruptive technologies they should use, new disruptive business models they should implement, etc. Innovators can be operators, telecom solution providers but can also be dotcoms or people not linked to the telecom industry. This is what Telruptive will be focusing on in the future.

Today Friday 13th August 2014, the conglomerate Ericsson Nokia Siemens Alcatel Lucent Networks has filed for bankruptcy protection.

How can it be that only 2,5 years ago the conglomerate consisted of three companies that were employing tens of thousands employees each? Bad management was not the reason for the downfall. Each company was professionally managed and was trying to provide solutions its customers asked for. Their major business was delivering LTE (5G) networks to telecom customers all over the world.

The downfall initiated at the end of 2012 when their customers started to massively launch LTE networks. Subscribers in 2013 noticed that with the new LTE network calls and SMS could be substituted by free VoIP and instant messaging. All of a sudden telecom revenues started plummeting. To make things worse HD digital content distribution moved from broadcasting to streaming, putting heavy loads on the new networks and the associated costs onto network operators. By switching off digital broadcasting, spectrum all of a sudden became less expensive, triggering major accounting adjustments.  Several operators went into panic mode and started large-scale consolidations and cost cuts. This triggered a consolidation between the three major telecom solution providers.

Operators never requested their solution providers to help them build new revenue generating solutions until it was too late. Operators were asking for faster, easier to manage and cheaper networks instead. As a clear example of the Innovator’s Dilemma, telecom solution providers focused on what customers requested, not on what customers really needed.

For the telecom industry IP communications, Cloud Computing, Smart Phones, Tablets,  Content Streaming, Social Networks were all disruptive innovations that changed the status quo completely and faster than anybody in the industry expected. Consumers changed their behaviour faster than telecom providers anticipated. Dotcoms, then also called over-the-top-players, were a lot more agile than operators and telecom solution providers.

After the introduction of LTE, also the complexity of the telecom industry changed. For the first time networks no longer had services entangled in obscure protocols. Standardized web technology could be used which massively invited IT players to enter into areas that used to be the exclusive playing field of telecom solution providers. Ericsson Nokia Siemens Alcatel Lucent Networks had a company structure build around complex proprietary-standards and solutions. When these could be substituted by off-the-shelf standard-based solutions, services daily prices got divided by four. This rendered the existing players uncompetitive virtually overnight.

February 2012: This post is fictional but unless telecom solution providers start asking their customers how they will generate new revenues with LTE, nothing will stop it from happening…

When you ask a company about innovation, they talk about how their product manager asks customers what they want and how their R&D delivers new features or new products. Lots of companies are following the pain points to solution approach and engage in evolutionary innovation.  Although evolutionary innovation is the best way to grow revenue from an existing customer base in the short run, there are several disadvantages that most underestimate.

Evolution means assuming the status quo will never change

Evolving products based on customer feedback assumes that the current solution is the best possible solution for the customer and only some features are missing. Showing status-quo-breaking innovations, a.k.a. disruptive innovation, to customers will often yield a negative response.

Whoever went to the postal service to try to sell email servers as the next generation letter [letter 2.0], will have had a very negative reply. The postal service would not understand why they would want to offer free-of-charge instant delivery to their customers because it canabilizes their existing business. Instead if you would offer a sorting machine that can sort double the amount of letters in half the time for half the cost, you are a lot closer to a sale.

Whoever read “the innovator’s dilemma“, will understand that disruptive innovation is often rejected by the current customers because it either canabilizes their business or is not resolving their specific pain points.

World-leading companies focus at most 90% on evolution and at least 10% on disruptive innovation. Some like Amazon and Apple seem to invert the equation.

Companies that do not focus on disruptive innovation will sooner then later run into problems. Disruptive innovations are becoming more common place and occur more frequently. Whole industries are being transformed as we speak. Existing players can disappear in a few years:

Media:

• Books versus Kindle and eBooks
• CD, DVD and Blu-ray versus P2P, mp3 and DIVX

IT:

• Harddisks versus memory cards
• Data center per company versus Cloud IaaS
• PC with Windows versus Tablet with Android

Telecom:

• Physical PBX versus Cloud-based PBX
• Roaming versus VoIP
• Nokia feature phone versus iPhone and Android
• Circuit networks with pay per minute versus flat fee data traffic
• Physical routers, firewalls, loadbalancers versus virtual networks and Openflow
• High priced spectrum licensed versus white spaces

Towards a world of demand creation

Companies that want to innovate disruptively should focus on demand creation. Demand creation is about understanding customers hassles. Customers hassles are different from their pain points in the sense that customers do not always understand their own hassles, and even less tell you.

People never told Nokia that their phones were such a hassle to navigate the internet and to install applications on. Customers will not tell you that you need to build a touchscreen phone and app store to solve the hassles.

Disruptive innovators find those activities that customers waste a lot of time with, think are ackward, cost a lot but deliver few value, etc. by questioning, observating, networking and experimenting.

Disruptive innovators at the same time focus on developing technology capabilities in innovations that have a potential to change industries, e.g. VoIP, cloud computing, big data, collective intelligence, etc.

Disruptive innovators work together with early adopters to map out their hassles into hassle maps. To understand if solutions for these hassles are like painkillers [big market] or just vitamines [no or small market]. They propose the simplest solutions possible. Those that do not require a user manual.  First on paper and only when everything is validated [technical solution, business model, distribution, purchasing stakeholders, marketing] do they build a real prototype. Ideally customers can personalize the new solution towards their individual needs. Listening to customers is key. Being able to add features frequently and validating in a statistical manner which one contribute to the bottom line, allows innovators to rapidly go from an early beta to a ground-breaking product.

Disruptive innovations do not need to cost millions to launch. Good books on the matter are: Nail it then scale it, Demand: creating what people love before they know they want it, the lean startup, etc.

1. One or more major telecom operators will fail. With the crisis continuing some major telecom operator will get into trouble due to the high costs of LTE licenses and the abrupt drop in ARPU.
2. Consolidation in the telecom provider domain. Either ALU or NSN will be losing its independence or Chinese players will merge.
3. Nokia and RIM will lose their independence. Microsoft will absorb Nokia.

Let’s hope my negative predictions are wrong and a lot more positive things happen.

Telefonica recently restructured its business units and now has a separate business unit called Telefonica Digital that is ran from the UK and has several offices around the world: Sillicon Valley, Madrid, etc.

Telefonica Digital is a clear sign that the traditional telecommunication business is no longer going to be the growth engine for Telefonica. So what should Telefonica Digital focus on. Here are five ideas. Some are already partially in progress but ease-of-use, consistency and completeness often can be improved.

1) Become the European Netflix

Google and others are likely to enter into the European market for all-you-can-eat video-on-demand, a.k.a. pay a monthly fee and see all movies, music, series, documentaries, etc. you want. Netflix is the American success story however there is still a window of opportunity to become the European one. Having great content is key in this market. However the most important competitor is not a company but a protocol: P2P. Some European countries have high piracy rates. People are getting accustomed to downloading movies and music for free. The longer Hollywood holds on to high prices in the digital age, the more chances there are that people will not want to pay any more for content. Even when all-you-can-eat service becomes available. Sometimes it is better to have every family pay €15/month then to have almost nobody pay €20/DVD.

2) Long-Tail Partner Eco-System

Open system for partners, big and small, to easily integrate into Telefonica’s back-office systems. Partners should be able to:

• charge customers and handle recurring subscriptions
• have single sign-on solutions and access to user profiles
• update Telefonica’s inventory and CRM systems without magic
• provision Telefonica’s base services (e.g. numbering plans, VLANs, etc.) in one-two-three
• long-tail monitoring and alarming
• long-tail settlement engine
• long-tail support systems
• Escrow and standardized contracts
• Standard revenue sharing arrangements in which partners get the lion share.

Having a long list of long-tail partners will boost innovation at a relatively small cost. A regular operator takes 12-24 months from idea to production launch. In the digital era, new services should be launched daily. Without partners this is impossible. Telefonica should focus on lowering the entry level so two people in their garage can benefit as well.

3) Telco & Mobile PaaS

Offer easy to use telecom APIs to key assets like billing, network quality of service, user profiles, micropayment subscriptions, etc. Allow developers to integrate these telecom APIs into SaaS and mobile apps/SaaS. Have tools to easily create mobile SaaS and native apps. A cloud-based environment to host SaaS. Have a marketplace where customers can easily buy and provision the combined solutions. Solutions to support customers that need help for solutions they have purchased.

4) M2M PaaS

Similar to Telco PaaS but for machine-to-machine and the Internet of Things. Specific hardware plug-and-play functionality, backoffice plugins for monitoring/alarming/management interfaces, etc.

5) The Paypal of Mobile Payment

Operators have a limited time left before alternative systems will disrupt the micro-payment “oligopoly”. NFC solutions, micro-payment subscriptions, mobile payment, etc. are still not standard. Mostly not because of technical limitations but because the whole eco-system wants to see a high margin business. High-volume low-margin would however change the potential of short-term success. What if a micro-subscription (€0,10/month) would leave a merchant with €0,09 instead of €0,05 or less? The window of opportunity is closing fast however…

Telecom operators have always focused on two aspects: ARPU and time-to-market. In the latest technology craze – Cloud Computing – a lot of telecom operators are seeing a new golden grail. Those that can see further than SaaS marketplaces and moving their hosting to IaaS are only the happy few. Since Cloud Computing = SaaS + PaaS + IaaS, it is normal that operators start talking about Telco PaaS. However Telco PaaS is a lot more than combining telco assets with an IT PaaS.

IT PaaS are aimed at quickly launching applications. The IT grail is to launch thousands of applications to find the one that everybody likes and become an overnight millionair. Telecom operators might be easily fooled that opening their telecom assets to IT PaaS developers will bring that one application that will turn the telecom sector around: “The Killer App”.

Unfortunately a telecom application is more than an SDK+app server in the Cloud that can do VoIP. The reason why companies pay a plus to telecom operators is “trust”. “Trust” that you can pick up the phone and call somebody. “Trust” that if something is not working that you can call their call center. “Trust” that tomorrow they will offer you the service.

All this “Trust” has to do with the way operators have their backoffice systems and processes set-up. Having thousands of developers creating applications that mix telecom with SaaS might give some nice innovation. However telecom operators are not prepared to handle thousands of end-users that find bugs in a long list of applications and start calling call-centers massively. End-user expectations are different for telecom applications then for IT applications. This definitely has to do with the price they pay for them.

What should a Telco PaaS offer?

More than a fixed feature set, the most important changes for an operator that wants to offer a Telco PaaS might be internal. Operators will need a large shift in thinking to be able to accept some of the new realities:

1. Telco PaaS services need to be launched in weeks not years.
2. Telco PaaS services will be buggy, unstable and fail.
3. Telco PaaS services can not be supported via a call center.
4. There are no Telco PaaS standards and there are likely not to be any until it is too late.
5. Telecom can not be greedy

Launching in weeks instead of years

If IT PaaS is bringing something then it is speed of development. Telco PaaS needs the same type of speed. In practice this means that REST and JSON should be the operator’s vocabulary, not SIP and CDRs. Telco Assets need to be exposed to non-telco programmers. Developer communities need to be created. Marketplaces that allow developers to sell their creations by the click of a button and not to worry about complex charging and billing.

Unstability, bugs and failure

Not every IT programmer is a genius. There are probably quite a few geniuses. Instead you need to expect that people will do things incorrectly, by error but also on purpose. Application virtualization and sandboxing are key to make sure “mistakes” don’t bring down the whole platform. On the other hand customers need to be segmented. There are customers that can see further than the bugs and see the potential. These are called visionaries or early adopters. It is critical that operators allow these early adopters to play around with buggy services. However it is equally important that the majority of users know that the sandbox might contain buggy apps and that the call center is not the place they can find help.

No support via the call center

All sandbox applications can not be supported via a call center. Agents will not know anything about these thousands of apps but neither should they. The only one that knows is the one that developed the service. He or she should get the right tools to quickly understand which bugs or feature requests are important, e.g. via a social CRM. The operator should monitor those promising apps that are ready to graduate the sandbox. They should be place in an incubation program. Incubation will see if the applications can go mainstream and will professionalize support, availability and reliability.

No Telco PaaS standards

In the dotcom world the first one that creates a solution, creates the standard. In Telco PaaS this will be the same. If we do not know how users will use a Telco PaaS, how can we expect that standardization bodies will define the correct standards. However in disruptive innovation, unlike technology evolution, first movers have an ever lasting advantage.

Telecom Greediness

If you have a monopoly, you can be greedy. No competitor will offer anybody a better deal. However in Cloud Computing, greediness will kill your best innovation. It is better to get a small percentage, signup or usage fee per application when you have thousands of applications then to get nothing at all. Many cents can make billions. Think Adwords…

Ask a Telecom architect how you create a telecom network application, often dubbed as value-added services. He or she will focus on SIP/SS7 standards, service delivery platforms, etc.

The future of cloud-based telecom network apps, let’s call them tapps, is going a totally different direction. For the former telecom architect they probably like open source solutions like Mobicents that allows you to create SIP-based applications on Java. The Asterisks and other types of VoIP application servers are other alternatives.

However for a new generation of Web-based programmers this is all too complex. These are the programmers that like Javascript, Ajax, JSON,  PHP, Ruby, etc.

The majority of them will be fine with whatever Twilio or Tropo offer via easy to use REST APIs or embedded in their favorite scripting language. Which cloud-based application needs more than calling, SMS, answering the phone, getting feedback from the user, telling the use what to do, putting multiple users in a conference, transcribing what the user does, forwarding a call, etc.? 95% of the functionality is covered with a handful of REST APIs.

For business developers that are more used to Java, they can also use Java APIs to access for instance Twilio. To be able to cheaply launch an application and scale it afterwards they could deploy it on Google App Engine. A new alternative has just come around from Amazon: Elastic Beanstalk. A developer can write their app and deploy it on Beanstalk. They no longer have to worry about monitoring, scaling, opening firewalls, etc.

Other alternatives are to extend Cloud-ready telecom applications via plug-ins. An example here could be Twilio’s OpenVBX in which you can easily add new plug-ins.

The conclusion is that 2011 will be the year in which Web 2.0 and the Cloud meet the Telephone 2.0. However the Telephone 2.0 will unlikely pass through Bluevia and other operator initiatives given the fact that they are running about two years late and are very scattered, slow-moving initiatives.

Operators should embrace the new reality and try to help these new applications find new users. The Appstore brought a new eco-system to life. Millions of small and medium-sized Telephone 2.0 applications are waiting to be discovered by Billions of users. Remember that not everybody can pay an expensive mobile with an expensive data plan. However there are billions that can pay for cheap call and SMS-based applications. We need to help the billions find those tapps that are useful to them…

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.

SS7 networks or “intelligent networks” have been the core reason why network-based services can not be rolled-out quickly. Specialized skills are needed to launch a new SS7 service.

Currently operators are investing in service delivery platforms or SDPs to move the network intelligence out of SS7. These SDPs will be holding modern copies of the SS7 services.

However do we need intelligent networks? Why can’t we have dumb networks?

The Internet is a dumb TCP/IP network. Intelligence is not in the network but in the applications that run on top of it. Why are telecom networks different? Why do routers have to know if the application is voice, SMS or data? Why does the network have to know about conferencing, numbering plans, etc.?

One example: MSISDN

Why do you want to hard-code an end-user identifier throughout your network & billing systems? Why can’t we have a mechanism like a unique IP address and several DNS names for it. I don’t want to learn a long list of digits to identify a friend. I would like to control my own numbering plan. My direct family starts with 1xx. My friends 2xx. Alternatively I can use their email. I should be able to call a company with its DNS. Ideally I can use the Facebook or Twitter id as well. This would all be possible provided that an internal identifier would be mapped to an end-user identifier instead of using one unique identifier.

Example two: CDRs

Why should every network element know that for every call you need to generate a CDR. However for data, charging is not based on seconds or minutes but data volume? Cannot the metering be done outside the network? Why are we generating millions of CDRs when end-users have a flat-rate or are calling a free number? With software-as-a-service metering can be different per application (pay per GB of storage, per MB of network traffic, per user per month, per company per year, etc.).

The proposal: Define the metering mechanism for each call, SMS or application ad-hoc and use specialized meters outside of the network to meter the service. Time-based meters allow any type of data to pass through to the network but will bill by nano-second, millisecond, second, minute, hour, day, week, month, year, etc. You just configure that this voice application needs second-based billing, that adult entertainment application needs minute-based billing and that compute server needs hourly-based billing. Flat-fee calls would not have to be metered and as such don’t need a meter. Meters could be gateways that scan if data goes through. However they could also be event-based and delegate complex metering into an application to warn them when an event has to be billed, e.g. application download, new user registration, etc.

Simplifying the network by taking out complexity to manage/launch/meter/monitor services would substantially reduce the cost of network equipment. Perhaps to such extend that it becomes too small to meter services and as such also metering can be eliminated. Pure bit-pipe operators could probably do with an Excel or Access database as their billing system.

At the end of the nineties Sillicon Valley was nerd paradise. Every technically skilled person could have a chance on getting excellent working conditions and maybe become rich. The bubble burst. No more unprofitable dotcoms and the end of telecom innovation paradise. Shorts in the office were replaced by ties.

The new ruler of the world was the CFO, who was first promoted to COO and afterwards to CEO, shortly CFEO. Shareholder value, CAPEX and OPEX were the new buzzwords. Creative accounting the solution to revenue problems. The current crisis is showing the limitations of focusing only on cost reductions and not on growing the business via innovative products and services.

It is time for a new class of rulers, the CBIO. The ideal profile is a generalist with a technical background, knowledge of financials, operating experience and an innovative strategist. This person does not have to be an expert in all domains but have at least a good understanding of each and be able to surround him/herself with experts in these areas. The CCO will understand that there are two types of technical projects: routine and innovative. The routine projects should be executed in the cheapest fashion possible: Cloud Computing, Off-shoring, Open Source, etc. The innovative projects will make the difference between global leadership and bitpipe doom in the next 12-36 months. No single RFQ process has brought innovative results to any operator that got front-page news coverage. So innovative projects should not be handled by an RFQ. The telecom operator should be split in two units: “Business as Usual” and “New Business”. The “Business as Usual” should continue to focus on shareholder value, CAPEX and OPEX and become a best-in-class bitpipe. The “New Business” should launch on a weekly basis new services and features to quickly understand what works and kill those things that do not. If the “Business as Usual” systems are not delivering the results the “New Business” needs then they should be allowed to shop elsewhere, even shop with competitors! The “New Business” should focus both on hits as well as long tail services. Giving end-users the choice between millions of services instead of only Voice and SMS. Focusing on the why people communicate and not the how.

Failure to recruit a CBIO will result in the “Business as Usual” becoming a bitpipe but the “New Business” being called Google Voice, Facebook Seamless Messaging, Apple App Store, etc.

CBIO stands for Chief Bitpipe and Innovations Officer…