For example, in the conversation the problem of rapid deployment or provisioning arose. 20 years ago this month, when I was the Manager of Network Support for the Auburn University College of Engineering, I had the task of taking a classroom full of boxes containing workstations and deploy them to the departments and classrooms prior to school starting. The only sane way to approach this is to reduce the variance between the systems. I produced a golden image of the OS and started cranking out workstations. But we still had variance problems. The network was not yet implemented in every building. So there were some deployments which were unique. Later, when we were able to connect all of the buildings (and eventually, we even connected to the internet :-) then I quickly resolved the unique systems and brought them into the fold. By the time I left Auburn, we could deploy a new workstation in about 20 minutes, including physically unpacking and installing the hardware, with the workstation being fully usable in the ubiquitous environment and connected to the internet. Sometimes, it would take longer than 20 minutes because we allowed the faculty member or staff to choose their hostname -- a process that could take days. Since the hostname was the only variable, it was no wonder that it cost time to resolve. But it is good to have real names instead of numbers for such things. Today, with a well designed "cloud" you could expect to deploy a New Thing in just a few moments -- after resolving the unique properties such as billing information.
Rapid deployment is a Good Thing, but it isn't a new thing. We've been doing that for many years. What seems to be new is that people who do not have the net in their DNA are starting to figure it out. I can loosely classify these as PC people, those who have been exposed to the software installation and configuration issues in the disconnected, fat client world -- aka PCs.
This is where SaaS comes in. The problem with installing software on each and every fat client is that software changes over time. By the time a software vendor becomes successful in the fat client market, they could have dozens of versions of the software installed in the client base. Keeping track of all of the versions, and the features, bugs, and platform support is a nightmare. At Sun we constantly had customers asking for a compatibility matrix, which I call a sparse matrix, because there were so many products and platforms that were never tested together, it was impossible to make sure everything worked together at any one point in time, let alone as they changed over time. The best way to tackle this variance problem is to not install software on the fat client at all. I know, I know, this is the same mantra we sang about 20 years ago when the network was the computer, but it really is all about decreasing costs and complexity by getting rid of variance.
In a SaaS environment, you can roll out a new, improved version of your software and know that all of your customers will be on the same version. This is a huge reduction of variance in the installed base. This is also a huge win for the customer service group in your company. We did many studies at Sun that found the number of bug reports which had known solutions is large. Many enterprise customers are late adopters, which further compounds the problem of variance in the installed base.
So if it takes a marketing buzzword, like "cloud computing" or "SaaS," to help point people in the direction of removing variance, then I can live with it. Reducing variance is a Good Thing.