Archive

Posts Tagged ‘telecom paas’

Are telecom operators like stamp vendors in a world of email dominance?

After speaking with several cloud telephony startups, it looks like telecom operators are like stamp vendors in a world of email dominance. The Innovator’s Dilemma seems to be claiming another victim soon.

CxO’s in existing telecom operators should be really worried. The major telecom cashcows are in danger. Calls and SMS will be substituted by apps like Voxtrot, Skype, etc. Access networks will be under extreme load when heavy smartphone, tablet and M2M usage will become mainstream. Also aggressive bitpipe LTE providers can have a Ryanair effect on the telecom world. Finally business solutions like PBX, etc. look antiquated compared to solutions like Invox, OpenVBX, Ringcentral, etc.

So what should operators do?

First let’s talk about what they should not do. Business as usual is not the ideal strategy. Telecom assets are likely to be substituted in the next 2-3 years, just as location has already been substituted.

Embrace Over-the-Top Player

Only few operators have done so but the best strategy to avoid disruptive competition is to embrace disruptive players. Trying to compete with on-premise equipment against IP-based Cloud-driven PBX-like services is impossible. Allow over-the-top players to offer their solutions to your customers and integrate with your network and your billing systems. Allow end-users a choice of competing solutions.

Expose Assets

If you protect your assets from the rest of the world, then over-the-top players will find ways around them. Location has been substituted. There is a lot of effort being put in setting up micro-payment solutions. If operators want to keep an oligopoly on charging and billing then they should urgently open up both assets and make them available at very competitive prices.

Other assets to open up: numbering plans, call forwarding, subscriber data (either via opt-in or via anonymous aggregation), etc.

Assets should be made available with Web 2.0 APIs. New business models like freemium, subscription and advertisement should be put into competition with usage-based subscriptions.

Open marketplaces

End-users want choice and operators have been traditionally bad at offering it. Nobody wants a Facecopy, Smitter or a LinkedOn. End-users want the original. End-users want to choose themselves between competing products.

Open marketplaces in which developers, partners, end-users, etc. can sell solutions and services that are integrated with the telecom assets, should allow end-users to have an “App-Store”-like experience when they interact with their operator.

The operator should be a business enabler for small companies. Innovative products should be brought in via open communities and partners. The operator offers the infrastructure for small companies to act like global players: e.g. global sales channels, professional support, integrate assets once – deploy globally, etc.

Support 2.0

End-users, be it consumers or businesses, need support. Dotcoms have been traditionally limited when it comes to offering phone support. However a lot of people do not feel like writing a web-based support ticket. Here is where operators could excel. Operators could work on building global support communities in which small companies get access to “call centers as a service”, “professional helpdesk as a service”, etc. A 5 people company should be able to offer global support via local certified partners and a common infrastructure that is offered by operators.

Operators as business enablers

Operators will only be able to survive the Innovator’s Dilemma if they start refocusing their businesses. Instead of being a selector of hand-picked high-priced services, operators should move to open markets where competing services are offered by thousands of partners. The operator moves from offering the services to becoming an enabler for others to offer services that are either based on the communication infrastructure but could also not be based on them. Operators have brands, offer trust, offer phone support, have direct sales channels, know the local markets, etc. Global small dotcoms could save enormous investments if operators would open these non-technology assets towards them and enable dotcoms to become global businesses for as small as they are in the beginning…

Separating the 3G/LTE bit-pipe and voice from data to survive

Large operators are focusing on building the fastest and most reliable networks; increasing call and SMS traffic; offering the best data plans for surfing; offering excellent business communication services; building a machine to machine business; offering impressive IPTV; etc. Management effort has to be divided between all these and other businesses. The quest to get departmental budget is long and hard.

So if you are a telecom CxO and you get three business cases, which one do you choose?
1) LTE business case – heavy investment but strategically key and very good ROI
2) IP PBX vs on-site equipment business case – low initial investment and clear business model
3) Telco PaaS business case – low initial investment but unclear business model

Any business leader would say 1 is best, then 2 and do not invest in 3. However there is something called “The Innovator Dilemma“.  LTE will make it easier for dotcoms to offer IP PBX as well as cannibalize voice and SMS revenues because over-the-top players will be able to offer mobile VoIP and IM. Even if a CxO would invest outside of LTE in disruptive technologies then it is still very likely that the best people will want to work in the LTE project and not in a disruptive technologies project.

Note: An operator that does not invest in LTE will be dead in 2 years so investment in new network technologies is crucial for operators to survive in the short-term. So the solution is not to invest only in disruptive technologies.

So what should operators do?

Create a holding company and three independent sub-companies:

  1. The bit-pipe
  2. The cash-cow manager
  3. The future

The bit-pipe company is focusing on the network and its operations. Cost reductions, stability, network quality and new network technologies, e.g. LTE, are key for this company. This company should be able to work on low margins and even work together with competitors if it makes financial sense, e.g. share network resources or resell capacity to competitors.

The cash-cow manager should also be a company focused on maximizing profits and minimizing costs. The cash-cow manager gets to manage the circuits and deliver voice, SMS and traditional telco services. They have the liberty to provide these services on top of other networks if it makes financial sense.

The future is a company that will have the bulk of the people and some seed capital that will pay salaries for the next 18-24 months. The mission should be clear: “Focus on new revenues coming from data”. There will be no cross-charging between the other two companies. Either you get new revenues or your future is looking very bad. Why would you be so extreme? Look at McKinsey, Telco2Research, etc. they all say the same. Key telco assets will loose their value in the coming 2-3 years as has happened with location. Or operators start to work on new data revenues NOW or they will have to fire tens or hundreds of thousands of employees in 2-3 years. Telefonica already started a process to fire 20% of the workforce. Separating employees into a new company and giving them one mission will make everybody focus on success. Innovative revenue-generating data services is what the telecom industry needs. Without it everybody will start feeling the pain very soon…

Telco PaaS is not Telco Assets and PaaS

April 11, 2011 2 comments

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…

How to avoid becoming a bad Amazon-clone when doing IaaS?

February 17, 2011 Leave a comment

In previous posts I already expressed my doubt about telecom operators getting any real benefits from offering virtual servers and other IaaS aspects to their customers. It looks like “a 2000 déjà vu” in which operators started to offer hosted email after Yahoo and other showed them the way…

So if you don’t want to be a bad clone of Amazon AWS what can you do?

Alternative 1: The Mobile IaaS

Operators are all about mobile communication. However creating mobile applications is hard. Testing them is even harder. Let alone testing them on different hand-sets in a continuous automated testing approach.

This is exactly the type of services that a mobile operator can offer:

  1. Mobile hardware virtualization – instead of virtualizing an x86, why not virtualize the phone hardware, e.g. Nvidia Tigra2. A mobile operating system (MOS) developer could choose which hardware to virtualize: the amount of ram, which sensors, which CPU, which graphics card, etc. Afterwards different flavors of operating systems can be ran on this hardware: iOS, Android, Blackberry OS, Symbian, Windows Phone 7, etc.
  2. Mobile operating system virtualization – For less experienced developers they can already pick a pre-configured phone, e.g. iPhone 4. Afterwards a developer can launch applications on the phone.
  3. Automated mobile phone testing – After installing the application on the phone or using the build in browser to access a remote application, a developer should be able to run automated tests. This would allow for a continuous testing approach whereby a new version of a mobile app or an HTML5 application can be automatically tested by a whole set of mobile devices.

The business model would be the same as virtual servers: you pay by the hour.

Alternative 2: Telecom Infrastructure as a Service

Why not offer telecom infrastructure as a service instead of pure virtual servers? Admitted, the boundry between IaaS, PaaS and SaaS might be thin but ideas can be the following:

  • Billing as a Service: this can go from offering a complete billing system as a service to MVNOs or other industries that need real-time billing capabilities. To the other extreme whereby you would only offer APIs for partners and developers to charge.
  • Numbering Plan as a Service: more then just offering DIDs, you should be able to create services and associate them to a number formed by shortcode+mobile phone+app id => 12367012345601 => calling this number would forward the call to the application 01 belonging to the mobile subscriber 670123456 and 123 means the owner pays the call. 234 could mean caller pays. 345 could mean caller pays premium call and gives revenue share to owner. This could allow every subscriber to have multiple applications without having to pay €1-€5 for a virtual phone number.

Alternative 3: Mobile Development IaaS

Different from the mobile IaaS in the sense that we focus on facilitating the development and hosting of applications for mobiles. Developers would find tools to develop mobile application interfaces very easily. You write it once and run it on a large set of different mobile devices. Services like mobile push notification, device detection, charging, etc. should also be available. Also the hosting is optimized for mobile applications in which you have very strict low-latency and unreliable connectivity requirements.

Alternative 4: Beat Amazon AWS at Bootstrapping, Configuration Management, and other cloud operation automatization

If you are going to offer virtual servers, focus enormously on the bootstrapping and configuration management. Amazon and others have virtual images that allow a quick deployment of an existing configuration. However that is good if your application is stable and your software stack needs few modifications. Real-life applications and business solutions need a lot more flexibility. Setting up a database cluster, a webserver/proxy/memcache farm, a high-availability loadbalancer, an application server cluster, etc. are very manual tasks on most public clouds. True you can get an image with an apache, tomcat and mysql pre-configured, but you do not get a multi-node cluster image. To solve this you could use software like Chef or Puppet for provisioning and ControlTier or Capistrano for command & control. See my other blog post

Alternative 5: Be the Salesforce for Telecom & Mobile Applications

This is more PaaS then SaaS but being a Telco PaaS in which in a Salesforce.com style you can use Web 2.0 and drag-and-drop to create mobile and telecom applications. Instead of having to code, people can create application via visual designers.

Alternative 6: No.de/Heroku/etc. alternative for quick web & mobile front-ends combined with custom protocols and on-site systems

No.de is PaaS for applications written in Node.js a javascript language that allows for massively scalable applications to be quickly developed.

Heroku is a PaaS for Ruby applications.

These are language specific PaaS that are similar to Google App Engine (GAE).  Where GAE allows Java and Python, No.de has Javascript and Heroku has Ruby. Developers can very easily create applications. However GAE falls short writing front-end applications: Web GUI/Mobile HTML5 quickly. Also integration with non-HTTP protocols is not offered. Although the Internet lets you believe HTTP and FTP are the only protocols out there, there are literally thousands of binary, alternative standards and proprietary systems that large enterprises can not do without. Examples in the telecom industry are RTSP, SS7, etc.  If you can combine the speed of developing modern front-end together with the integration with legacy systems, binary protocols, on-site systems, etc. then you can have a large advantage when corporations want to move their back-office to the cloud.

Alternative 7: The Zoho/37 Signals for Telecom Applications

Zoho and 37 Signals are companies specialized in creating one-purpose mini applications for small and medium enterprises. Instead of a Siebel, Zoho will give you a basic CRM that works out of the box and has virtually no learning curve.

Zoho allows others to build applications on their infrastructure as well and resell them.

The same concept could be applied to telecom. Mini telecom applications like a PBX in the Cloud, SMS marketing, etc. are build on a common infrastructure. Externals can extend the application portfolio and resell them.

Alternative 8: Hosted PaaS

Instead of offering PaaS you offer a hosted PaaS infrastructure for enterprises. Each enterprise gets their own PaaS. Companies like Longjump and WSO2 are in this market. Be sure to add in some telecom assets…

Finding the Container for Long Tail Post-Sales Support

February 4, 2011 1 comment

There are several long tail sales channels that are currently showing results. Clear examples are Amazon, Netflix, Google, etc. However there is a key area that is currently not resolved: long tail post-sales support.

In the telecom world, operators are not launching long tail applications because they can not offer post-sales support. A lot of small innovative solutions are not meeting the public because the operator can not afford consumers or small businesses to call massively their call centers. Every call-center call costs €1 or more and training call center agents on thousands of niche applications is virtually impossible.

A director in a tier 1 operator told me the other day that what we are missing is the container for long tail post-sales support. His logic was that the second biggest invention after the Internet was the container and the pallet. They allowed goods to be shipped cheaply all over the world. The Internet accelerated the purchases but the container made it possible that China and others produced it and the rest of the world consumed it.

We need to find the container for long tail post-sales support. The simple solution that allows people to understand which services and solutions have a best-effort, basic or top-class support and to get their problems resolved in the shortest and easiest way.

What is the problem? An individual programmer can build a very successful application, launch it on a telecom cloud and get virtually overnight thousands of customers. This programmer would be totally overwhelmed with bug reports, feature requests, integration needs, customization needs, training needs,  etc. from thousands of consumers and small businesses. A business can not afford a critical service not to be available during hours or even minutes or seconds. A single programmer might be a guru in building an innovative application but might lack basic skills in supporting it.

The same would be true if we talk about niche solutions, open source solutions, general solutions with long tail plugins, telecom PaaS platforms,  etc.

So do I know what the container is? Not yet but I am actively reviewing different solutions. If you are interested in participating then drop me a line: maarten at telruptive dot com.

 

 

%d bloggers like this: