SaaS Blogs

At the turning point in the plot of my favorite ‘just for fun’ movie, Antitrust, the crooked software mogul Gary Winston mistakenly exposes his evildoings to the hero software programmer, Milo, by making the following statement:

“The answer’s not in the box, it’s in the band” 

In the movie, the phrase is used in reference to compression algorithms that Gary stole from Milo’s friend.  However, permit me to use this simple statement to illustrate my point:

As far as success in service delivery goes - the answer’s not in the application (the box), it’s in the platform that delivers it (the band).  After all, this is what SaaS developers struggle with - they know how to make software, but this new way of delivering it presents a few serious problems.  And of course the solution is found in delivery platforms - constructs that take the delivery concerns out of SaaS applications.  So, what makes a successful delivery platform, and what should you look for as a developer when choosing one for your SaaS application?

As Sinclair hinted in an earlier post, we need only look at the history of our industry to see the difference between what will work well and what will change the world.

In the SaaS world, what we have right now is a bunch of proprietary platform-esque offerings (perhaps the most touted being the newly announced Salesforce.com Apex).  Actually, Apex is a good example for this point - it’s got it’s own language.  Now, suppose I want to create an entire application that does things that the platform does not provide for - I’m on my own as far as I can tell, and while I can make API calls from the outside… I am no longer utilizing (or benefitting from) the band, am I?  I have to provide my own delivery mechanism anyway.  As far as my clever analogy goes - these platforms are Apple Computers circa the early 1980’s.

I think you might be able to tell where I’m going with this by now.  What did Microsoft and IBM do?  They created a software platform that made hardware accessible to application developers in a standardized fashion, while dictating very little about how the applications themselves conducted their core business logic.  Application developers were able to focus on software and worry little (and less over time as the operating system evolved) about how that software was delivered to computer users.

Now, let’s complete the analogy - if we equate SaaS delivery requirements of today with the personal computer hardware of the early 80’s - then history teaches us that we need standardization.  We need a platform that facilitates delivery, but allows developmental freedom.  Developers need to be able to create the software applications they create because of their talent, skillsets, resources, and native technology stacks… not the software they are only able to create because of the capabilities provided by the platform they choose for delivery.

Imagine if Pope Julius II had commissioned Michelangelo to paint the Sistine Chapel and said “Please paint the ceiling.  Here are your paints, but you can only use black and white.”

As the awareness and adoption of SaaS broadens, it will become more and more evident that the path to success for SaaS developers is in the freedoms and powers that their chosen delivery platform affords them, not the proprietary featuresets (read: limitations) and closed constructs of current platform attempts.  The answer is in fact, in the band.