Archive

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:

Telco PaaS services need to be launched in weeks not years.

Telco PaaS services will be buggy, unstable and fail.

Telco PaaS services can not be supported via a call center.

There are no Telco PaaS standards and there are likely not to be any until it is too late.

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…

Although a good percentage of tablets will come with 3G connectivity, and even 4G future-expandable connectivity, does this mean that telecom will get another cash-cow? I do not think so!

Yes operators will sell another SIM and the associated monthly data charges. But with people having to buy multiple SIMs, they will want to see discounts. Users will want plans that focus mainly on data. This means to have price plans that reduce calls and SMS monthly costs to the minimum. The idea is that they would use their phone to call and their table to surf.

However what is likely to happen is that users will come into situations where they want to communicate with people from their table. Since calling and sending an SMS is too expensive with their tablet data subscription they will install more and more instant messaging and VoIP apps. Pretty soon users will get accustomed to use video chat instead of just voice calls.

The end result will be a boost to IM, VoIP and video chat apps. If you use them on your tablet, then you are more likely to also start using them on your iPhone or Android. The final result might be that subscription revenue goes up for the operator but call and SMS revenue goes down significantly as well. Perhaps the overall outcome in revenue is positive but the final result is that at the end of 2011 operators are seen as data plan providers, a.k.a. bit-pipes.

There is no quick fix for the operators. Launching some operator-build tablet apps will not reverse the curve. Nobody wants Faceclone or SMSitter. People want the real thing.

A drastic shift is necessary in the operator to form part of this new eco-system, see long-tail telco.

Voxtrot is built by some of the original Skype team members. Unlike other mobile voip apps, this one has a real potential to change end-user’s behavior. The big difference with Skype and others is that Voxtrot does not assign you yet another username or phone number. You register with your original phone number. When you are calling somebody then Voxtrot will check if the other party is also connected to Voxtrot. If both parties are connected to Voxtrot then the default option will be to use VoIP instead of a mobile call. The Voxtrot call will be “free” – at least if you are on WiFi or have a large enough data plan – instead of paid. As such Voxtrot will have stolen a call away from the mobile operator…

Although Voxtrot is essentially similar to Skype and others in VoIP technology, the easiness of going VoIP together with the social aspect of inviting all your friends, is really setting it apart from the competition.

Voxtrot is currently only available for Android but plans for an iPhone version were made public.

Long Term Evolution, LTE or sometimes also referred to as 4G, is the next generation mobile network technology. It promises to bring network speed to the mobile that can beat the current ADSL offerings. In the beginning LTE prices might be high but competition especially from new entrants – “the Ryanairs of telecom” / “4G Bitpipes” – are likely to bring affordable pricing plans soon. The US already has the first “4G Bitpipe players”: Clearwire and Lightsquared.

So what does it mean if tomorrow you can have ADSL-like speeds for an (almost) flat-rate. In practice, end-users would be crazy to still pay €0,15 for minute for a call or per SMS. Skype with its optimized codecs (e.g. SILK) will offer better voice quality and will throw in video for free. Instant messaging, Twitter and Facebook chat will completely substitute SMS. This will be the end of the telecom cash-cows: calls and SMS…

What will be the next cash-calf? For those operators that are still looking for the “Killer App” – that single technology that only telecom operators can offer and is extremely successful – I have some news. Postal services are still looking for their killer app after the stamp was substituted by email. So is the music industry. There is no economic law that says that a former monopolist has the right to pick its next monopoly.

So if there is no “Killer App” does it mean that all telecom operators are doomed to become bit-pipes tomorrow? Over time several will but not necessarily all. Although dotcoms have the sexiest solutions, large corporations are unlikely to massively shift their communication services to a heavily indebted 25 people company close to a surf-paradise beach. So due to inertia the abyss is still some years away. However should you just give up and let consumer ARPU drop year by year?

I believe there is still a window of opportunity for telecom operators to bring new appealing services. However they must be willing to abandon some important historical laws of telecom.

1) Standards slow innovation

Collectively negotiate a standard that is more a political compromise then the simplest, most effective way of doing things is not helping innovation. In the Web 2.0 era, dotcoms launch new ideas all the time. Most of the time it is a “winner takes it all or at least most” market. So the winner sets the standard. How many Twitter competitors do you use?

By designing an architecture around obscure standards, few operators have employees that can explain their company’s architecture. Google and others have invested heavily in their architecture. They constantly update it. But on a blackboard a Google architect can draw you exactly why they choose Bigtable, GFS, etc.

2) Don’t talk about subscribers, call them users

A subscriber is an entity that signs a monthly contract with a telecom operator. By doing so a subscriber seems to subscribe to a list of applications that the marketing department of the telecom operator has preselected as the most adequate for him or her. The operators seems to know what is best for their subscribers. WRONG!!!!!!!!

Call them users and give them the tools to select/create/design/customize/configure the services they want. Let the community vote about which feature is needed. Ask users why they stop using a new service after a week. Let users define the price they are willing to pay by offering multiple alternative solutions in different price ranges with different feature sets.

3) Go from a catalog of few to an infinite catalog

If Telecom can no longer survive based on a few hit services, then they could go to the other extreme: the long tail telco. A long tail telco offers an almost infinite catalog of solutions that combine communication assets with other solutions in order to solve user’s problems, to make them more productive or to entertain them.

Users should be able to combine products to resolve their needs. A good example is what is offered by Invox. Via wizards, templates or a Yahoo Pipes drag-and-drop configuration, small to large enterprises can configure their own telecom services like call centers, PBX, etc. They can easily integrate the best of the Internet (Salesforce, Google, Yahoo, etc.) with IP-based communication. You use what you need. You configured it the way you want it.

What is missing is a market in which those users that don’t want to do it themselves or who need specific support (e.g. custom integrations), can go and find the right help.

Telecom operators should no longer focus on end-user services but on enabling the end-user and an eco-system of independent third-parties to be able to create and sell solutions and services to one another. As long as it is easier, faster and cheaper for a third-party to use an operator’s tools and assets they will see no need to design an alternative solution. This brings us to the next point…

4) Monopolists die because of greediness

Revenue shares of 40-95% are often not in line with the value and risk the operator takes in the value chain. Those operators that think that “squeezing partners until the last drop” is a good long-term strategy, will be the first to die. Innovation needs out-of-the-box thinking. People don’t take risks if they don’t see rewards.

You will need to do more than to just blindly follow these four rules. But by applying them and listening to users, you are on your way to create new cash-calfs…

I am still waiting for the first telecom operator to offer a similar service. Neither of these services is nuclear science. Most are SIP or other VoIP solution based. Via a SaaS marketplace operators could be reselling them if they don’t want to license or build. Additionally the operators have some valuable assets that dotcoms would love to make use off: micro-payments a.k.a. billing/charging; free call forwarding; numbering plan creation; high-available network assets; quality of service; etc.

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…

Billing – Micropayment solutions from Paypal and Google Checkout are trying to enter this domain. Squared from a former Twitter-employee is attacking the mobile payment terminals in shops.

Spectrum – Google’s CEO is the chairman of the New American Foundation that is trying to convince the American government to open medium-distance spectrum for free. Sort of WiFi but with kilometers reach.

High-speed interconnect networks – Google is paying part of some of the under-sea links that connect multiple Asian countries.

Fiber to the home – Google is rolling out fiber to the home.

VAS – mobile apps are taking over from the value-added services.

PBX like Business solutions – on-site premise equipment is being substituted by virtualized Cloud-based solutions.

The telecom network – telecom operators are becoming bit pipes. New bit-pipe-only companies however are trying to specialize in this domain, making it hard for communication service-oriented operators to keep on making the same profits.

What should operators do?

If there was one simple answer, I would not be writing this post but living on my own private island 😉

However if history can be a teacher, let us look at an industry that has been facing similar threats: Hollywood. Prices of distributing digital content have fallen close to zero. However the industry has been trying to keep on charging €12-€30 for CDs and DVDs. They have hardly embraced digital distribution and are now in a negative spiral of demise.

Telecom operators can easily get stuck in this same vicious circle. History has been cruel in the past: extremely lucrative postal monopolies were destroyed by email. There is no rule that states that economic wealth from one business model is substituted by a similar lucrative business model afterwards. Often analogue dollars are traded for digital pennies.

Accept digital pennies but collect them all

The first survival strategy is to embrace change and to go for digital pennies. This is often hard to do within existing companies. As such the proposed strategy is to set-up a parallel organization whose objective is to focus on these new business models and how to make money with them. Let the main company focus on the telecom hits (Voice, SMS, etc.) and the other company on the long-tail telco services.

Long-tail telco services are all about enabling communities of developers and companies to create new and innovative telecom solutions that they can sell to others. The focus should be on enabling others. Not on building them yourself. Being an App Store for telecom network-assets-based applications and not a builder of telecom services.

This parallel organization should be in close collaboration with partners and even dotcoms. If you can´t beat them, join them. Find ways of enabling startups to become successful with your network and other assets, not on building a parallel solution around your assets.

The music industry never understood this message but hopefully the telecom industry does.

Go IP and forget Circuit

Accelerate IP solutions and forget about circuit networks. The speeds at which services are rolled out in a circuit-based network are too slow to fight off competition. Isolate the circuit-based network elements and put an IP-based front-end.

Use the Cloud to quickly launch beta services.

Avoid building infrastructure and use the Cloud to innovate. In the telecom world services are often not launched until they are perfect. But perfect for who? It is better to launch beta services quickly and get real customer feedback instead of marketing-surrogate feedback. Launch multiple services. Check which are the successful ones. Kill the others and heavily invest in the successful ones. Cloud computing and open source can dramatically reduce innovation costs.

Build long-tail services and a common innovation-ready architecture

If you are going to work with hundreds of partners to quickly innovate then the way to interact with them is via self-provisioning. Build billing, telco network app stores, customer care, monitoring, etc. solutions that allow a third-party to automatically provision and test their solutions. Be open with interfaces and light on approval. Let them approve a web-based contract instead of sign a physical paper.

Also enable innovation via the right infrastructure. Let teams focus on the business and services. Not on storing data, managing users, billing, monitoring, etc. Common service APIs to interact with assets and common ways of building new services should accelerate time to market and avoid reinventing the wheel.

This is a time for innovation together with smart partners. Not a time to focus only on CAPEX reduction. Too many effort is spend on operating as cheap as possible and not on generating new revenues. At the end the best CAPEX reduction is to shutdown a telecom company that does not innovate at market speed and became obsolete 😦

Disclaimer

All the contents of the Blog, EXCEPT FOR COMMENTS AND QUOTED MATERIAL, constitute the opinion of the Author, and the Author alone; they do not represent the views and opinions of the Author’s employers, supervisors, nor do they represent the view of organizations, businesses or institutions the Author is a part of.

The Author is not responsible for the content of any comments made by the Commenter(s).

While we have made every attempt to ensure that the information contained in this Blog has been obtained from reliable sources, the Author is not responsible for any errors or omissions, or for the results obtained from the use of this information. All information in this Blog is provided "as is", with no guarantee of completeness, accuracy, timeliness or of the results obtained from the use of this information, and without warranty of any kind.