Software-as-a-service (SaaS) is now a highly prevalent phenomenon, used by businesses and government agencies large and small. Other information technology-related "as-a-service" offerings are also becoming more and more popular. Adding "aaS" to a variety of terms has matured to buzzword status (not to mention spawning a rich set of sophomoric jokes). Make no mistake, however, software-as-a-service is nothing more than good old-fashioned outsourcing.
Outsourcing is best described as the subcontracting of a business function to a third party. Organizations have been outsourcing their IT functions since at least the 1960s. Back then it was common for organizations to buy processing time on mainframe computers, as computers in general were so much more expensive (relatively) than they are now.
As computers became more affordable and organizations were able to buy their own hardware, many IT functions were still outsourced. This typically included one-time tasks, such as initial setup of a system and/or network, and custom software development. Many folks also outsourced recurring support and maintenance.
Folks have flocked to software-as-a-service (and its cousins, platform-, infrastructure- and hardware-as a-service) for the same reasons their predecessors went to outsourcing. The benefits include breadth and depth of expertise and efficiency. It’s difficult, especially for a small IT shop, to get exposure to emerging technologies and new methods, much less run these systems. The staff is too busy keeping up with its existing systems and processes to garner any meaningful external experience with new stuff.
Similarly, the same precautions we took with outsourcing must be applied to the aaSes (speaking of sophomoric jokes). First, the Service Level Agreement needs to be closely examined. The SLA defines the services to be provided by the vendor, and the associated levels of availability, response and maintenance associated with these services. The biggest concern with an SLA is typically with availability, or the percentage of time in which a system must be accessible and usable. Of course, the higher the uptime commitment, the more expensive the service.
The other key business consideration is the exit path. How are you going to terminate the service? What is the termination process? How do you get your assets, primarily data, back upon termination? This exit is not easy, so be sure what you’re getting into before you take the jump.
———
John Agsalud is an IT expert with more than 25 years of information technology experience in Hawaii and around the world. He can be reached at johnagsalud@yahoo.com.
