The SaaS delivery model is quite compelling to me. I founded a dot-com company back in 1999 which was what we called back then an “application service provider”, but the acronym ASP now seems to mean “average sales price”, and SaaS is what we call this deployment strategy today. Anyway, we delivered an information service to Internet portals which they used to enhance their search results. It was here that I discovered the sheer joy of being able to select and standardize on a processing platform independent of the customer’s choices. I say ‘joy’ because on-premise software in the enterprise space is really difficult to create. I have to digress here a bit to tell you why.
Today, there is not much difference between computers from the various manufacturers. The reason one company is an HP shop and another a Sun shop probably has little to do with the technology from those vendors and much to do with which vendor has a superior sales rep in the territory covering that company. This is not cynicism. It's just that computing platforms are largely commodity these days. There’s no value being added here by these platform selections, but it implies that an on-premise software offering from any vendor has to run on both Sun and HP platforms, and many others.
In enterprise software, this diversity of platforms creates a tremendous overhead for on-premise software companies. Consider a standard enterprise integration software package. It must run on Unix variants from IBM, Sun, HP, also Linux, Windows. It might also have to run on mainframes, mid-tiers (AS400 and such). It must support many versions of the OS for each, it must provide reliable connectivity to Oracle, DB2, Sybase, and many others, and many versions of each, not to mention every ERP platform (+versions thereof)…. I think you see that the combinatorics of this make QA quite troubling.
It gets worse.
There’s this aspect where every important feature of enterprise software has to be available but also pluggable. E.g., when selling a software package to a customer they will ask: “Does it have high-availability (HA) features?” The answer here is supposed to be “yes”. But another customer will ask: “Does it work with the HA package I already bought and am using for these other systems I have?”, and the answer here is also supposed to be “yes”. So HA has to be both built in, and pluggable. This is a nightmare for a software architect for enterprise software. Making a reliable software system where something as intimately configured as HA is pluggable is…. well, very challenging. Scary really.
Now consider SaaS instead of software packages. The provider, e.g., me, that is, Oco, selects an approach to scalability, HA, etc. we select a standard platform. We get big economy of scale from this. We have only to support a small number of versions of anything, and that’s just so we retain some internal flexibility in what we’re doing to provide reliable and performant services for our customers. This frees us up to concentrate on adding value by adding the features our customers need. QA is vastly simplified because the combinatoric explosion is gone. Involving our customers in the data-aspects of the QA is also easy in that new and old versions of an Oco service can be simultaneously up and usable. Customers can evaluate/test a new one while continuing to use an older one. There’s no “forklift” upgrades i.e., where the new software version supercedes the old one, and upgrades it and there is no going back, no agony over whether installing a new version will disrupt a prior functioning system, etc.
To a software developer, working on the features is where it's at. It's more satisfying to deliver more features to customers sooner. It's liberating and energizing. All these lead to good psychology for keeping the developers motivated, and that adds up to satisified customers.
Now if you consider the arguments above, appliances (product consists of hardware + software) can also a reasonable approach, so long as maintenance of the system isn't a burden placed on the customer. But that is a subject for a future posting.
All these lead to good psychology for keeping the developers motivated, and that adds up to satisfied customers. It's more satisfying to deliver more features to customer as soon as possible
Posted by: Cheap Computers | June 20, 2009 at 07:00 AM