I have been working with a SaaS provider to help them define metrics that should be measured, monitored and correlated to business metrics. Thought it would be useful for others who might be in SaaS business. While there are other metrics that SaaS companies should track like Annual Contract Value (ACV), Total Contract Value (TCV), and Monthly Recurring Revenue (MRR) etc from a finance/profitability point of view, I will focus on operational metrics that help you build customer success in this post.

Usage Metrics

• Application Logins: it is always a critical statistic to measure how many users are signing onto the application. It not only talks to the scale of the application, it also demonstrates the critical nature of the application. If you broke down the logins by the role of users in the application – for example a HR Manager versus a VP of Talent Management, and individual usage patterns should help drive focus areas in your product roadmap. Marketing can use this same information to create day-in-a-life documents or case studies on the critical nature of the application. Operations can use the metric # of logins as a way to demonstrate the scale, SLA and also determine peak/off-peak usage patterns for performance benchmarking, planning scheduled downtime etc.

• Time Spent in the application: Time spent in the application is something a company should always be proud of. It talks to the stickiness of the application. While that is something marketing can use to demonstrate the value of the product, product teams should inspect the same metric to identify potential areas for optimization. In this day and age, users seek smart business processes that are not click-hungry and easy to accomplish. So users spending longer time on a given process could imply productivity loss and in the long run could lead to unhappy users. Client Services should look at this metric to identify opportunities for training (or lack thereof). It is always critical to benchmark a typical lifecycle of a business process and see if there are reasons to be concerned if deviation from the benchmark is large.

• Access Mechanisms: As such most SaaS applications are accessed using a browser. But with the browser wars looming again it is important for a product team to measure and compare the different browser usage – Firefox, Chrome, Safari and the Goliath – Internet Explorer. Besides the different browsers, it is critical to measure the versions of each. With effective logging of sessions, this information should be easy to capture. Besides browser, it is also important to capture information around
  • Desktop Operating System (Windows, Mac, Linux)
  • Monitor Resolution
  • Platform (Desktop Vs Mobile)
  • Languages used
  • Bandwidth used (DSL, T1, Dial-up)

  Product teams can use this information to improve testing coverage,   support for specific browsers (versions). Marketing can use this same information to highlight to the broad capabilities of the product/platform. Sales will require this information for the RFP they complete as part of a sales deal.

• Source of Users: Where your users are accessing your application from is a key important metric from multiple angles. If you are in Sales, you probably know your customers in various geographies. Facts about the density of users from a particular geography might indicate better adoption rates and need for increased sales efforts. For product team, this might drive decisions around caching strategies, internationalization or localization needs, increase in latency based tests. If you are in marketing you will now be able to leverage customers from various geographies to provide you localized references in marketing efforts.  Operations can factor this information to gauge the coverage of the redundant data centers created to cater to global users.  For those with one active data center, this could provide insights to support that second data center plans you were putting in place.

• Nature of Business Activity (Quotes created, Search conducted): Capturing metrics around the key activities performed in the application like creating orders, creating versions, search conducted, user roles created, projects created, surveys conducted, documents uploaded are all great ways to measure the coverage of usage of the application. The product team can use this information to crosscheck with the roadmap and identify the cause for lack of usage in certain areas. Follow that up with discussions with customers that requested those features to better understand the effectiveness of the product feature. For instance a large number of document uploads might indicate companies using documents in lieu of  structured business process and identify opportunities for expansion of product footprint. Operations can use the same metric of large number of document uploads to determine if storage configuration should be optimized or potential for using de-duplication technology.

Operational Metrics provide additional insights in the user behavior and indicate hidden opportunities to improve.

• Tickets logged: Not the most favorite metrics for any constituents in the service provider company.  But I have a bright side. It is much better than not have any tickets at all – atleast you know your product is used. While it is standard to bucket tickets into product areas, I recommend you break down tickets into those logged by new users, critical areas of business process and specifically those logged during critical dates (month end, quarter end and year end). The easier you make new users to adopt the application, reduce the instances of fall-over the more purpose with which they will use the application. The more they will talk about your application. Conversely, the more troubling it is to get accustomed to the application the sooner they will desert it. Critical areas in business process and critical dates need no highlighting as to why they are important.
• Time outs: Timeouts in my opinion are the worst kind of issues. In addition to creating a bad perception of the product, they also could point to infrastructure issues, missed test cases. They also put client services in a bad spot where they cannot explain the cause unlike a product deficiency. Considering that it is not always possible to root out all time out issues due to the varying nature of access (cable, dsl etc), it a great idea for client services to have a “Have you checked this?” list. Worst of all are those that happen during crucial demos to prospects.
• Downtime: While unplanned downtime is bad and puts your CEO in the news for the wrong reasons, planned downtime is equally painful from the customer point of view. Given the round-the-clock nature of world we live in, people extend their work lives to evenings and weekends. So having excessive downtime and more so, those that went over the announced window need to analyzed. No one likes to work on weekend and if you cancel plans to work on weekends only to find out that downtime window has been extended would not make for a happy user on Monday.
• User growth over time: This is a no-brainer of a metric. Tracking user base growth and charting the patterns gives you a view of buying habits, correlation of success of campaigns and what you do well. It also show the times when you should increase thrust on your sales/marketing campaigns.

This was a representative sample of metrics we identified and started tracking. The list extended to sales, marketing and implementation to track success in converting leads, success in converting trial users, investment done in implementation cycles, training cycles – I am sure you catch the drift.

All these metrics once identified and tracked, can be part of a dashboard that all employees in the company has access to. Make sure to include those as discussion items in company meetings and goal settings for each executive.

SaaS companies, it seems like, took the easy route and started using the model that has been a staple of hardware industry (100GB hard disk costs $50 and 500GB costs $100) or the Storage Container vendors (100sqft – $10/month, 250sqft – $25/month). It worked great for hard-disk vendors as they operate in volume business, the more SKUs they sell the more money they make. Hard-disks have limited shelf-life, SaaS software is different. Also it is fine if you want to be in the commodity storage business like the cloud-based storage vendor Amazon S3. With SaaS, it is not so much the software that your are selling, it is the relationship. You are essentially a trading partner who the client relies on to run his business. The last thing SaaS vendors want to do is to look like wireless service providers – bargain basement prices for initial storage quota then the overages kicking in.

With that said, what should the SaaS company do with all the costs incurred? Should they absorb them as Cost-of-Goods Sold (COGS)?

Tactically, yes. They are COGS that need to be absorbed, but I take a different view and look at it as an investment. For one, you take one thing off the contract that the client has to constantly keep track of to avoid being slammed by overages. This, if anything, will allow them to use the system unfettered. The SaaS sales is predicated on the land-and-expand model, where you sign customers up for a small subset of use-cases that you can solve, while continuing to sell the long term vision. This keeps your sales cycle small and also affords a quick ROI for customers. With that as key focus, the last thing you want is, for customers to use your system partially and conduct business offline or in another application.

I would strongly encourage SaaS vendors to take a leaf out of the large malls operators’ thinking – they ensure abundant free parking and let customers spend as much time at the mall as they wish. The more time they spend at the mall, the more the cash counters ring. Last thing they want is customers going to another mall just because they could not find parking space.

So how could a SaaS vendor benefit from relaxing space quotas ? ( Did I mention I have a particular disgust for this word? Coming from India where every job opportunity, school admission, membership has caste based quotas perpetuated by politicians in lieu of vote banks) .

Here are some strategies to adopt.

1. One of the key advantages of going to a SaaS model is the continuous access to the user behavior that it affords. If you have lived through the old on-premise build-and-throw-across-the-wall model, you can appreciate the value of having access to the end customer without filters. You are not just going to have access to customers, you are also going to see what they are doing as opposed to what they think they are doing. This is a product manager’s dream. To draw upon the user’s behavior to determine the roadmap. So measure, monitor and rationalize the usage. You will find nuggets of information that will help you identify revenue opportunities in your product that will more than compensate for the lost space costs.
2. As an extension to 1, based on the data insights, introduce features like Surveys, Viral marketing opportunities to increase engagement, increase demand for your products. Your marketing team might be paying millions to get this kind of information to base their campaigns. No better source that the user community that is already using the system. Engage with the users based on the view you get to conduct Day-in-a-life, Case Studies, ROI studies. All these are real proof for the value your system delivers resulting in increased demand.
3. Companies are still document happy as it is the most easily transportable container of information. So don’t be surprised if you see companies consuming a lot of space quota (spare the itch to bill them for it) using documents in lieu of using the application to its fullest. Identify the causes and there might be additional opportunities to expand your product footprint.
4. Identify the value that your customers can derive from aggregate information across their industry or target industry. The more the usage, the more diversity in the data you will see. Unless you are one of those expense or task management applications (sorry no disrespect). Diverse data gives you good basis to make product decisions.
5. Guess what people would want when the data gets un-manageable?. Tools and capabilities to mine them. There is the opportunity to build out new high value capabilities (and upsell – Ka-Ching!) that could bring new user-base into your application. Think Executive Dashboards. If you did not know, the corner offices pay big bucks for everything. If you don’t believe me ask – Dennis Kozlowski and John Thain.

That is my rant on this topic. Would love to hear what others think. I would be happy to discuss more in detail with anyone interested.

Let us start with examining the raison d’etre of Open Source. Open Source made its entry with a bang with the introduction of Linux operating system. These were the days when Unix vendors and Microsoft were doing very little innovation besides suing each other and banking large license deals. Linux represented the rebellion against the proprietary operating system vendors and put the power in the hands of the masses to innovate and contribute towards a larger goal that each of them by themselves would not have been able to accomplish. The appeal of a free operating system with inexpensive support (or no support if you were brave enough to lean on the community) was just what the doctor had ordered. It was the equivalent of generics in the world of pharmaceuticals – just-as-good but at one-third the cost. The fact that Linux would work on commodity hardware amounted to double dipping for companies. Cost Reduction++.

Despite starting off as a low-end pretender to the incumbents, thanks to the rate of innovation Linux has caught up with all the high end operating systems – some would even say it is better. The success of linux opened the floodgates of open source offerings in all area like databases (MySQL, PostgreSQL), System Management Tools (Nagios, Zenoss), Content Management (Alfresco, Drupal) and even to mission critical business applications (Compiere, SugarCRM, Apache OFBiz). Not limiting itself to end products, Open Source has since moved into platforms (Apache, JBoss, LAMP, Zend) upon which ISVs or IT shops have built their products.

So far so good. Open Source was on cruise-control seemingly crossing more frontiers.

Then came the SaaS wave. SaaS posited that it was absurd for companies in the non-technology business to each spend large amounts of resources and manage their own IT infrastructure. Companies were better off focusing on their core business and leave IT Management to the experts. They also proposed hosting and managing software and letting companies use them in a subscription-based model, thereby helping companies manage their ballooning IT spend. After the initial spurn, the world seems to have come around and accepted the notion of SaaS. Armed with economies of scale through multi-tenancy, virtualization (the coincidental wide adoption of broadband), SaaS is now providing solutions ranging from edge apps like Email (Google Apps), Sales Management (Salesforce.com) to business critical applications like Financial Management (Intacct), ERP(Netsuite), Human Capital Management(SuccessFactors,Workday, Taleo), Product Lifecycle Management (Arena Solutions), Security(Symantec), Identity Management (Symplified).

With SaaS, companies/customers need to concern themselves only with the service availability and forgo the IT nightmare. No more software license, upgrades, maintenance, army of IT people, backups. All that is packaged into a single subscription fee paid on a as-used basis.

Riding on the coattails of SaaS, its brethren – Infrastructure-as-a-Service and Platform-as-a-Service are now wooing outlier custom projects onto pay-as-you-go, focus-on-your-core-business platforms. They take away the complexity in the infrastructure and technology platform giving you the similar benefits as SaaS.

What does all this mean to Open Source? Does this mean the target customer base for open source companies would soon be dwindle down to the SaaS ISVs, PaaS vendors?

The biggest challenge dealt to Open Source by SaaS would be that with Open Source, while the costs of licensing and maintenance are reduced, companies will still bear the responsibilities of building their own solutions and maintenance. This would mean that companies need to continue to spend on maintaining large IT resource pool and deal with the vagarities of complex technology integration. The entire premise of SaaS hits at this very pain.

That said, if you are a CEO of a Open Source company, you should not be immediately concerned about customer base seemingly dwindling with every gain of market share by SaaS/PaaS vendors. At the same time here are three things to think about

1. Open Source represents the single biggest large collaboration, crowd-sourcing based successful innovation models of our times. There are many other industries trying to borrow what-has-worked in Open Source and apply it to their industries. So while many open source companies are looking to cash out selling themselves to proprietary vendors (MySQL, Xen, SpringSource.. the list goes on), it serves you well to keep expanding the engagement with community and serving their interests. There will be a open source shakeout – lot of “gimmicky” open source vendors who just have a useless community edition product will wither away. The longer you can keep your innovation going, the more longer you will be viable.
2. Consider having a SaaS (or atleast a hosted subscription service) for your Open Source application. Software technologies will only be delivered through subscription in 5-10 years from now. Use this time to establish that presence while you still have a license business.
3. Join hands with other Open Source vendors and create platforms/applications that are integrated and easy to consume and maintain. This should not just be limited to technology integration but also in the areas of upgrades, support and documentation. RedHat has done a great job in integrating all their offerings into the JBoss Suite and reducing the complexity for their customers. Doing this will address both the value delivered by PaaS and the overhead requirements that customers have today in stitching together multiple open source offerings. I see a future where co-operative platforms where multiple vendors contribute to make up the platform and its ongoing success.

The idea of this is to create discussion from both the Open Source and SaaS/PaaS die-hards. Like it or not, if you look further ahead, this is head-to-head is going to happen, no way around it.

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.

Anyway I digress. Now that we have had a successful year of market share gains for SaaS vendors behind us, it is time for CEOs of SaaS companies to make their new year resolutions. Having spent some time meeting CEOs of SaaS companies and their clients, I thought the least I could do is to create a new year resolution template to help them out. So here goes.

Resolution #1: Improve Customer Service: My customers have been incessantly complaining of lack of adequate customer service. This coming year we will spend enough money and resources to provide A+ service, excellent documentation and foster a community that can support itself. After all, we will need customer references to gain new customers now that we have cornered the easy pickings. The last thing we want when the economy recovers is for the customers to move in droves, to a competitor.

Resolution #2: Provide better on-ramp process: We managed to get a bunch of customers online – kicking and screaming. Not to mention, our profit margins on those customers went down the toilet. Considering that we do not need to spend all that money on cross-platform porting/certifications, on supporting multiple versions concurrently, we should make it easy to get new customers online and using the product.

Resolution #3: Provide a real integration framework: Following up on my previous resolution, we should make sure the engineering team designs the product with the knowledge that we will not be an island onto ourselves. Companies require that the information loop is closed with their other cloud applications or existing on-premise (or do those fall under the category- Clunkers now?) applications. Standard APIs/Web Services should be moved from nice-to-have bucket to must-have bucket early this year. In fact, we should be working with our customers to identify the adapters that we should be providing out of the box. This will then make good on all the blabber we made about TCO during the sales cycle.

Resolution #4: Be the best customer advocate I can be: I MUST become the biggest customer advocate in the company. I don’t need to be the great visionary all the time. Customers have made big commitments by taking a chance on us and signing up to our service. Now it is my job to support them and help them succeed in their business. While I am at it, I should make it a point to ensure my entire organization makes only those commitments that they can follow through. Memo to Sales team – “SaaS is not a hit-and-run sale, we will be engaging with the customers for a long time, so let us not start on a wrong footing by promising the impossible/non-existent.”

Resolution #5: Be Transparent: Every time we had service outage this year, we have had to have a embarrassing meeting to customers/press. This year invest in being transparent. Trust builds when we are transparent. Do what Intacct and Big Dog Salesforce.com has done with their service level dashboards. We definitely do not want to have a public boo-boo day like Workday did. While am at it,  I must put in place a process to share the audit certification and governance reports as well with our customers.

As a CEO if I follow-through on all these resolutions and we execute we  should be able to have another great growth year ahead while keeping the customer churn down. Now that I have captured my resolutions, it is MBO time for VP of Products, Service and Sales !!

Starting with delivery model, architecture, sales, support companies, employees and customers need to get used to a new way of doing things. If you are one of the decision makers on either side of the transaction, the SaaS vendor or the Customer considering buying SaaS, there are a variety of legal issues you need to contend with.

Bruce Cleveland, a SaaS veteran and a pioneer of on-demand business while running the Siebel On-Demand, now a VC with Interwest Partners, must have been one of the first few to enter this uncharted territory. Defining new pricing model, subscription agreement, Service Level Agreements (SLA) is just the beginning. As a vendor you need to ensure you have backing agreements with your service providers like hosting company, license software providers for you to be able to meet all your commitments to your customers.

Bruce shared a detailed Q&A session on SaaS business model and legal issues, he had with his legal attorney during Siebel days, Cary Platkin of Platkin Law, on his blog. If you are starting off in your SaaS journey, this serves as a good starting reference.

Cary goes on to explain the basics of a Subscription Agreement and risk mitigation/sharing strategies by using similar or better back-to-back terms with your vendor. The larger your customer base, larger you share of the risks are.

SLAs are critical in providing services that customers run their business on. Most SaaS companies guarantee anywhere 99.5% to 99.9% up-time as part of their SLAs. As Cary rightly points out, most and the best SaaS providers have outages or unplanned downtime. So keeping that in mind, factor the availability, response times, performance commitments, Disaster Recovery commitments, while drafting a SLA. Service credits are becoming a critical part of SLAs. But in my experience after a service has delivered enough value to the them, (make sure you keep that as your focus), customers are more forgiving that you might think. We once had a service credit report of 250k (across a year) whittled down to a mere low thousand of dollars, when all was said and done.

Besides outage, data breach or leaks are the most concerning issue that will be raised by customers during contract negotiation. Customers are getting more educated on the Data Security concerns and the necessary process and infrastructure needs around Data Security to meet their regulatory mandates. As you saw from the Merrick v Savvis case, the service provider can be held liable for incidents of breach. Cary has the right advice for SaaS vendors is ensuring sufficient insurance, avoiding unlimited liability and avoidance of any ASP like terms.

If revenue recognition was not already complex, SaaS has some new twists considering that the agreements are signed upfront but the corresponding revenue recognized over the life of the contract.

Cary also explains the complexities surrounding multi-year agreements, international contracts, Data Privacy requirements, Data Ownership are all key areas to focus on during contract negotiation.

As with any legal issue, consult your attorney to ensure you have worked out the details around the complex legal issues involved while the SaaS model and the legalities continue to evolve.

For the longest time, customers have borne all the growing pains, quality issues, large capital expenditures in licensing, managing, updating and maintaining enterprise software. Now the tables are turned. With SaaS, the vendor is now saying, “You the customer, just pay for the use and we will take the responsibility of providing the same software on my premise and we will be responsible for upkeep, upgrade and up-time. All for a flat fee that comes out of your OPEX.” The statistics of SaaS adoption bear out that the customers have liked the message and acknowledged with a resounding “YES”. Vendors not embracing this SaaS movement are slowly seeing the truism of Richard Waters’  “The end of Software gravy train“.

With the economies of scale, the costs SaaS vendor incurs in managing the application will eventually trump the costs the customer incur if they did it themselves. But in the tough climate we are in, revenues hard to come by, coupled with the ongoing customer’s concerns around outage, data breaches and coincidentally, broader adoption of Cloud Services like Infrastructure-as-a-Service (IaaS) from Amazon EC2, Rackspace etc,  a new hybrid model of delivering SaaS applications seems to be emerging and gaining interest.

SaaS vendors who support this hybrid model where the customer now has the option of subscribing to their service but choosing a cloud based infrastructure to host it.

Bruce Richardson of AMR Research wrote a post recently on his discussion with Don Klaiss CEO of Compiere around SaaS and Cloud Computing.

Don makes his observation about how Cloud Computing with its lower TCO, flexibility would become the next generation on-demand software delivery model. Specifically he went on to say

“Cloud computing is the next-generation of software-as-a service, in which a complete software environment is licensed as a subscription from a software vendor and low-cost, secure, and dependable IT hardware infrastructure is ‘rented’ from a utility-computing provider on demand. The customer has complete control over its own secure and private IT environment at a very low cost and without the hassle of procuring and managing its own data center. It can quickly scale IT resources up or down as computing needs change. And [the customer] has complete freedom to customize the solution as it sees fit and complete control over upgrade cycles and all other aspects of its IT environment.”

This symbiosis of Cloud Services and SaaS applications will definitely have arguments on both sides. So let us look at the merits and demerits of what this means, to customers, considering this model.

Merits

1. As a customer you will no longer need to be concerned about losing control of the your critical applications, data and management. You will own the environment.
2. If the vendor goes bust, you already have your application, data and hopefully with your IT resources already trained, you will be able to mitigate most of the risks to business continuity.
3. Unlike a on-premise solution, you get the infrastructure that you can control at a fraction of the cost with Amazon Web Services (AWS), Rackspace or any other cloud based infrastructure provider – so you get the benefit of lower TCO. So all the benefits of your own environment minus the painful part of negotiating technology contracts with hardware vendors.
4. One of the biggest challenges in most SaaS offerings is around business intelligence and reporting. Most offerings around reporting are merely a shadow of what you can do with your own data. Your end users who might have been trained on a corporate standard tool like Business Objects/Micro Strategy/Cognos would have had to get trained on the new reporting tool of the SaaS vendor. Customers typically work around this by negotiating the ability to get copies of their slice of data from SaaS multi-tenancy so they can run their own reports on-premise. With customer-owned cloud based infrastructure, and data under your control, now you get to use your own Business Intelligence, Reporting tool.
5. With the source code being available to you, you will have luxury (depends on who you speak to) of making customizations which are not available in a true SaaS model. In true SaaS model you are limited to configuring business processes, UI changes/branding using the switches and knobs provided by the vendor.

Demerits

1. As a customer you now have to worry about EVERYTHING outside of application changes. You will be responsible for all the maintenance, security, data management and the costs. The economies of scale that SaaS vendors achieve doing it for many many customers is not available to you.
2. You will now be responsible for updates, change management to the application. This will over time introduce the need for SaaS vendor supporting multiple releases, considering that realistically, left to themselves customers would define their own schedule to upgrade. With that need comes additional costs that SaaS vendor will incur and that costs will be transferred over to the customer.
3. Irrespective of what your corporate standard for hardware/IT is, you will have to make do with what the Cloud provider supports.
4. You will now have train your IT to manage cloud infrastructure and include that under your corporate IT governance guidelines.
5. You will be responsible to implement Disaster Recovery environment on your  own. This almost doubles your cloud infrastructure cost. With a SaaS provider this would have (in most cases) been included as part of the service.

This short list should give you a frame of reference to evaluate this model.

To me, there are definitely slices of benefits when compared to the on-premise purely based on the transfer of management overhead and upfront costs to Cloud service provider and some benefits from agility of a SaaS vendor. But that said, one of the benefits of SaaS is if things went wrong you know who to go to but with a hybrid approach now you will invariably get ping-ponged between the two vendors.

A better model would be for the SaaS vendor to use cloud and also provide access to the data, ownership to the customer but still be responsible for the management, maintenance.

Would love to know what you think about this? Send me a note and I would be happy to discuss this more.

• Lower upfront costs…no large one-time license fee. Pay as you go and only for what you need and use.
• Ease of implementation… sign up this morning  and you can start using it this afternoon.
• No maintenance or upgrade costs … done by us. So there is no need for a large IT team. More $$$ savings.
• No extra support costs…everything baked into the subscription fees.

It’s easy and  natural for a SaaS sales rep to produce cost comparisons with an on-premise alternative and highlight the immediate savings. This strategy, while it works sometimes, is not enough to close in all cases.

A direct comparison with a traditional on-premise software purchase will immediately bear out the short term cost benefits. If you can think about it, a prospect could too and they might have probably run this scenario prior to your discussion. If the value proposition of your SaaS offering is limited to – “It is cheaper” – then brace for a tough time selling. You will perennially be fighting a commodity pricing battle. If you apply Moore’s law, the probability of a new vendor beating you at your own game (price) is pretty high…think open source vs licensed software or just ask Dell how HP caught up. Moreover, the incumbent on-premise customer gains very little advantage in uprooting an established, heavily invested-in solution (it is working right?) and moving to a SaaS solution. There must be more benefit to win here.

To differentiate your offering and stand out here are some strategies SaaS vendors should be using to position their solutions.

Value Chain Approach: SaaS inherently offers you the ability to incorporate your extended enterprise, involving customers, partners, and suppliers, into the business process. Being in the cloud, it is a natural for integrating your business processes with processes of the other stakeholders. Until now, this was only possible (and achieved) through system level integration with complex (read expensive) messaging, data integration or in the most advanced case – an extranet based solution for data interchange. Now with SaaS, you can do it at a business process level. Examples of successful SaaS based Value Chain solutions include Aravo for Supplier Relationship Management, Siterra for Capital Project Collaboration, E2Open for  Supply and Demand Collaboration.

If you consider a Human Capital Management scenario, it could be bringing together internal HR, external recruiters, training companies, background screening, relocation providers, etc. to a common business process platform.

AMR Research terms this “Multi-Enterprise Collaboration” to illustrate the virtues of this value chain approach,  albeit in a predominantly supply chain-focused view. Having  companies create and align performance measures to meet a set goal in a common environment with integrated data and processes to build scalable and repeatable relationships. Each value chain member derives benefit from this collaboration.

Define and highlight the larger value your solution delivers across the entire value chain beyond your clients’ company into their extended enterprise and thereby giving them a distinct advantage over their competition.

Master Data Management

If you extend the value chain concept further, by the virtue of having all the key stakeholders participate across a common business process platform, you are inherently creating a Master Data Management(MDM) framework. All the participants of the value chain would be looking at a single, consistent definition of data. In your specific case, it could be any or a combination of customers, employees, suppliers,  products or assets. Companies spend millions of dollars in creating MDM (data creation/propagation/rationalization/synchronization) solutions, with uneven results. Now with a common platform you get a MDM solution in much simpler, more realizable and much less expensive way. High quality and consistent data and the ability it affords in making strategic and operational decisions is invaluable.

As an example : Suppliers from across the world that do business with GE have been mandated to use Aravo to manage and maintain their information. Now GE no longer has to manage fractured information, rationalize it across different divisions. It will now be captured and maintained at a single source. Consider the effort and difficulty a company would encounter doing this with a traditional on-premise software solution across multiple geographies/divisions with all the provisioning, change management and governance issues involved….think nightmare!

Governance Baked in

In the face of the litany of compliance mandates SOX, HIPAA, PCI-DSS, to name a few, a company’s resources (and money) can be drained in meeting those demands. With SaaS, annual SAS-70 Type II certification, elaborate Disaster Recovery measures will automatically meet majority of clients’ IT Governance needs.

Finally – Yes!. Cheaper, Faster and BETTER

Yes there is real value in being cheaper and faster but significant additional strategic advantages such as these will provide improved agility, better leverage of your customers/suppliers, and true competitive advantage. Try and understand the critical challenges the prospect faces in their industry and highlight how your agility, flexibility allows them to overcome those.

Large Upfront investment: The first and foremost benefit to a company is that it is hosted by the vendor (or a third party) and a company does not have put in place the IT infrastructure, team to host, manage the application. This frees up the large IT spend that now could be diverted to other projects that require it, now.  Remember the infrastructure includes application deployments for QA, Production, Pilots/Acceptance, Development and Fail-over besides production.  If you are global company then add to it the other needs around replication/WAN optimization to counter the latency issues. It is the Total Cost of Ownership (TCO) remember!. Then there is the Storage. With SaaS, your vendor will address all these needs for a fixed all-rolled-into-one subscription price. The beauty of the model is you can ramp up your costs commensurate with your consumption as opposed to making all the investment upfront often resulting in under utilizing the hardware/software.

Ongoing Costs: This is one of the most contentious one. Traditional vendors will have you believe that over time (5yrs and above) the infrastructure investment will have paid for itself. After that SaaS is going to cost you while an on-premise solution will have no incremental cost if you add more users. This is a bogus argument.  On the face of it, the subscription costs might look like a redundant cost after the “infrastructure pay-off period” but that is only one side of the story. Anyone who has managed IT for a while, will know, IT infrastructure is a living thing and needs constant care and feeding. Software updates, hardware additions, performance tuning, monitoring, backup and recovery. Then there is the burden of negotiating contracts with the hardware and software vendors. This on top managing the application and the upgrades will clearly be much more than the subscription costs. Each upgrade cost could come up to tens of thousands of dollars, if not more.

One thing which was until recent not a consideration was the power consumption and needs. With all the power glut, now energy needs are becoming the first or the second line item on every on-premise software consideration.

What else? Oh! yes. Did I mention that there is the small matter of manpower turnover that you will have to deal with when managing things on-premise?

On-demand Elasticity: SaaS affords you a quick on ramp with costs commensurate with the size of the team. Once you have conducted the smell test and decided to move further, SaaS also gives you the opportunity to scale up and/or scale down depending on your demands. Say your company makes an acquisition – you scale up your usage with just the subscription cost going up – easily quantifiable. Say 6 months later you rationalize the acquisition and decide to reduce a workforce reduction, you can now scale down the usage on the SaaS application. Contrast the same with a on-premise deployment. You buy it – you keep it. You will have to continue to pretend that those phantom users who were part of your organization during the post merger/acquisition integration are still part of the organization and keep on assuming those costs for the hardware procured, higher energy costs for that extravagant hardware footprint.

Anytime/Anywhere Access: Being in the cloud, your users will have access the SaaS applications just by using a browser and internet connection. Contrast that with a on-premise application that needs provisioning of access, you will need to go through a IT root-canal for arranging for VPN, access control etc.

Short-term ROI: Depending on the scope of implementation a SaaS application can quickly allow you to define target ROI and achieve it. Implementations are shorter in matter of weeks for a new implementation and maybe 2-3 months in cases where there is data migration, back-office integration. Contrast that with a long drawn out on-premise implementation. By the time the software is installed, pilots done, it will be a good 6-9 months if not more. ROI is elusive, if ever.

Risk Mitigation: In case of a traditional on-premise implementation, besides the large upfront investment for IT infrastructure, there is substantial investment to be done to get the project off the ground. This could include staffing a team and a prolonged project wrought with risks of project failures and cost overruns.  With SaaS, you could have a defined implementation schedule and near term ROI, which if not met, can allow you to terminate the project at the lowest cost.

Frequent Product Updates: One of the key benefits of SaaS is the product updates are frequent. This nimbleness of the vendor allows them to deliver incremental functionality faster than any IT organization can deliver to business. This represents a opportunity cost that a company will have to bear in a traditional software management model. Also given that the vendor is responsible for upgrades, relieves you of that cost burden as well.

Support Cost & Quality: With the vendor themselves providing the support (included in the subscription price), the buck stops with the vendor. You can define SLAs and measures to hold the vendor accountable. In a on-premise case, the IT organization is responsible for SLAs for a product that they would not be the ultimate experts in.

Get ready to be drilled

While we went into all the virtues of SaaS, there are some landmines that you should avoid as well.

Portability: SaaS has been perpetuating this principle that – “Customers can easily move to another vendor, if they did not like the service. So they have nothing to loose by signing up to a SaaS service”. This is b.s. of the first degree. This is much easier said than done. Never sell yourself into a deal where your bluff can be called. A smart buyer can push you to a corner with this and have it in the contract for you to provide data in a normalized form when/if they decide to move to another vendor. If you are tech savvy then you know what you are getting yourself into with that argument. Talk to your engineering team before you sign-up for this.

Integration: “We can integrate to everything/anything on earth through our APIs”. This is one area were every vendor exaggerates. Integration is not an off-the-shelf offering. Remember – Even a band-aid needs peeling, sizing cleaning the wound before you apply it to the wound. It is not magic. So take time to understand the need before you oversell your integration capabilities.

Disaster Recovery: While you are new SaaS company, it is unrealistic to assume that you will be able to afford Disaster Recovery implementation. While this is one of the gating issues – you would do well to highlight the Service Levels, Uptime statistics and if you do have a roadmap for DR share it. Remember you do not have the same excuse that a on-premise sales person has – it will be ready by the time you are live (read 18 months). On SaaS you are live tomorrow.

Given that everything with Software-as-a-Service(SaaS) is different from traditional software wouldn’t you assume the  same should apply for sales and marketing? It is. But majority of the companies are not recognizing this and continue to follow the traditional sales model.

The key difference in the SaaS sales model is the structure and focus for the sales organization. Sales organizations in traditional software companies are used to pursuing large deals (with large upfront license + ongoing maintenance contracts), but in SaaS everything that is charged to a customer is rolled into a monthly subscription fee. The typical contract size is 1yr to 3yrs and the contract value might be considerably smaller than a traditional software deal. This makes it very important to keep upfront sales costs down and increase the sales velocity. Having a hunter-and-farmer model is another key requirement. Closing as many sales deals as possible in the least possible time for the least possible cost should be the mandate to the sales force.

Given that your business operates online entirely, large part of your sales and marketing should too. To that end here are some strategies I offer

• Let them find you: Unlike in traditional software space, you should expect majority of your leads to come through the online channels. This in effect collapses the walls between marketing and sales to a large extent. The responsibilities of marketing and sales should overlap in a SaaS operation. To make your online presence strong, here are some strategies that must be followed
  • Presence: Make sure you have an engaging website. Your corporate website is the face of your company. Just like you adapt yourself to different situations  a website should also be able to assume various persona depending on the situations. This should be considered as part of the lead qualification process in some respect. The longer you engage someone on your website the better the chances of you funneling that interest into an opportunity. There are lot of free tools available to conduct A/B testing on various formats of site for various scenarios that would convince customers to engage with you.
  • Engage: Provide multiple ways for visitors/prospects to reach you from your website. Telephone, Chats all encourage prospects to reach out. When they do reach out make sure you have automated processes to contact the prospect in a timely manner. Industry stats show that the sooner you connect with the prospect that reached out to you, the better the possibility of closing a deal.
  • Qualify: It is cheaper to generate leads online with SEO/SEM than the traditional lead generation process. So spend the necessary resources to generate quality leads. Once the leads come in have a well-defined process to score, rank leads and razor-like focus to qualify those leads so sales finds the leads warm for close. Remember keeping sales cycle to a minimum is the goal.
• Let them know you: Establish thought leadership with blogs, webinars and workshops. If you are a startup you might not have the luxury of demonstrating elaborate case studies and live implementation proofs. Use your blog to articulate your understanding of the business that you are trying to sell into and make a compelling case for why your offering hits the mark. For good measure, host demonstrations to the industry experts or expert industry bloggers and get them to write independent opinions about your offering. People trust independent opinions more than marketing mumbo-jumbo. (Tip: Spare the money you spend on analysts and use it for roadshows and outreach.)
• Get to know your customers: Just like your prospects find you and do research on you, you should do the same on them. Check their websites, 10K filing (Management & decisions section), online customer community, case studies on their websites. The more you know about their business, the industry they are in, their key competitors, it will help you get closer to their real business problems. You will learn more about their company this way, than anything you will know from the team on the customer side you are interacting with.
• Help them through the decision: Try-before-you-buy, evaluation versions are always great way to eliminate the initial hurdle. Customers love to try the software before they make the commitment and it speaks volumes about the way you think and reducing the risk for them. Supplement that with videos, demos to guide the customer in their evaluation process. Lesser the risk for them, shorter the sales cycle for you. I am a big fan of Q&A forum where you can let customers co-mingle and exchange knowledge. Instead of worrying about that becoming a rant-exchange, you can make it work for you by having happy customers share with distressed customers. Even better find some champions from the user community and empower then to moderate the forums. If you have one such forums, let the prospect access those as part of the evaluation.
• Share the vision and ROI: Share the vision and not the current functionality. Remember it takes time for decisions to be made and eventual implementation. So sharing roadmap would really help companies make a decision knowing what is coming. On the flipside, be forthright in sharing things that you don’t do (or well). It is better than the customer finding out (and they will). Sales is notorious in overselling or pushing the envelope sometimes a tad more than they should in their eagerness to close the deal. But remember in SaaS, you need your farmers to delight the customers and open opportunities to expand the account. Remember angry customers don’t make good up-sell opportunities.
• Continuous Selling: Make sure farmers are doing their job. It is one thing to make a quick sale with the expectation that account manager would up-sell and expand the account in due course. But that needs rigor. Most often the account managers are saddled with fighting fire i.e, managing expectations or product deficiencies. Define intermediate ROI milestones and continuously keep demonstrating the value generated.  Remember your profitability on that customer account might depend on up-sell beyond the initial sale. In SaaS, it takes an average 1-3 yrs before you turn a profit on a given customer. So in a way you are investing (while making loss) in the initial years with the expectation that you will be able capture additional revenue in that account in subsequent incremental sales. Tip: Maintain a diary of the progress in the account and keep documenting the case as you go. You can use this to illustrate the value to the next customer.
• Sell the value not the cost: Software sales have traditionally been focused on automation, efficiency with cost as the centerpiece. Cost is a tricky thing to sell. When you try to sell the cost benefits to a room full of people (IT people much less) you know where their thoughts go straight away – their jobs. In these bad times, none of us want to be out of work. So unless you are dealing with a senior management, downplay the cost element and instead focus on the value your solution delivers. Any one smart would figure out that a good solution will eliminate resource overheads. So do your homework on what else is bothering that prospect and mention the intangible value your product delivers i.e., “frees them up to do that other project”.

What do you think? Share your thoughts and experiences that has worked for you via comments.

Late last year, I was working on a deal to sell our SaaS software to federal government. Being a SaaS company, naturally we were in a quandary. Up until then we had stuck to the core SaaS edict – i.e, maintain a single code base and all customers hosted on a multi-tenancy based deployment. Despite all the challenges we ran into from technology, architecture and operational issues, we had persisted. There were times when we debated on the question of  segregating customers into Small, Medium, Large multi-tenant instances. But we resisted and persisted. We invested large amounts of time and resource required to put out all the fires/challenges, make the requisite scalability related improvements and kept going with a single instance.

But this deal with the government was different. It was a large multi-million dollar deal which was tough to walk away from. What with the financial meltdown upon us and the prospect of a bleak 2009 being forecast.

As we had imagined, the federal government agency required their own instance and a on-premise installation at that. Considering the information they were going to manage in our product, I could see why it made sense for them host it and not co-mingle (their words) their data in a publicly accessible internet based application.

The deal we were trying to secure was with one particular agency and the usage was going to be limited to that agency. We had an elaborate RFP process that ran for more than couple of months – many many spreadsheets to fill with information and multiple demos to the primary contractor and in-house staff.

But with all the recent focus/news on Federal IT, federal CIO/CTO nominations, Recovery.gov and the talk about government agencies better leveraging technologies, I could not help but think of how SaaS would be the PERFECT model for deploying applications within the government. Various agencies can form tenants of the single instance and derive the inherent benefits. While there could be numerous other benefits here are 4 clear ones I could see federal government agencies could gain from by having their own SaaS deployment.

Master Data Management
As with the multiple business units in a large conglomerates, different federal agencies share common information across multiple agencies. Real Estate Properties, Approved Vendors, Approved Items, Locations, Technology Sourcing and the list can go on. With a multi-tenant SaaS model, all these master information entities and the related transaction can be managed in a single database, with appropriate access controls. This would eliminate all the redundant integration and data replication needs between different agencies and it could serve as a master data repository. All the reporting needs can be met from this single repository for a single agency and rolled up across all agencies.

Provisioning and Identity Management

While in recent times, government agencies have increasingly adopted Identity Management solutions, they still manage the identities in disparate directories. An internal on-demand solution hosted by a central IT agency under the Federal CIO can effectively streamline the identity management needs across agencies and serve as the provisioning clearinghouse for all the applications. If and when a agency employee transfers across agencies, it would merely be a change in access control as opposed to the entire provisioning work done across both the agencies (to revoke and grant access).

Collaboration

A single multi-tenant collaboration solution would not only standardize the way processes are followed across agencies, it will allow them to leverage best practices across agencies. I would put Project Management, Document Management, Communication under this bucket.

IT Infrastructure and Operations

Having a single instance would eliminate the need for redundant infrastructure needs for backup, recovery, redundancy infrastructure (for fail-over), hardware, software licenses, security assessments. All the upgrades, quality tests, user acceptance can all be conducted under a single installation.

All the management applications needed for governance i.e., change management, configuration management will also need to be done once.

Last but not least, the resources required to manage multiple implementations of software across agencies can now be deployed to perform incremental IT needs.

Who else would benefit from this?

SaaS Technology Vendors: Government sector has been off limits due to the resistance of government agencies to use any software outside their premise. With a dedicated instance hosted for government agencies or a hosted version on their premise (hardware), now the 70B+ spend is a new market segment SaaS vendors can go after.

Prime Contractor: You should strategize with a SaaS vendor to become the reseller of their SaaS offering with a government flavor. You can be a turnkey operator to manage hosting, provide managed services for provisioning, upgrades, custom integrations. Also being knowledgeable of the government processes, government contractors can now turn their knowledge into best practices for agencies.

What should a SaaS vendor be prepared for?

Brace for discussions that will question the very premise of your business model. While NIST comes up with the standards for SaaS security and performance, each RFP will be onerous to say the least. The numbers will be large. Government does not understand the monthly subscription business. They throw money once and buy things they want and as is their wont and would look to customize the application. It will take some time before they digest the fact that they are buying usage and not custom application capabilities as in the past.

Be prepared to hear the following

1. “Government does not want to store its data outside their firewall.” This should not come as a surprise to you considering all the critical data they seem to store. So to counter this you have three options
   • Create a hosted instance or an appliance on government network and you manage it just like your commercial offering. This might mean you need to have dedicated resource managing that instance and in some cases they will need security clearance. So factor that in your quote.
   • Host the application with database managed inside the government network. This entirely depends on how your Multi-tenancy architecture or product architecture is designed.
   • Let government host and support a copy of your product. You provide updates. (this has caveats based on 2 below)
2. Government would like to customize the product to their need. This customization could be anything for changing the application flow to building extensions in the form new UI+ Data capture or security model changes. To accomplish this they would need access to the source code or you exposing all the underpinnings of your application in the form of a SDK or API. Government is big on SOA so have your SOA story ready.  I would strongly urge you to push back on any request for source code. If you are working with a prime contractor, chances are they might be the ones perpetuating this need for source code more than the government. SIs make their living by customizations and long implementation cycles so it is their DNA. Eventually you might have to succumb and agree to part with your source – part of doing business with Uncle Sam.
3. Source Code and Who owns it: Extending the point from 2, if you do part with your source code, get your legal to draft verbiage around who, where and how the source code can be used and what if any, attributions you need out of the code changes they make. Also highlight the fact that if they make changes to the core product, they will do that at the risk of precluding themselves from getting further updates from you. At a minimum they will require a source code escrow.
4. Accreditation with government standards like FISMA, NIST.
5. Location specific storage: If you manage to convince government to use a hosted instance owned by you, then you will run into requirements like storage being done within the boundaries United States.
6. Preferred Customer pricing

SaaS is based on the premise that deals come in short sales cycles. A government deal is a anti-thesis to that – long drawn out and expensive. If you have gone through a similar process, shoot me an email, I would love to compare notes with you.

In the past SAP has always portrayed Business ByDesign as its on-demand offering albeit making it available only in a small subset of countries. It was a positioned as a complete on-demand suite counterpart for its on-premise SAP Business Suite. It was also targeted primarily at SMB customers.

But going by what John has outlined in his interview it seems like this new strategy is going to be different. To quote from his interview – “Here’s what SAP customers can expect in the coming months: function-specific software applications, available by subscription, that plug into customers’ on-site SAP Business Suite systems, and that SAP will host for customers using a multi-tenant architecture.” He also goes on to say “SAP won’t develop software services that compete directly, as independent SaaS applications, with companies such as Salesforce.com, Concur, and Ariba. Rather, all of SAP’s on-demand apps will be designed as extensions of Business Suite.“

This strategy is unique as Wookey says, and more complementary to the Business Suite. It is based on the platform multi-tenant architecture acquired from acquisition of Frictionless.

At the outset, based on these comments, it is easy to assume SAP is missing the plot or that it is just making some noise about SaaS yet again. Vinnie Mirchandani felt it was a “moat” strategy. Although it has been received with skepticism I have an alternate theory on why this might turn out to be a smart strategy.

Successful SaaS vendors in the business applications area, barring CRM as a category, have been primarily building solutions in three areas

1. the in-between areas where ERP vendors don’t have a solution and homegrown solutions are cannot scale or are tough to maintain.
   
2. Advanced solutions like predictive analytics, Talent Management, Performance Management, collaboration solutions that sit on top of ERP/CRM solutions.
   
3. Horizontal solutions with scaled down common ERP flows focused on SMB segment.
   

SAP already has about 25% of ERP, CRM and Supply Chain market – depending on whose numbers you go by. So SAP can do one of two things –

1. Entrust their product teams to enhance Business ByDesign to effectively compete with  nimble SaaS vendors. We all know who will win that race. It seems like SAP Management also knows that and hence it is not the strategy-of-choice they are pursuing. Add to that the financial dilemma of spending on BBD as Bob Warfield outlines.
   
2. Go after the up-sell opportunities in existing accounts and build industry vertical specific, value-added functions to sell into their existing accounts. This will serve two purposes. This will provide a way to slowly ease the existing customers into SaaS and considering that these are add-ons on top the Business Suite, it is conceivable that SAP can compete with nimble startups in this area.
   

While the SaaS meal is cooking in the SAP kitchen, Wookey would well to use a trick or two he learned from Uncle Larry’s M&A University and tuck-in a few more smaller SaaS vendors to kick start the closed-loop application ecosystem.

While this strategy looks good from the SAP point of view, John and his team should work out – the small matter of partners. SAP has long been known to be partner friendly in nurturing partners in building ancillary applications to augment the Business Suite. This has played a large role in the partner ecosystem. Now with SAP entering their turf, it remains to be seen how the partners will react to this announcement.

While large deals Data Domain, Sun Microsystems, WindRiver, seem to be taking the center stage, I think Sramana is spot on with her take on the SaaS industry.

If you look around there are a handful of SaaS companies that are profitable (and a few others are lucky to land large follow on rounds of investments like Workday). There are some great technologies that could be bought at some attractive terms.

The business model in SaaS is predicated on companies making large upfront investments to build up infrastructure, product and team. In addition, with the Customer Acquisition Costs (CAC) being front loaded to a large extent, it is supposed that over a period of time, ideally ranging from 1yr to 3yrs, a customer would prove to be profitable. All subsequent customers are expected to be acquired at a lower cost and faster profitability based on an evolving on-boarding program, best practices, templates etc, as I alluded to in an earlier post. But in this climate, without cash and luxury to make investments for growth SaaS companies present some great opportunities.

There are two constituents who might and should be active in this.

Firstly, larger companies like Intuit, ADP, Amdocs, Autodesk and I will add SAP, HP and Microsoft to the mix (Oracle, IBM, EMC, Cisco already being in a acquisitive mood) can get ready made entry into an already established, risk reduced opportunities. Acquiring SaaS vendors will also give them a low- barrier-of-entry solutions that will complement their existing on-premise solutions already used in most companies.This will also give them an influx of innovative products which are more in tune with today’s user demands and easier to implement. In this tough economy, when net new sales are tough to come by, these larger companies can use SaaS offerings to get into new accounts.

Secondly, SaaS companies themselves should look and consider merging with complementary offerings thereby providing a integrated offerings to customers. This would make a lot of sense from a customer point of view. I know companies that use SuccessFactors for Human Capital Management, SalesForce.com for CRM and Intacct for Financials. While the SaaS companies themselves amplify the rhetoric of  “the days of integrated suite of products in numbered”, the reality is far from that. If you talk to a IT executive  they will tell you that, one of the biggest hindrances for SaaS adoption is integration. They are continuously trying to make things works in an integrated fashion, thereby reducing the point of failures, share data and be able to map to their business process. Going to point solutions from different vendors is definitely not going to get them there.

In an ideal world, it would be great, if SaaS companies formed consortia where they innovate independently but fit into an overarching framework so their solutions works in unison. But that would be nirvana and asking for too much from technology vendors.

This downturn might provide an opportunity for companies to find suitable partners and willingly merge so they have a much more compelling broader solution. It will also allow them cross-sell into each other’s accounts.

PayCycle, founded by two ex-Intuit and headed by ex-Intuit Chief Financial Officer Jim Heeger was targeting smaller businesses and winning deals away from Intuit. It serves more than 85,000 customers and was generating revenue in the range of $25 million.

Intuit has always modeled it businesses with a complementary services business. This makes the deal a perfect fit with the Intuit model. With this deal, Intuit makes an entry into Software-as-a-Service (SaaS). Intuit is a well known trusted brand in small and medium business spectrum. This should give PayCycle solution the necessary credibility and muscle to go on and do greater things.

Intuit is known for letting individual business under it operate like autonomous subsidiaries. This should bode well for PayCycle to grow faster with the financial and sales muscle of Intuit behind it.

The first mention of SaaS application, as a possible technology choice, is sure to make your IT and the CFO/Risk officer sit up and take interest. A single breach and the consequential data loss can cost companies millions of dollars in penalties/damages. This does not include the unquantifiable damage to the company’s reputation. Regulatory mandates like Sarbanes Oxley (SOX)-404, HIPAA and PCI-DSS have strict requirements on how customer, financial, employee, partner data should be governed and protected. Moving to a SaaS application does not preclude, you the company, from those responsibilities.

Given that, how does a company considering a SaaS application conduct a good assessment of the risks involved before jumping in ?

Let us start with the premise.

Companies store data in servers and databases each kept from unauthorized users under strict access control. Additionally, the data itself is regulated by who can see what and what, if any, operations can they perform on the data. The operations could be manual or via an application that manages it.

In SaaS, your data will reside in the databases and servers owned by the service provider. If your SaaS vendor happens to use third party cloud based services then your data might reside in the data center of the Cloud provider. You as the customer, get to add, update, delete data from within the SaaS application, subject to the business rules and security policies implemented in the application. Unlike in the case of an on-premise application, your IT organization will not retain access to the servers, databases, storage, backups and the network. That responsibility would now rest with the service provider.

Risk Mitigation

In order to safeguard your data that would reside in the service provider’s database, here are somethings, you must ask the software vendor as part of the RFP/evaluation process.

1. Keep the bad guys away: Knowledge of existence of a particular service and its location is not a secret. Everyone knows how to access Salesforce.com or Netsuite. You go to the vendor’s site and look for the Customer Login or Client Login button/tab. Given that what are some of the processes vendor has in place for preventing Denial of Service Attacks, Spoofing (remember the Salesforce.com incident!).
2. Authentication/Sign-On: Most SaaS vendors these days support and delegate Sign-On using SAML(Security Assertion Markup Language). This will allow you to configure the entry point to the application/data for your company through a trusted site – like your enterprise portal which is accessed through VPN. With such a configuration you are now essentially in-charge of your provisioning and revocation of access from your corporate  single sign-on identity management.
3. Encryption Policies: Making data secure in the data center is the first step. Another challenge is to make sure data is safe in-transit. As you access data from the application, data is traveling over the wire back and forth. Having strong encryption of data on the wire is paramount. 128bit SSL encryption is common these days, but some vendors are now starting to provide stronger encryption. Check what your vendor supports. In fact, while you are at it also check what they support for the on-disk encryption so your data in storage and backups are encrypted.
4. Test the Tester:Verify the quality process being used to conduct security tests. Specifically check for tests conducted to identify vulnerabilities due to Cross-site Scripting, Cookie Management, Mass Update of Access Control, iFrame embedding, URL manipulation, Excessive Logging.
5. Multi-tenancy/Data Slicing: Multi-tenancy provides the economies of scale that SaaS vendors seek to provide low subscription costs. But this also means your data will be co-mingled with other customers. With all the rapid product development cycles, if the tenancy data separation architecture is not robust, this might expose your data to your competitors. So it is important to understand the way data separation is implemented.  Have your architects verify the  architecture to understand the multi-tenancy architecture better. Specifically check for the quality tests conducted to prevent SQL Injection. Code flaws that allow SQL Injection would end up allowing access to wrong slice of data.
6. Network Security: Network weakness is one of common ways for malicious users to get access to information. Typical issues found in networks would be improper SSL configuration, lack of robust session management and open ports. Once the hacker gets access, they can hijack active sessions and gain access to user credentials and critical information.
7. Backup/Recovery: In the quest for 99.99% availability, it is conceivable that vendors build redundancy and replicate data just in case of a crash. This means copies of your data could be residing in multiple data centers, in some case in multiple geographies. So if you are in a regulated industry and comply to data security guidelines that prevent your data being hosted outside the country or a certain geography, you should get that clarified upfront.
8. Certification: First of, ask for a SAS-70 Type II audit certificate, preferably conducted in the last 6 months and as an ongoing practice, every 6 months. This is like an insurance policy. SAS-70 is a generalist guideline and it is not a mandate. The certification, by itself, does not guarantee that everything is hunky-dory. You can find many examples of cases where companies supposedly certified, having incidents of data breaches resulting in large financial losses. If the application you are using include managing Credit Cards or Health Care data then you should also ask for the specific certification like PCI-DSS and HIPAA.
9. Preventive Measures: As part of your evaluation process, request for the documented architecture and policies for Intrusion Detection System (IDS) and Intrusion Prevention Systems (IPS). In addition, also ask for a recent run report of the IDS system. Review this with your corporate security team and ensure they meet your corporate mandate. If you are a small business and do not have a corporate IT security team, hire a CISA certified consultant and review the report with them. Even better, insist on a penetration test to be conducted by your team. You can hire third party services or a third party software to conduct a round of penetration testing.
10. Audit: Request for a report from a Penetration Test conducted recently, preferably by a third party. This is like conducting a fire drill to verify the preventive and corrective process the vendor has in place, does work.  More about Penetration Testing and Intrusion Detection and how to incorporate this into your process, later in the post.
11. Governance: Request for a change management and access management report of who in the vendor’s organization has access to the data. If the vendor has SAS-70 Type II certification, this is something they would have documented already. With the dynamic environment, in which most SaaS vendors operate, there will be a lot of churn in the people. It is important to make sure the vendor has processes in place to ensure their past employees, contractors do not retain access after leaving the organization.
12. Understand the data management:To provide 99.9%, almost interrupted, high performance service levels, SaaS vendors will end up replicating your data (or backing up) to multiple data centers. It is important to understand that process and access control on the replicated data.

This should give you a good set of upfront checks before you decide on a SaaS vendor. But just like physical fitness, security is not a one time thing. It is a ongoing process. You keep at it regularly – Measure, Monitor and Adapt, and only then can you be sure you data is secure.

Portability/Switching Cost

One of the beauties of SaaS is that if the SaaS vendor measure up to their commitments in SLA, you have the opportunity to switch. No infrastructure, resource investment overhangs. But don’t expect for switching to be as easy as switching your cellphone service. You still have the all important data residing with the vendor. With a little bit of smarts during initial contract negotiation, might get you your data free or for a nominal cost, you still have to ensure that your data is deleted clean from the vendor’s database and servers after you leave. A breach at your previous vendor and learning that your old data was part of the data loss is not something you would want to hear.

Bake it into the Contract

To make this a IT priority and a scheduled activity, here are terms you should incorporate into your Contract.

1. Have your vendor furnish a SAS-70 Type II certificate every 6 months or a year (depending on your comfort level)
2. Conduct a penetration testing exercise every 4-6 months from your end. If you are happy with the third party agency employed by the vendor to conduct a penetration test then save yourself some money and ask for that report to be made available to you. Vendors like Qualys provide you with a service that you can avail for conducting these tests.
3. Have your vendor furnish IDS/IPS logs to be available upon request or through the Self-Service Administration portal.

Parting Shot

You know I am big SaaS fan, so now for you SaaS naysayers out there – chew on this.

If it makes you feel any better, these are the very same checks and processes that your internal IT has to follow. So not going with SaaS does not preclude you from this process. With SaaS, since this is asked of the vendor and goes through the scrutiny of many customers like you, the chances are their process would be much more hardened resulting in your data being more safer. As un-comforting as it is the last I checked, the majority of data thefts happened from the inside of an enterprise as this survey done by a UK firm states – 33% of employees would steal data .

Back when I came across this document in the SandHill Report, I had just taken over a new job as Chief Strategy Officer at Siterra tasked with Corporate Strategy, M&A etc. Being new to SaaS, this was really good reference to start off. I also had a chance to meet Byron to discuss some of these later on.

Specifically, the law around maintain the CAC/CLTV ratio is so relevant in the times we live in today.

I just went back through my documents and went through this presentation again. It seems like this presentation keeps on giving. I was doing some research on channel opportunities for a SaaS company based in India that is looking for expansion into US. Ironically they are implementing Law 7 explained in the presentation but in reverse. Starting from Asia, they are looking at US as the primary market for their software.

Take a look at some ideas I have shared around the Customer Acquisition Cost (CAC)

• Reducing Cost of Implementation
• Selling SaaS