SaaS and the global virtual stack

When people argue that SaaS is just another deployment option for software, they really are missing the bigger picture. It's as hopeless as a carriage-builder in the early 20th century saying that using motors instead of horses is just another locomotion option for carriages. It ignores the wider revolution that's going to transform the way software gets used, just as the internal combustion egine revolutionized the way people moved themselves and their goods about.

The bigger picture is this: the entire framework of how businesses consume computing and thus automate their information and communication processes is moving to a services model that runs on the global Web infrastructure. Within that software stack, SaaS is a component. But not as an alternative to conventional on-premise packaged software. I don't believe that conventionally licensed packaged business applications will feature in the stack at all. Here's why.

First of all, let's define the stack. The diagram below is based on a slide I recently presented at an Oracle SaaS seminar for ISV partners.

The stack specifically addresses the issues that SaaS providers need to be aware of, but there's nothing in here that shouldn't be in the architecture of any enterprise doing business in the Web era — more on that point after a quick run-through of the five layers in the stack, working from the bottom up.

• Hosted infrastructure forms the foundation layer. This is the physical server and operating system infrastructure that supports the whole stack. In the classic SaaS model, it's hosted at the provider's data center. Today, the emergence of virtualization technology means it could be anywhere — perhaps the SaaS provider is using a cloud computing platform like Amazon EC2, Joyent or Mosso, or perhaps the infrastructure is the customer's own (though probably based at a co-location center). The crucial conceptual leap to make here is that the infrastructure is in the cloud, no matter where it's physically located.
• System services form the next layer. This is a vitally important layer for a SaaS provider, because it contains all the resources that govern service delivery management — security, authentication and identity, provisioning, performance management, monitoring and reporting on service levels, revenue management and customer services. In a continuous-service, subscription-billed environment, these resources are mission-critical, and form a key part of the 'SaaS platform' (as I'll be discussing tomorrow in a panel session at the SaaS Summit in San Francisco — see disclosure). But any enterprise that's moving its IT infrastructure to a service-oriented architecture is going to look for their stack to contain many of the same resources, so although SaaS provides a commercial imperative for having this layer, it's an increasingly ubiquitous requirement.
• Service aggregation is the middle of the five tiers. Whereas the first two layers form the architecture for service delivery, the next three form the architecture for service consumption. Service aggregation is where the data sources are blended — what used to be called integration in the pre-services era, and is now often known as mashups. But at this layer, these are raw, API-level resources. The next layer is where they are made fit for consumption by end users.
• Application composition adds workflow, user interface and other components that arrange the underlying services in a meaningful, productive format for human interaction. In an SOA context, this often comes under the heading of business process management. In a mashup context, it's the client-side widget.
• Multiple clients characterize the final tier. It's not enough to deliver just to the Web browser or to the enterprise desktop. Rich desktop clients, remote-access browser clients and a huge variety of mobile devices all have to be supported — and if the user can switch seamlessly from one device to the next while using the same application and data, so much the better.

Although this describes a SaaS stack, it's just as applicable to an enterprise SOA architecture. It's all about contract-based, autonomous services that adhere to the same principles of separation of concerns to minimize dependencies, allowing any component at each layer to be swapped in or out without having to stop and modify other components elsewhere. It's a generic services architecture stack.

Looking at this stack, two attributes stand out that are accelerating the rise of SaaS and other cloud providers.

• It's complex. The expertise to build a stack like this and maintain it up-to-date — especially in aspects such as keeping it secure from intrusion and supporting every new generation of mobile device — is moving beyond the competence of most enterprises. At the same time, providers are growing in their competence to provide reliable services that remain up-to-date with fast-moving technology, and as they do so the economies of scale begin to move in their favor, making it less and less viable for all but the largest enterprises to follow the do-it-yourself route.
• It's virtual. What we're seeing here is the emergence of 'the Global SOA' — a common shared infrastructure for computing that spans and connects every enterprise and service provider across the globe. SaaS is a component within it because clearly some enterprises are still going to operate their own service infrastructure. But they'll also consume some services from external providers (and from other enterprises) and they may choose to host part of their infrastructure with cloud providers. That's why I prefer to call this the 'global virtual stack'. It's more than just a SaaS stack, which implies that everything resides outside the enterprise, and more than just an SOA stack, which implies that everything resides inside the enterprise. The stack is virtual because it's neither wholly external nor wholly internal. It's everywhere.

So here's my parting thought, coming back to my original assertion about there being no place for conventionally licensed packaged business applications in this stack.

I can see why service providers would want to buy licensed software to build their service delivery stacks (although I suspect they'll be more likely to use open-source alternatives). But a conventional packaged business application sold on a perpetual licence looks to me like a fish out of water in this service-based architecture. How do you provision and bill for usage? What's its API for data aggregation? How do you compose functionality from other applications into its user interface? Can you embed functionality into other application UIs? Unless it's architected exactly like a SaaS application that follows the stack architecture I outlined above, I don't see how it works. And if it is architected exactly in that way, then it's an academic question (or, more probably, a matter of simple economics) whether the provider is the enterprise itself or a third party.