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?
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.
- Deployment management – ideally continuous deployment or integration tools that allow fast feature by feature deployment.
- 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.
- Single sign-on & identity management – allow companies to use their own user credentials (e.g. SAML), authorization for third-parties (e.g. oAuth), etc.
- 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.
- Support – helpdesk, ticketing system, SLA management, etc.
- Social integration – tools to add social aspects like Facebook apps, Twitter feeds, etc.
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.
A long list of startups are making it easier every day to create and customize value-added services. These tools mainly focus on two segments:
- soho and small enterprises with visual PBX, call center as a service, etc.
- consumer oriented with voicemail, mobile apps, etc.
The main players in this new market are small startups. Companies like Twilio with OpenVBX, Invox / PBXPlus, etc. Also some established players offer solutions: e.g. App Inventor and Voice from Google, Yuave from Nokia Siemens Networks, etc.
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.
Most operators have a mobile portal in which end-users can buy games, applications, ringtones, etc. Several operators have a legacy of server hosting, email hosting, and other business services. Some operators have a marketplace where small medium enterprises can buy SaaS. Others are thinking or building a private cloud and want to become an infrastructure as a service provider. Often to avoid legacy hosting to disappear.
There can be reasons why a small, medium or large enterprise wants to use the infrastructure from an operator compared to a public cloud: SLAs, quality of network service, security, etc. Price is very likely not going to be one of them. Neither will be innovation or flexibility because here the likes of Amazon, Google and Microsoft are almost impossible to beat.
So why is it that operators think that IaaS is their preferred strategy to enter the cloud? I have no idea but my opinion is that it is easier to start with SaaS and work down to PaaS then to start at IaaS and work upwards. IaaS will have hyper-competition and very small margins as a consequence…
An alternative telco cloud strategy
Operators often have a direct sales channel towards medium-sized enterprises. By offering a SaaS marketplace they could extend the amount of services they are providing towards these medium enterprises. After reaching a tipping point, smaller enterprises will likely follow via direct web-based purchases. However reselling SaaS can never be a long-term strategy.
SaaS should be an initial start of a new customer relationship. Operators should focus on selling complete solutions focused on a specific industry or problem domain. Examples:
* Healthcare – web, mobile, tablet, TV and SMS patient reminder & reservation system, health-care call-center as a service, farmacy locator,web-based medicine reservation system, etc.
* Restaurant – web, mobile, tablet, TV and SMS table reservation system, online menu web hosting, group-based or community food purchasing service, special deals á la groupon.com, etc.
* Car dealers – web, mobile, tablet, TV and SMS maintenance reminder & reservation system, parts-locator call-center as a service, etc.
The operator should not focus on inventing these services but instead on creating the tools, the eco-system and the community for smaller IT shops and other to come up with scalable niche services.
To fully utilize a SaaS an SME needs help: training, configuration, customization, integration, etc. For this you need a services marketpace closely linked to your SaaS marketplace. As well as a long tail support solution.
The Long Tail Telco PaaS
To be really able to offer long tail services, operators need to have a long tail Telco Paas. A Telco PaaS is like a Google App Engine, combined with Google App Marketplace, combined with Twilio/OpenVBX, combined with charging on your invoice, combined with open standards like OpenID, oAuth,SIP, etc.
Not clear??? A small company knows best what another small company need. However they do not have the infrastructure to reach and help thousands of other small companies in the world that have the same problem. This is where the operator should help both with global communication and IT solutions. A small company should not be focusing on installing a CRM, call center, ERP, etc. if they want to help others configuring and customizing a health care reminder service. They should have specialists in the health care reminder service and should be able to purchase the rest from the Long Tail Telco’s marketplace. They should also be able to auction a request for legal assistance, escrow-service, translation, etc., basically an all-in deal. The operator should focus on business communication in the broad sense, not the telephone service sense…