This is part two of a two-part series I’ve wanted to do about strategy for PaaS (Platform-as-a-Service) vendors.  The overall theme is that Platforms as a Service require too much commitment from customers.  They are Boil the Ocean answers to every problem under the sun.  That’s great, but it requires tremendous trust and commitment for customers to accept such solutions.  I want to explore alternate paths that have lower friction of adoption and still leave the door open in the long run for the full solution.  PaaS vendors need to offer a little dating before insisting on marriage and community property. 

In Part one of this PaaS Strategy series, I covered the idea of focusing on getting the customer’s data over before trying to get too much code.  We talked about Analytics, Integration with other Apps, Aggregation, and similar services as being valuable PaaS offerings that wouldn’t require the customer to rewrite their software from the ground up to start getting value from your PaaS.  Now I want to talk about the idea of starting to get some code to come over to the PaaS without having to have all of it.  My fundamental premise is to create a series of packages that can be adopted into the architecture of a product without forcing the product to be wholesale re-architected.  I use the term “packages” very deliberately.

Consider Ruby on Rails Gems as a typical packaging system.  A gem can be anything from a full blown RoR application to a library intended to be used as part of an application.  We’re more focused on the latter.  The SaaS/PaaS world has a pretty good handle on packaging applications in the form of App Stores, but it needs to take the next step.  A proper PaaS Store (we’re gonna need a better name!) would include not only apps built on the platform, but libraries usable by other apps and data too.  Harkening back to my part one article, data is valuable and the PaaS vendor should make it possible to share and monetize the data.  Companies like Hoovers and LinkedIn make it very clear that there is data that is valuable and would add value if you could link your data to that data.

What are other packages that a PaaS PackageStore might offer?

I am fond of saying that when you set out to write a piece of software, 70% of the code written adds no differentiated business advantage for your effort at all.  It’s just stuff you have to get done.  Stuff like your login and authentication subsystem.  You’re not really going to try to build a better login and authentication system, are you?  You just want it to work and follow the industry best practices.  A Login system is a pretty good example of a useful PaaS package for a variety of reasons:

–  It doesn’t have a lot of UI, and what UI it does have is pretty generic.  Packages with a lot of UI are problematic because they require a lot of customization to make them compatible with your product’s look and feel.  That’s not to say it can’t be done, just that it’s a nuisance.

–  It adds a lot of value and it has to be done right.  As a budding young company, I’d pay some vendor who can point to much larger companies who use their login package.  It would make my customers feel better to know this critical component was done well.

–  It involves a fair amount of work to get one done.  There is a fair amount of code and it has to be tested very carefully.

–  I can’t really add unique value with it, it just has to work, and everyone expects it to work the same way.

–  It is a divisible subsystem with a well-defined API and a pretty solid “bulkhead” interface.  What goes on the other side of the bulkhead is something my architecture can largely ignore.  It doesn’t have to spread its tendrils too far and wide through my system in order to add value.  Therefore, it doesn’t perturb my architecture, and if I had to, I could replace it pretty easily.

These are all great qualities for such a package.  What are some others?  Think about the Open Source libaries you’ve used for software in the past, because all of that is legitimate territory:

– Search:  Full text search as delivered by packages like Lucene is a valuable adjunct.

– Messaging:  Adobe and Amazon both have messaging services available.

– Mobile:  A variety of services could be envisioned for mobile ranging from making it easy to deal with voice delivered to and from telephones to SMS messages to full blown platforms that facilitate delivering transparent access to your SaaS app on a smartphone.

–  Billing:  There are companies like Zuora out there focused on exactly this area.  Billing and payment processing comes in all shapes and sizes, and many businesses need access to it.  You needn’t have full-blown Zuora to add value.

–  Attachments:  Many apps like to have a rich set of attachments.  There’s a whole series of problems that have to be solved to make that happen, and most of it adds no value at all to your solution.  Doing a great job of storing, searching, viewing, and editing attachments would be an ideal PaaS package.  There are loads of interesting special cases too.  Photos and Videos, for example.

I want to touch on an interesting point of competitive differentiation and selling.  Let’s pick one of these that has a lot of potential for richness like Photos.  Photos are a world unto themselves as you start adding facilities like resizing, cropping, and other image processing chores, not to mention face recognition.  There’s tons of functionality there that the average startup might never get to, but that their users might think was pretty neat.  After a while, the PaaS can set the bar for what’s expected when an app deals with photos.  They do this when their Photos package is plush enough and adopted widely enough, that people come to expect it’s features.  When it reaches the point where the features are expected, but a startup can’t begin to write them from scratch, the PaaS vendor wins big.  The PaaS customers can win big too, because in the early days, before that plushness becomes the norm, a good set of packages can really add depth to the application being built.

PaaS vendors that want to take advantage of this for their own marketing should focus on packages that deliver sizzle.  I can imagine a PaaS package vendor that totally focuses on sizzle.  They’ve got photos, video, maps, charts (bar charts to Gantt charts), calendars, Social Media integrations, mobile, messaging, all the stuff that when it appears in the demo, delivers tons of sizzle and conveys a slick User Experience. 

Before moving on, I want to briefly consider the opposite end of the spectrum from sizzle.  There’s a lot of really boring stuff that has to get done in an application too.  We’ve touched on login/authentication.  SaaS Operations is another area that I predict a PaaS could penetrate with good success.  Ops covers a whole lot of territory and the ops needs of SaaS can be quite a bit different than the ops needs of typical on-prem software.  For one thing, it needs to scale cheaply.  You can’t throw bodies at it.  For another, you have to diagnose and manage problems remotely.  One of the most common complaints at SaaS companies I’ve worked with is the customer saying performance is terrible.  Is it a problem with the servers?  Is it a problem in the Internet between your servers and the customer?  Is it a problem inside their firewall?  Or is it a problem on their particular machine?  Having a PaaS subsystem that instrumented every leg of the journey, and made it easy to diagnose and report all that would be another valuable, though not particularly sexy offering.

I hope I have shown that there is a lot of evolution left for the PaaS world.  It started out with boil the ocean solutions that demand an application be completely rewritten before it can gain advantage from the platform.  I believe the future is in what I’ll call “Incremental PaaS”.  This is PaaS that adds value without the rewrite.  It’s still a service, and you don’t have to touch code beyond the API’s to access the packages, but it adds value and simplifies the process of creating new Cloud Applications of all kinds.