Strategies for SaaS, Cloud Computing, Governance and Sustainability

As SaaS becomes increasingly the preferred way for delivery and consumption  for all things software, incumbent on-premise vendors are feeling the heat to come up with their own version of SaaS application. Customers unequivocally convinced of the  cost efficiencies of the SaaS model are resenting the hefty support contracts.

The challenge of coming up with a SaaS incarnation when you have a established on-premise customer base is nothing short of what the Big Three Auto manufacturers are going through in re-inventing themselves. The entire thinking software design to delivery and maintenance changes. I will take a look at some of the key challenges and potential solutions.

Lay of the Land

Let us start with a look at a the footprint of a typical large on-premise application deployment.

• Global 2000 company with global deployment of a suite or integrate set of applications covering Financial Management, Supply Chain Management, Human Capital Management and Customer Relationship Management besides some industry specific vertical applications.
• Extensive customizations, localizations, integrations to other applications
• Reporting infrastructure supported by a large data warehouse or some form of redundant data store with aggregated data from one or more sources.
• Company specific security implementation to meet the governance mandates.
• Scalability related deployments like WAN Optimization, Caching, Replication.
• 5-10yrs of historical data.
• All of these managed over private hardware infrastructure that needs large upfront investment and ongoing care-and-feeding.

Just so we get a true sense for what they are up against by establishing the key characteristics of a SaaS application. Granted, the definition of SaaS along with Cloud Computing, Web 2.0 form the troika of terms that have had a hundred interpretations, if not more. But in my mind a true SaaS application would have the following characteristics

1. Single Code base shared across all customers
2. Multi-Tenancy architecture to host all customers in a single instance.
3. Blue-prints/Templates to facilitate rapid on-ramp of new customers.
4. Self Service Administration model
5. Framework to easily integrate external applications
6. Framework to move data from existing applications in bulk

The Challenge

The incumbents see the on-coming SaaS train shaking the very foundation of guaranteed maintenance revenues. In the face of mounting pressure from customers to reduce TCO and also to combat lost sales to upstart SaaS vendors, are responding to this challenge is different ways.

• Some have gone onto create a new product, albeit scaled down version with limited success.
• Some have sprinkled some web-based services to their on-premise offering and claimed victory with some marketing around it.
• Some have just plain made claims that their products have been designed as SaaS from the ground.

To me all this is posturing in deferring the inevitable. They all know SaaS is here to stay (Sorry for ruining your wish Harry) and the on-premise gravy train has run its course and entering its last leg. If the recent customer pushback to a SAP’s one-price-fits-all maintenance contract (driven increase) is any indication, customers are clearly sending the message that they are tired of bearing all the risks, overheads and whims of software vendors.

The Journey

Different companies have embarked on this journey in different ways. There are companies like SAP and Callidus who have created a alternate line of products for SaaS and along with it came a parallel organization who will invariably end up competing against each other. Then there are companies like Oracle, Infor who are re-architecting existing products or new version of their products to support both models. While this seems like nirvana, it is rife with challenges.

Business Model: The foundation of any business is its business model. Moving from a license model based company to a subscription based model creates ripples in the business model. It creates challenging questions around the R&D budgets, revenue streams, revenue recognition and cost of sales as they are going to be dramatically different from what it is in the on-premise world. It is easy to just hope that this Cloud/SaaS stuff would go away.

Sales: Of all people, Sales will have a rude awakening. There will no longer be those front loaded large contracts that will bring in big commissions. SaaS deals are going to be much smaller in size to begin with and then ramp over time. Save for some exceptions like Flextronics deal for Workday or GE deal for Aravo, deal sizes are going to come down a notch from millions to thousands. Just so SaaS sales does not cannibalize the maintenance revenue “gravy train” from existing on-premise customers, they will be out of bounds for SaaS sales team. Hunter & Farmer model, if adopted, will create more heartache for sales guys. They will not be able to engage with customers after the initial sale as they do now.

Marketing: Marketing will no longer be the “all vapor no results” and now unwillingly be bed fellows with sales. Their activities will be scrutinized and tied to ROI more so than ever before. Budgets will be constrained unlike days of the past. As I explained in my post scope of marketing will now expand from demand gen activities to lead qualification and the primary goal would be reduce sales cycle. Webinars, online marketing campaigns, customer/partner communities, customer engagement assume critical nature.

Partners: System Integrators in the good old days would take a product that does not really fit the real needs of the customer would make it work by customizations, integrations, migrations – all for a lowly price of some million dollars. If you had just recovered from the sticker shock of the product, the after shock from SI would enough to make you dig deep into your IT budgets. Now with SaaS, the provider takes onus for many a activity that a SI would have performed. Customers expect the try-before-you-buy deal during which they expect to spend very little, if at all. As a SaaS vendor, you are expected to have integration APIs, Web Services that connect to their in-house apps or other Cloud based apps. This also puts onus on you to have a more finished product and eliminates a shield that SIs provided for product issues in the past.

Product Architecture: This to me is the most under-estimated issue. To say,  “Our architecture is designed from ground up to work for on-premise as well as SaaS” is gross underestimation of the challenge. Just stripping the database for multi-tenancy architecture while essential, makes not a product SaaS ready. Here are things you need to factor in

• You are now going to be responsible for scaling of the application, fail-over, almost zero-downtime maintenance, all this while one issue is enough to cause most, if not all, customers to be at your throat.
• You will have to continuously tweak a single deployment to adapt to the varying workloads in terms of volume, user habits, areas of the application usage, geography.
• If you said, same product will work for both sets of customers, on-premise and SaaS, brace yourself. You will have two sets of customers each expecting different rates of change. Having a product team go full throttle once and hunker down another time is easier said that done. Remember – they say in Good Driver guide – Rapid Acceleration and Sudden Slow Down might not get you where you want to go faster, but it guarantees damage to the engine.
• If you had two different teams for building SaaS and On-premise, then you are dealing with fragmentation of knowledge and skills. Domain experts will now need to stretch themselves to meet the needs of two teams.

Operations: This is a completely new area for a software company. If internal Development Operations was challenging enough, now you are dealing with Data Center challenges, Redundancy, Disaster Recovery, Intrusion Detection, SAS-70 Audits and constant demands from sales team to support them in sales cycle allaying fears of customers. The SLAs asked of you would put you on the hot seat while the budget constraints will continue to ask more of your for less.

Support: In general, the customer support of most enterprise software companies is ordinary at best. Customers are left to fend for themselves and at the mercy of System Integrators, IT Consultants and Community Q&A forums. This in addition to the small army of IT resources in-house. With SaaS, the support tiers suddenly collapse. Vendor is now becomes the helpdesk for not just product issues but also for its availability and performance SLAs. It would be in your own interest to make the product as much self-service as possible to alleviate the strain it is going to put on your support. Fostering a vibrant community to support itself via community owned product documentation, how-tos, case studies would go a long way.

Roadmap: No not the product roadmap, the company roadmap. There is no way a company can keep going with two product lines that demand such divergent needs of the company. There should be plans for the product lines to converge and so also the plan to move customers over to SaaS. While SaaS would continue to drain a lot of money upfront for infrastructure investments while on-premise gravy train continues to fund it. But this can go only for so long. Ask Callidus Software that embarked on such journey as to the amount of (financial) stress it put on them for some quarters.

A few companies like Infor, Plex seem to have made the transition or almost there. It will be interesting to see how this journey shapes up for SAP, Oracle and how they transition from old to new.   While the ever growing list of upstart brand new SaaS startup with no baggage keep creeping into their customer base.