Archive
Telco PaaS is not Telco Assets and PaaS
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…
What should tomorrow’s mobile cloud offer?
The IT cloud has taken shape. The next step is to offer a mobile cloud. How will it be different and what should a telco offer? For clarity, mobile cloud applications are combinations between mobile apps and cloud computing and telecom backoffice services, not iPhone or Android apps.
Mobile screens of all colours and sizes…
Where the PC worlds only has a handful of web browsers, the mobile world is completely different. Old mobiles live together with the latest smartphones. Applications can be native or web-based. Screens can go up to 11 inches (28cm) on tablets and even if we consider television screens to 50 inches (1.27m). We can even find mobile applications without screens (M2M) or via very limited character entries (SMS).
Although HTML 5 is bringing a good potential stardard, there are still quite some differences between different mobile browsers. So it will probably take some years before a reliable standard is omni-present.
In the mean time operators will have to offer solutions on their mobile cloud. Applications will have to be available on a wide set of platforms. Any help an operator can bring to developers will be highly appreciated.
Mobile testing nightmare
Having to test an html5 application on hundreds of mobiles is a nightmare. Some companies already offer partial solutions. However providing a solution via mobile hardware virtualization and automated testing would help developers bring apps to market quickly. Testing could be paid for by minute (instead of hours in the IT cloud). Mobile makers and testing software companies could get a revenue share for every developer that uses their virtualized solution. This would release the operator from having to do all the mobile OS virtualization and sensor testbeds themselves. It would be similar to having third-parties selling access to their Amazon AMIs but instead they would be for a Nokia Symbian or iPhone 4.
Mobiles have sensors
The latest mobiles have a long list of sensors (GPS, accerelometer, etc.). Mobile clouds should offer developers help in using these sensors and automating testing. You don’t want to physically move a mobile abroad to test if you get a roaming event, would you? Push notifications to the mobile have to be supported in a uniform way accross different platforms.
Latency and network connectivity can be a nightmare
Content caching on the mobile device is key. HTML5 offers an off-line key-value store but unfortunately not all mobiles support it so custom solutions are necessary.
Advertisment support is key
Offering a ready-made integration with major mobile advertisement solutions is important. Some applications can not be charged for, so advertisement is the only means of income. Inline content sales should be supported and hopefully at more competitive rates than the App Store’s 30% revenue cut.
Telecom assets should be the differentiator
All of the above can be offered by IT and dotcoms. Integration with unique telecom assets is a must. Sending an SMS is no longer a unique asset. Neither is location. They have to be real assets: micro-payments via telecom billing, custom numbering plans, zero-cost call forwarding, voice transcription, quality of service, etc.
Become the Elastic Beanstalk of the mobile cloud, not the Google App Engine
The Amazon Elastic Beanstalk is a service that allows java developers to deploy their applications and instantly benefit from auto-scaling, elastic loadbalancing, etc. However in contrast to Google App Engine, there is no one way of doing things. Developers have the liberty to swap out Amazon’s initial configuration by customized configurations.
Mobile to Cloud and Telco connectors
The mobile app, tablet app, TV app, M2M app should be seamingly integrated with cloud applications as well as telecom services. Having single sign-on via OpenID or getting data from the cloud via oAuth are basics. Setting up a conference call, managing call forwarding, voice transcription, etc. are others.
Selling the mobile cloud via a telco marketplace
Mobile cloud applications are combinations between mobile apps/M2M/SMS/Calls/TV Apps/…, cloud computing and telecom backoffice services. Programmers should be able to add them to a telco marketplace and sell them to different customer segments (consumers, soho, small/medium/large enterprises, M2M, etc.). However offen mobile cloud applications should be given away for free and programmers should get a revenue share on telco assets that are used, e.g. calls made, SMS sent, etc.
Mobile Social Networking
Adding social networking concepts are key. Operators know who you call most often. This information can be key when combined with cloud social networks. As long as privacy and opt-in are used, then users should only see benefits.
The long tail mobile cloud is nearby…
The long tail mobile cloud is nearby and operators can be the key players in it. However they will need to suppress their urges to be greedy. Revenue shares should be inline with the dotcom and IT industry. So should individual mobile cloud application pricing.
Cloud speed in time-to-market is necessary. Operators should not try to build things themselves. Instead they should partner with dotcoms and IT/network providers in real partnerships.
Finally the rules are changing. Old rules can no longer apply. Users need to be able to choose between multiple competing mobile cloud apps. No longer can the operator’s marketing department decide what will be a hit. The user community is the only one with this power. Social CRMs and other long tail support solutions can be used to avoid massive call center calls.
Creating Telecom Network Apps the Cloud Way: Telephone 2.0!
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…
The CFEO and the nerd make room for the CBIO
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…
