Strategy Process Section 001 Blog

Thursday, February 14, 2008

Written by Greg Olsen

Imagine that your friend tells you that he has an idea for a new Palo Alto, Calif.-area restaurant that he wants you to invest in. His pitch goes like this: The restaurant is all about self-sufficiency. In addition to actually serving good food, this restaurant will feature the following:
• All food served will be organically raised and processed on-site
• Power will be provided by an on-premise power plant
• Water will be provided by a well-and-rain capture
• A self-contained waste management system will eliminate the need for a sewer hookup

While there are probably some people in Palo Alto that might actually think this is a good idea, you being of sound mind respond, “Is this a joke? Why build basic infrastructure like foodstuff production, water, sewer, etc. when very efficient, cost-effective, ‘pay-as-you-need-it’ options already exist?�

Imagine that your other friend tells you that she has an idea for a new software application company she wants you to invest in, and that this company (in addition to actually creating a useful service-based application) will:
• Build and manage redundant data centers with a carefully constructed custom hardware and software stack
• Set up an advanced network peering infrastructure for redundancy and improved latency
• Implement a flexible payment system for customers and channel partners

This could also be misconstrued as a joke. Why would a small application provider spend so much capital, time and energy building infrastructure when readily available ‘pay-as-you-need-it’ services exist, such as compute, storage and network infrastructure services (e.g. Amazon’s EC2 & S3 services), and payment services from Google, Amazon, etc.?

It is possible that specifics of your friend’s application make use of available service options infeasible, but it is just as likely that your friend has simply not yet adapted to a service-based infrastructure reality. There are always seemingly good reasons to continue doing things the way they were done in the past, and transition always presents challenges. As ironic as it may be, we continue to see software applications deployed as a service but which fail to use any service-based infrastructure themselves. They are two basic reasons for this situation: Change of existing operational services is hard. So is changing people behavior.

Once an application service is deployed, infrastructure changes are hard to make. Often commitments of capital cannot be undone without very high switching costs, such as advanced purchases of compute and storage capacity. Many architectural choices can have lasting ramifications.

For example, if a provider built their application based on the assumption of very large SMP servers, a proprietary commercial database clustering approach and vendor-specific HA infrastructure, they would find it difficult if not impossible to move to a service-based infrastructure that’s based on generic hardware/software platforms and horizontal scaling.

Even for a new application service, it’s often hard to find people who will embrace disruptive infrastructure options. It is almost inherent in human nature that once we develop a difficult skill we are reluctant to give up using it — even after simpler and more efficient alternatives become obvious. Often, people perceive that their livelihood is tied to the skill and then fear their own obsolescence in the obsolescence of the skill. The history of software applications provides a rich set of examples of this phenomenon. At one time, it was common for software application providers to create their own hardware, operating systems, networking infrastructure, languages, compilers, user interface technology, etc. Eventually, successful application providers took advantage of standard hardware platforms, operating systems and languages — to the detriment of the many providers that clung to the prior model. Likewise, vendors that leveraged the Internet and application servers gained, while many others continued to cling to proprietary client/server architectures and were the worse for it.

The recent “software-as-service� phenomenon is a particularly interesting example of disruptive change. SaaS was first seen as a disruptive force inside of the IT groups of large application users. Most companies are starting to understand that they would be better off with less information technology on their premises and more of it procured as a service over the Internet. Still, however, many within IT organizations are reluctant to embrace this form of change. (Personally, every time I see an IBM Blade Server commercial during a major sporting event, I’m wondering what percentage of the viewers know what it is, what percentage of those could actually affect the purchase of one, and then what percentage of those should actually be buying data center servers in an efficient universe).

We are now at point where implementors of SaaS capabilities are being disrupted by newer SaaS capabilities. Services that are built largely from other services are a reality, and offer many clear advantages. The types of services that could be used in the creation of new services span the spectrum, from base infrastructure services to complementary high-level application services that can be composed or mashed up. Example services include: compute and storage services; DB and message-based queuing services; identity management services; log analysis and analytic services; monitoring and health management services, payment processing services; e-commerce services like storefronts or catalogs; mapping services; advertisement services; in addition to the more well-known business application services like CRM and accounting.

The move to SaaS applications built on SaaS is a much more profound shift than the move from on-premise applications to SaaS applications. The software industry is beginning to display characteristics that mimic the supply chains and service layering that are commonplace in other industries like transportation, financial services, insurance, food processing, etc. A simple set of categories like applications, middleware and infrastructure no longer represents the reality of software products or vendors. Instead of a small number of very large, vertically integrated vendors, we are seeing an explosion of smaller, more focused software services and vendors. The reasons for this transition are simple: It takes less capital and other resources to create, integrate, assemble and distribute useful software capabilities.

By leveraging service options like Amazon’s EC2 and S3, a small company can deploy a complex, highly available and scalable multi-user software application — without huge upfront investments in hardware or software infrastructure. Likewise, a very small company can build a simple, narrowly focused service and can cost-effectively sell it to a mass audience. Neither of these companies would have been possible only a short time ago.

A new software service economy is rapidly unfolding and is causing disruption in the software industry. Ironically, some of the first victims of this new economy may be some pioneers of the software-as-a-service movement. Today, many established SaaS application providers are applying much more of their precious focus and capital to infrastructure issues than newer competitors that are aggressively utilizing service-based infrastructure. The self-contained restaurant and the build-it-all-ourselves SaaS application vendor both have seemingly good rationales for their chosen paths, but both will ultimately end up as anachronisms that are left behind by their competition.