This is part one of a two-part series I’ve wanted to do about strategy for PaaS (Platform-as-a-Service) vendors…

The PaaS market is a fascinating one.  Building SaaS and Cloud apps that really take advantage of the Cloud is non-trivial.  And, as I’m fond of saying, at least 70% of the software you build winds up adding no differential business advantage at all.  It’s just stuff you have to get done to finish a working software product.  If you could buy a solution to all of this, and focus all of your energies on the part of the software that does add competitive advantage, that would be good for all concerned, right?  Hence many PaaS offerings set out to do just that–save you 70% of your coding, make you radically more efficient, and let you focus on your business problem while they take care of Multitenancy, the Cloud, and whatever else they can.

It’s a great idea with just one great big problem–it requires an incredible commitment on the part of the customer just to get started.  Giving up control over 70% of your code is scary as heck.  I’ve written before about the need for PaaS vendors to act like Switzerland in order to be as non-threatening as possible.  After years of abuse at the hands of companies like Microsoft, everyone who writes software fears lock-in.  It gets worse too.  Have you ever tried to get developers to work on someone else’s code?  Their answer is universally the same.  No matter who wrote the code or how good it is, it could be done by the Senior Architect they most totally respect, the first time they look at the code and hear you want them to deal with it, their response is invariably, “This code is sh*t and we’re going to have to rewrite it.”  I’ve seen this over and over again.  Oddly, developers seem to hate to learn new things, but they most hate to learn new code.  They rebel at even simple things like trying to organize how they format their code.  Now PaaS vendors would like them to drop everything they know, learn a completely new framework and potentially even a new programming language.  Is it any wonder it’s an uphill battle?

So what’s a poor PaaS vendor to do?  My answer is simple: quite focusing so much on code and change your attention to data.

Data is so much less threatening to the developers you hope to win over.  Sure, you’ve got to prove to them that you’ll take good care of their data, but if they were building software to run in the Cloud or be a SaaS app to start with, presumably they’ve come to grips with that and it’s a conversation you can get through.  Data is extremely advantageous for the PaaS vendor to have.  First, it leads to code coming over as your customers will inevitably want to do something with the data.  Second, there are strong network effects associated with the data (that will turn out to be a pun, sorry) due to latency.  Simply put, it is easier to access data in the same Cloud than in another Cloud.  So data will tend to accrete.  The more data that is in a Cloud, at least if its data that goes together, the more data will want to be in the same Cloud.  Data is also pretty frictionless to get into the Cloud.  Sure, there is latency if you move it around a lot, but loading it in and keeping it up to date is not so bad.  Those same developers that wanted to rebel over swallowing a bunch of foreign code have no problem at all getting on board with a project to move a bunch of data into a Cloud.

The next question to answer is, “Why should a customer put their data onto our PaaS in our Cloud?”

There are some good answers here too.  Customers will put their data in your Cloud in exchange for:

• Analytics:  Reporting and Analytics is something every application needs to do that is pretty darned painful to keep building yourself every time.   There is a reason the BI companies stayed independent for so long even though the apps companies owned the data–it’s hard to write BI software!  And so many SaaS companies have lousy to middle of the pack reporting and analytics.  For some it is almost non-existant.  Almost nobody has much in their first release, but they nearly all reach a point where they have to invest in it because their customers demand it.  PaaS vendors should focus on this one up front.  It is extremely high value add, and gives a powerful reason for customers to move their data into your Cloud.  Make it easy for them to create their reporting and analytics data warehouse there.  You won’t be sorry.
• Integration:  Next on the list of reasons to move data to your Cloud is you will solve an Integration problem for customers if they do so.  No software is an island these days.  It all has to integrate to something.  If you can facilitate that integration once the data is in your Cloud, everybody wins.  Note that this integration should inform your business development strategy too.  Look for partners to pull into your Cloud that add value through integration.  Identify key systems of record, and either get that system into your Cloud or get connectors to that system into your Cloud.  But don’t offer the connector without the Cloud.  Give the connector away in exchange for keeping data in your Cloud.  Don’t give away the cow, sell the milk.
• Aggregation:  The subject of deriving benchmarks from aggregated data comes up constantly in reference to the Cloud.  The insights that can be gained from looking across many customers at the same data are tremendously valuable.  The PaaS vendor should facilitate this in two ways.  First, they can act as an aggregation clearing house.  It takes a particular kind of BI Warehouse to be efficient at aggregation.  It takes a particular kind of expertise as well, so there are services to be sold here that a lot of SaaS companies don’t seem to have.  Call this an offshoot of Analytics if you like, but in my experience it is rich enough to be a stand-alone offering in its own right.  Second, the PaaS vendor can augment the value of the data via aggregation of a different sort.  Take Salesforce.com’s purchase of Jigsaw.  Suddenly they have a lot of interesting data about any contact that you may have in any database for any reason.  If they let you connect that data to yours, it is a sort of aggregation that adds value.  For sales and marketing or supply chain-related software, there is a lot of opportunity in this sort of value added data linkup.  There is less opportunity for inwardly facing data, but it is still there (salary benchmarks, anyone?).
• Other Value Added Services:  Let’s not stop with the Big 3.  There are lots of other Value Added Services you can bring to the table once customers are comfortable giving you a slice of their data.  Disaster Recovery is an obvious one.  But what about Disaster Recovery combined with Integration?  Not only are you helping to back up the customer’s immediate data, but you are backing up the data they may have entrusted to other Cloud Providers and SaaS applications.  What about services to help them manage their data in various ways?  Every SaaS vendor has to manage data in some form or fashion.  At the very least they need a plan to archive or dispose of it.  Perhaps your Cloud is the final destination in a hierarchical archiving scenario.   And while we’re talking backup, archiving, and disaster recovery, how about a simple service while your customer’s SaaS app is down during a maintenance period?  Can you provide them with a reduced-functionality front end and access to data so that their customers are never completely cut-off with no service waiting for the regularly scheduled maintenance (or the irregularly scheduled and unplanned-for outage) to end?  Of course you can, and it will make your customers happy because it makes their customers happier.

Okay, there’s a sampling of things PaaS vendors can do to win over the data of customers so they can earn the right to win over more and more code.  It offers a way to build a win-win relationship between the PaaS Vendor and customers so that trust can be built and a stronger relationship can unfold.  In the second installment, I’ll be writing about how PaaS vendors should manage that unfolding so the elephant can be eaten one bite at a time.

Related Articles

Have you noticed how many Analytics and Integration acquisitions IBM has been making in the last 12-18 months?  Fascinating basis for PaaS over there.