Friday, October 22, 2010

On Software as a Service

True, the traditional view of software commercialization may go the way of the slide rule and the typewriter, but there will always be a need for the services that software provides. However, the ability to access software services depends heavily upon the enabling of shared infrastructure from companies providing hosting, data storage and networking and telecommunication services. This infrastructure should continue to move towards standardization to facilitate the kind of “plug-and-play” flexibility the market demands. The ongoing standardization of emerging “middleware” technologies supporting distribution and access of services via service interfaces will have an impact comparable to that of the world-wide-web.

Software as a Service (SaaS) is exploding nowadays. Google’s application suite is an instance of SaaS providing generic horizontal services. Function specific products such as GoTo Meeting and WebEx for meetings along with Sales Force Automation, a more focused horizontal SaaS tool have been gaining significant market share over traditional competitors. This explosion also includes vertical industry applications. Thousands of hotels use TravelClick for reservations; the health care industry has hundreds of SaaS applications for patient management, ambulance services, etc. Plus remember, ultimately, Facebook and Twitter are nothing more than social media SaaS environments.

Despite all of this, SaaS is not a panacea—at least not yet. The model has to mature and as a result, the range of options, costs and enrollment mechanisms is still too varied and complex. Most significantly, SaaS systems need to find the right balance between functionality and flexibility; plus the model presents a list of new security considerations. Are you comfortable having your company’s most sensitive data out there, somewhere in a cloud?

Take heart though, standardization breeds commoditization, and a result of standardization is that in the future there will be a consolidation of service models and expected features. This consolidation is also being facilitated by the emergence of the “Cloud Computing” model that essentially makes the infrastructure services supporting SaaS invisible to the user. Large vendors are already introducing sophisticated virtualization, security, and management tools that will enable SaaS providers to offer an expanded range of configuration and portioning models to their clients.

But SaaS does not necessarily need to be wholly based on a centralized service delivery. The paradigm also applies to distributed services such as those provided to smart-phones. Already the paradigm for the booming smart-phone market is that of downloadable “Apps” with modules providing functions. Some Apps run entirely standalone, but others provide a front-end that can access powerful backend systems. Google is making available a suite of shopping Apps that instantaneously leverage the powerful Google server environment displaying reviews, alternative prices and so on. The popular Shazam is a complex application that tracks and recognizes tunes being played, and there are a myriad of widgets for all kinds of things. The user, particularly the younger user, no longer views these Apps as software. The kid downloading a ring tone is not buying software or data but a experience. The fact is that many of the Apps providers are now moving away from straight purchase models and toward service subscription or ad revenue models.

Now, so far I have discussed that the SaaS paradigm appears to be a consumer of services. The question is how will your company fit the upcoming Infosphere economy and how will this impact your very own IT strategy. What kind of SaaS is your company planning to offer, if any? When you envision the IT system of the future, you need to ascertain how you are going to play in this brave new world, as a provider of software services, a user or both. This includes defining the manner in which you will make your IT services accessible to users. When doing this, you will be glad you followed a comprehensive SOA strategy as the baseline for the IT transformation.

In a way, SOA is a necessary (tough not sufficient) element for the habilitation of SaaS. SOA systems intrinsically create services that can be selectively commercialized under SaaS. The SOA services become SaaS services. In other words, the concept of Software as a Service will evolve into the more prosaic “Service as a Service.” This statement seems obvious, but it has deeper implications . . . a complex SOA system may well consist of an interplay of components. For example, Provider #1 of service S1 may access a second service, S2, from provider #2r #2, who may depend on service, S3, from Provider #3, and so on. The user needs only sees the integrated service provided by provider #1 and can be oblivious of the value chain behind the original service request. In essence, SOA enables the replication of the way traditional value chains operate, except now we are using digital means. Just like real markets, SOA systems can become incredibly complex. Their support has to be structured in such a way to allow quick resolution of issues presented by complex, intertwined value chains. There has to be clear accountability lines.

Having said this, I am doubtful that mission-critical IT systems should ever rely entirely on external SaaS services. I firmly believe that technology; some technology anyway, will always be a weapon to attain commercial advantage and to enhance one’s competitiveness. Don’t buy into the idea that all software will become so commoditized that it will be something you can always provision externally—a simple utility provided by SaaS. General purpose business software such as ERP systems? Use them as a commodity. These systems do what they do. Being able to process payroll or accounts receivable internally is not going to give your company a competitive advantage (I am sure though there are exceptions to this!) But there will always be that little extra function, that cost cutting algorithm or automated innovative process, that will not be available externally, either because it represents a core intellectual property asset of the company or because the cost or risk of placing it in a external environment is not acceptable.

The question then is “What services should you endeavor to create rather than purchase?” The answer to this question depends on an analysis of what are you trying to get out the service: Data? Content? Wisdom? More on this next…