As SaaS increasingly becomes 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 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 from business model, pricing, software design, delivery, maintenance and support 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 a 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 home grown or best-of-breed applications
• Reporting infrastructure supported by a large data warehouse or some form of redundant data store with aggregate data from one or more sources.
• Company specific security, audit implementation to meet the governance mandates.
• Scalability related architecture including Load Balancers, WAN Optimization, Caching, Replication.
• 5-10yrs of historical data.
• All of these managed over private hardware infrastructure that has invested cost, the resources and ongoing care-and-feeding.

Just so we get a true sense for what they are up against let me establish the key characteristics of a SaaS application. 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 (or at worst for scalability or maintenance reasons a fixed number of instances).
3. Blue-prints/Templates to facilitate rapid on-ramp of new customers.
4. Self Service Administration model for companies to manage their user base and usage.
5. Web Services framework to easily integrate external applications
6. Data Interconnect framework to move data from existing applications in bulk.

The Challenge

The incumbents of traditional software arena 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, incumbents 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 complement their on-premise offering and claimed victory, with some fancy marketing around it.
• Some have just made plain claims that their products have been designed to run as on-premise and SaaS from the ground up.

If you ask me, all this is posturing, in deferring the inevitable. They all know SaaS is here to stay (Sorry for ruining your wish Harry). 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 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. Then there are companies like Oracle, Infor who are re-architecting existing products or creating a 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 perpetual license model 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. It is easy to just hope that this SaaS stuff is a fad and would go away like Harry did.

Sales

Of all people, Sales will have a rude awakening. There will no longer be those large front loaded 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. Companies like SAP have adopted the “Don’t go near my on-premise customer” approach just so SaaS sales does not cannibalize the maintenance revenue “gravy train”. The most commonly used sales model in SaaS, Hunters and Farmers, 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 need to be bed fellows with sales. Their activities will be scrutinized and tied to ROI more so than ever before. As I explained in my post scope of marketing will now expand from demand generation activities to lead qualification and the primary goal would be reduce sales cycle. The key focus in SaaS is to keep the Cost of Sales down. So marketing will be asked to nurturing the leads and leave the sales to close the deal. Inbound marketing is more important than outbound. Webinars, online marketing campaigns, customer/partner communities, customer engagement assume critical nature. Given that the sales model is get-the-foot-in-the-door and the expand, marketing will also be expected to help with up sell by generating interest in the overall product.

Ecosystem

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 a few million dollars. For companies, that had just borne the cost of software, the hardware infrastructure, the resources, the implementation costs come as a additional cost. With SaaS, the service provider takes the onus of most of the activities  that a SI would have performed. Customers expect the try-before-you-buy trials to evaluate the product 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 the SaaS vendor to have a 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  makes not a product SaaS ready. Here are things you need to factor in

• SaaS vendor is now going to be responsible for scaling of the application, fail-over, almost zero-downtime maintenance. In fact, the SaaS vendor will be responsible for meeting the SLAs with penalties for any lapse.
• The application will have to adapt to the varying workloads in terms of volume, user habits, areas of the application usage, geography. Making that happen is SaaS vendor’s responsibility.
• 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. The cycles of product updates are much more frequent in SaaS than an on-premise product. So for those saying, that they will support both SaaS and on-premise customers with the same product, imagine the challenge.
• 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. The SLAs asked of you would put you on the hot seat while the budget constraints will continue to ask more of you for less.

Support

In general, the customer support of most enterprise software companies is ordinary at best. Customers are left to fend for themselves or at the mercy of System Integrators, IT Consultants and Community Q&A forums. This is besides the small army of IT resources in-house. With SaaS, the support tiers suddenly collapse. Vendor is now becomes the help desk 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 and on-premise gravy train continue 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 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.