Site icon SmoothSpan Blog

PaaS Strategy: Data not Code

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:

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.

Exit mobile version