Telruptive

Although the number of solutions Amazon AWS is offering has become very large, here are 5 ideas of what Amazon could be adding next.

API Marketplaces

There are thousands of APIs out there. However what is missing is an easy way for companies to control their costs. In line with other marketplaces Amazon runs, there could be an API marketplace. An API marketplace would allow third-party API providers to let Amazon do the charging. Companies would be able to pay one bill to Amazon AWS and use thousands of APIs. Also third-party API providers would be winning because they often can not charge small amounts to a large set of developers. Amazon already sends you a bill or charges your credit card, hence adding some dollar/euro cents for external API usage would be easy to do. The third-party API provider would avoid having to lock-in users in large monthly usage fees to offset credit card and management charges. Amazon of course would be the big winner because they could get a revenue share on these thousands of APIs. End-users would also be winning because they can easily compare different APIs and get community feedback from other developers and pick those APIs with the best reputation. The typical advantages of any online marketplace. Also cross-selling, advertisement, etc. and other areas can be reused by Amazon. A final advantage would even be to have Amazon be in the middle and offer a standard interface with third-parties offering competing implementations. This would allow developers to easily switch providers.

Language APIs

A lot of applications would be helped if they could use language APIs that are paid per request. Language APIs is a group name for text-to-speech, speech recognition, natural language processing, even mood analysis APIs. These are all APIs that are available individually but there is a clear economies of scale effect. The more speech you transcribe or text documents you process, the better your algorithms become. Also there is an over-supply of English language APIs but an under-supply of any other language in the world, except for Spanish, French and German perhaps. Another problem with existing APIs is that a high monthly volume is needed in the even the most basic subscription plan. Examples are Acapela VaaS pricing that costs a minimum of €1500. Very few applications will use this amount of voice.

M2M APIs and Services

Amazon is already working hard on Big Data solutions. M2M sensors can generate large volumes of data pretty quickly. S3 or DynamoDB would be ideal to store this data. However what is missing is an easy way to connect and manage large number of sensors and devices and their accompanying applications. There are few standards but with examples like Pachube, Amazon should be able to get inspired. Especially the end-to-end service management, provisioning, SLA management, etc. could use a big boost from a disruptive innovator like Amazon. Also M2M sensor intelligence could be offered from Amazon, see my other article about this subject.

Mobile APIs and Solutions

With billions of phones out there, mobilizing the Web will be the next challenge. Securely exposing company data, applications and processes towards mobile devices is a challenge today. BYOD, bring-your-own-device, is a headache for CIOs. We do not all have a MAC so we can not sign iPhone apps and launch them on the App Store. Ideally there would be a technical solution for enterprises to manage private app stores, deploy apps on different devices and be able to send notification to all or subsets of their employees. Also functionality like Usergrid in which developers would not have to focus on the backoffice logic would be of interest. Also tools to develop front-end for different devices would be appreciated, examples like Tiggzi come to mind. There are a lot of island solutions but few really integrated total solutions.

Support APIs and Services

Amazon is becoming more and more important in the global IT infrastructure business. This means that solutions will move more and more to the Cloud and sometimes be hybrid cloud. With these complex solution scenarios in which third-parties, Amazon and on-site enterprise services have to be combined, risks of things going wrong are high. Support services both from a technical point of view:

• detect failures and to automatically try to solve them
• manage support ticket distributions between different partners
• measure SLAs
• etc.

as well as from a functional point of view:

• dynamic call centers with temporary agents
• 3rd party certification programs in case small partners do not have local resources
• 3rd party support marketplace to offer more competition and compare reputations
• etc.

are all areas in which global solutions could disrupt local and island solutions that are currently in place.

Cloud Computing is reaching the tipping point. SaaS is on the verge to balloon. Mobile apps are moving to the enterprise as we speak. Small, medium and large companies will need to mobilize their back office systems.

What better a solution can operators offer then a mobile SaaS enablement platform? A platform in the cloud that allows companies to connect in a secure way their back office systems and to expose internal data to third-party mobile SaaS. Hundreds of small software companies can be making specialized mobile SaaS offerings to allow companies to easily “approve travel expenses”, “monitor KPIs on the go”, “remotely reserve a meeting room”, etc.

Unified Back-office Exposure

Companies would find tools to expose internal data sources and back-office systems as web services. Data islands are exposed and protected via technologies like oAuth. User management and security are managed from a central dashboard. Unified web services interfaces can standardize the exposure of different back-office systems, allowing for mobile SaaS applications to work independent from for instance the back-office ERP that is being used.

The operator is the perfect companion to expose internal resources via secure communication links.

SaaS Builders

Developers can find a list of tools that take the repetitive tasks out of creating SaaS. Federated user management, multi-tenancy data store, mobile interface designer, integration frameworks (messaging, web services, oAuth, etc.), virtual application servers, long tail monetizing tools (e.g. subscription management), on-demand call center  and CRM tools for support, etc.

Enterprise App Stores

Employees can access enterprise app stores in which they can use mobile SaaS applications, either on subscription basis (hourly, daily, monthly, yearly, etc.) or after one-time purchasing. Everything goes immediately on the cost center of their department after manual or automatic approval and is paid via the enterprise’s telecom invoice.

Long Tail Support

Eco-systems of support organizations, on-demand call centers, online trainings and certification programs, etc. can all make sure that enterprises get the support they need.

Show me the money

Operators can charge for sign-up or listing fees, get revenue shares from mobile app sales and support subscriptions, etc. Developers can move solutions from public app stores to enterprise app stores and charge instead of €0.79, several (tens of)  euros as a one-time or subscription fee. Software would no longer have to be purchased by IT but can be “used when needed” and only paid for when it really solves a business problem. Also end-users would be able to use the software they really need and not have to wait for a corporate policy update.

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.

In a previous post I shared that I was looking for the container for long tail post-sales support.

Today I would like to present a draft proposal. Feedback is very welcome. The idea is to simplify support to a 0 to 5 stars model:

0 stars: No support.
1 star: Best-effort / community support
2 stars: Basic 8×5 SLA with no penalties and web/email support,  daily scheduled maintenance windows possible.
3 stars: Basic 8×5 SLA with limited penalties and phone/web/email support, nightly scheduled maintenance windows possible.
4 stars: Advanced 24×7 SLA with significant penalties, phone/web/email support, and limited off-peak (e.g. weekend nights) scheduled maintenance windows
5 stars: Mission critical 24×7 SLA with high penalties, on-site support and no scheduled maintenance windows

Additionally the operator would be measuring both the availability of the service,  the responsiveness of the support, and the buyer’s satisfaction rates hence not only the “theoretical SLA” is available to potential buyers but the last 12-months of actual performance as well.

By having a simple star system, small and medium enterprises would immediately be able to compare a 1 star with a 5 star support. Afterwards within each star level there might parameters that can differ like the amount of penalties, the 8×5 time zone, the nature and limits of the schedule maintenance windows, etc. So there is still flexibility and potential to differentiate through support.

Having a standard support offering would be one step closer for buyers to be able to understand what they are buying and for operators to be assured that companies offer a standardized high-quality service.

Standardization bodies could even make contract templates, certification programs, etc. to make sure post-sales support is uniform and easily understandable.

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.

Launching thousands of services in a long tail marketplace might not be as hard as it used to be. However supporting millions of users with these thousands of services definitely is. Technology seems not to be the limitation of telco long tail, support and monetization are.

What support is needed?

Consumers as well as small, medium and large enterprises have different support needs. For simplicity let’s focus on small and medium. Hundreds of thousands of those are available in most countries. Often IT skills are in the best case basic. No dedicated IT staff. Just a helpful colleague if any. Time and resource shortage are plenty.

Before reaping the benefit of any long tail service, people will have to learn about what is being offered: product awareness. Additionally once the product is purchased, help with configuration/customization, product training, product integration, consultancy, product questions, etc. Finally when things go wrong: rapid workarounds and bug fixes.

Traditionally telecom operators have used sales teams, help desks and support  organizations to offer more basic types of support. Scaling these organizations up to provide the previously listed items is often not possible. And if it were, it would be economically inviable.

Why is long tail support different?

Google, among others, promotes a services-based marketplace inside  its Google App Marketplace. Although a step in the right direction, it will not resolve all the issues.

These long tail services could be an answer for established brands and the more straight-forward support tasks like product training. However a developer that on a Sunday afternoon builds a cool app and all of a sudden is surprised that 50.000 companies downloaded it on Monday, is not able to offer any reasonable support.

What do small mom&pops support services need?

Specialization and economies of scale would be two key factors. The “lucky developer” has specialized skills around application development. However does he or she has knowledge about how to integrate a corporate single sign-on solution into it? Probably not. Also when the developer will be helping one company, he will not have time to help another one.

So our “lucky developer” will need people with additional skills and be able to increase his/her bandwidth.

Option 1: Community Support

By offering the tools on the marketplace for an online support community to build around this “lucky app”, companies can help one another and don’t repeatedly ask the developer the same type of questions. Some communities have demonstrated to be offering faster and better support then most commercial support organizations. However there is a problem here. Bug fixes can only be provided by the “lucky developer”. (S)He can choose to open source the application code but that would very likely allow others to quickly copy and extend the app and destroy all market advantage.

Option 2: Commercial Product Support

The “lucky developer” can foresee potential success and hire some external company that gets trained on the app and is able to resolve most of the bug fixes. A trusted third-party that can have an escrow with the “lucky developer” and take over development in case something happens to him or her.

However this would take time and would only take place for those apps that have a steady growth to success, not an overnight craze.

Some tools could be beneficial here.  Version control to share proprietary code with authorized third-parties to let them generate patches and in case of a deployed application access to a mechanism to test and deploy an updated version. Also standardized CRM solutions and multi-channel helpdesk access can offer a unified and high-quality service even for one person support companies.

Option 3: Commercial Specialized Services

Even if a third-party company gets trained on a product, this does not take away that customers will demand specialized services that are outside of the scope of product support. Examples could be security audits, SLAs about service availability, integration support & consultancy, performance benchmarking, commercial volume discounts & pricing, marketing, legal support, etc.

By itself this can be a totally new services marketplace in which both the “lucky programmer” as well as its customers can contract these services.

Tools are completely different based on which service is offered so standardized tools are difficult. Probably tools could become SaaS offerings from third-parties.

Option 4: Reputation

Bringing together community support, commercial product support and commercial specialized services is not enough by itself. All tools will not help without one key aspect: reputation.

How can the “lucky programmer” differentiate between 50 lawyers, 350 security experts, 20 performance benchmarking firms, 30 SLA validation agencies, 120 technical support help-desks,  etc.? The answer is reputation.

If a security expert has found security holes in some of the most famous Internet sites and he certifies your application then this means that your application is having a reputation of being save. The higher the reputation, probably the higher the fees the “lucky programmer” has to pay.  So not everybody will be able to afford the best, especially in the beginning. But then again, sometimes companies with a top reputation might want to offer their services for free for those “lucky programmers” that are likely to get them free press.

The same is true for buyers. If you see that an SLA validation authority, that is generally trusted, is certifying that the services was up for 99,9999% in the last 24 months then you probably want to buy this service over a service that is slightly cheaper but has no reputation for reliability. Also you will want  to buy bug fixing support from an organization that was able to meet a very tough SLA in the last 24 months and has all its customers raving about it.