Archive

Fujitsu just presented SaaSification on Cebit. Existing applications can be easily brought to the Cloud and sold via App Stores and SaaS marketplaces. IBM is also working on SaaSification and even adds multi-tenancy.

What is next?

Everybody wants to have a full App Store or SaaS Marketplace, so SaaSification is the next step after launching your store. However converting a client/server application to the Cloud is only step 1. Step 2 is creating new services that are specifically built for the Cloud.

What does Built-for-the-Cloud means?

Application design is changing. Traditional Web applications are built on a LAMP architecture. New Cloud-Ready applications should be Big Data ready and should be looking at SMAQ architectures.

Cloud-Ready applications should also accept the new reality of APIs. Both for exposure as well as consumption. This means that applications need to be redesigned according to application slices.

So if SaaSification wants to be successful then it needs to add quick enablers for multi-tenancy, big data, integration with external APIs as well as API exposure, etc. This integration concept can be called iPaaS or integration platform-as-a-Service. iPaaS should not only focus on exposing or integrating APIs but on providing complex services by integration multiple SaaS solutions together.

Other enablers should be added as well. Basically 80% of a SaaS solution consists out of the same elements or tries to solve the same problems. These could all be provided via a SaaSification PaaS:

Blog – to describe the newest ideas.

Forum – for people to get answers from the community.

IT PaaS – where you run the actual business logic and UI. Data storage is assumed to be provided by the Big Data elements.

Portal and Mobile Portal – allows to quickly define the “static” content for the web and mobile site.

A/B testing – allow new features to be deployed to subsets of users and check which version of a feature has the highest impact on the bottom-line. A/B testing was made popular by Amazon.

Automated testing – lots of testing can be automated but especially end-to-end and performance testing are the harder tests that should be focused on.

Configuration management – manage the version control of the code.

Metering and billing – be able to meter the resource usage by users, companies or any other element you want to meter and be able to bill users both for subscriptions as well as for usage, ideally with advanced set-up with overage, etc.

Marketplace listing and provisioning – automate the listing of products on the marketplace as well as the provisioning of new services.

Reporting and data warehousing – this can be part of the big data stack but especially being able to create ad-hoc reports for instance for A/B testing . Of course regular business reporting needs to be included as well.

ERP – accounting, resource management, etc.

CRM – sales and lead management

Operations & Maintenance – automation of back-ups, monitoring both for the performance and fault management but as well business monitoring.

The idea is not that a SaaSification PaaS offers all these solutions by custom development. Instead the SaaSification PaaS should allow startups to assemble an ideal architecture by combining different solutions from different providers. For example you would be able to select the support solution you prefer, e.g. desk.com, zendesk.com, etc. and this solution would be completely integrated into the overall stack, e.g. CRM integration with help desk and fault management together with sign sign-on.

SaaSification 2.0 should focus on making sure that 2-5 people can start a new dotcom solution and focus on creating a killer service and not on building up yet another stack of solutions for configuration management, support, billing, etc. If a SaaSification PaaS can shorten the time to launch with months and reduce the needs to operate the solution with several people then startups will see the value. Instead of SaaSification PaaS a good term could be Incubation PaaS, to incubate SaaS solutions. Once the business model and solution is proven, there will be money to move to a custom-build stack but during incubation and crossing-the-chasm enterpreneurs should be able to focus on delivering value to their customers and not on re-inventing the startup wheel.

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.

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).

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.

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.