A December 2006 article in Intelligent Enterprise caught my attention. Titled “SaaS and SOA: Together Forever”, it argues that service oriented architecture (SOA) is what separates the success of the current generation of software-as-a-service (SaaS) providers from the failures of first-generation application service providers (ASPs) in the dot-com era. While SOAs certainly strengthen the value proposition of SaaS offerings, it is giving them far too much credit to say that they are the sole determinant of success.

A SOA does bring significant benefits to a SaaS offering.

1. SOA makes integration with existing systems easier, whether those systems are also SaaS offerings or run behind the firewall.

An SOA’s loosely coupled services could more easily combine SaaS and behind the firewall functionality in a “composite application” that creates an end-to-end business process for users. For example, a SaaS performance management application could pull sales figures from a behind the firewall ERP system, send performance rating information to a behind the firewall compensation management system and then send bonus payments to the company’s ADP payroll system.

Frank Gens of IDC sees SaaS-to-SaaS integration as an important market dynamic: "SaaS service providers will primarily compete with each other on the basis of the richness of their solution ecosystems; that is, customers will gravitate toward service providers whose SaaS solution portfolios best match their business needs. SOA will be the most practical way for service providers to support the massive scale of integration that these large solution ecosystems will require.2

2. SOA makes it easier for SaaS vendors to build multi-tenant architectures that support configuration and customization by their customers. Vendors have learned that even the smallest customers want some control over how their application looks and behaves. Building in configuration and customization capabilities requires an architecture with many levels of abstraction; SOA can provide this.

3. SOA makes SaaS applications more cost effective to operate and maintain. SaaS vendors’ development and operations staff benefit from SOAs’ established models for building code in a consistent way. And the open standards that make up the SOA are ones that are understood by many developers.

On the other hand, many arguments that people use to bolster the SOA-SaaS connection are simply cyber-myths.

1. SaaS was not successful until SOA came along.  Because SaaS and SOA have been maturing over approximately the same time frame, some people argue that SOA made SaaS successful. However, correlation is not causation. SaaS is about solving customers’ business problems in a unique way. Salesforce.com became successful early in this decade by delivering simpler, easier to use, and easier to deploy salesforce automation. In early 2000, I worked with a company called Zantaz (now part of Autonomy) that solved a need for organizations in certain industries to archive their email for compliance purposes. Neither of these companies succeeded simply because of an architecture – they focused on delivering a value proposition that made business sense to their target customers.

2. SOA makes multi-tenancy possible. Multi-tenant architectures (architectures that support multiple clients on a single software instance) are a requirement for running a profitable SaaS business. In fact, the lack of multi-tenant architectures was one of the main issues that kept the first generation of ASP businesses (e.g. Corio, USinternetworking) from becoming profitable. Once again, though, multi-tenant architectures pre-dated SOAs. SOAs can make these architectures more configurable and more maintainable, but they do not make them possible.

3. SOAs solve all of architectural problems of SaaS. In reality, they do not. Two important problems that they do not address today are security and application performance. While web services security standards have come a long way in the last couple of years, they are far from mature. A SaaS business leveraging a SOA will have to build upon the existing standards but plan for future change. In addition, SOAs rely heavily on XML, which is notoriously slow. The SaaS business will need build its deployment environment very carefully to ensure that it will be able to deliver adequate performance to customers.

The most important thing to remember is software capabilities never equate to a business model. For example, how much customization would you really want to give to a SaaS customer? While a customized deployment will meet their business needs on paper, it will be harder for a SaaS vendor to provide effective end user support if every one of its deployments looks and behaves differently. What kind of customers does the SaaS business want to serve? Whether the software is SaaS or behind the firewall, enterprises and small businesses have different needs.

Finally, what about people? Accenture points out that what they call “downstream activities” traditionally account for 50-90% of a customer’s TCO and have a huge impact on overall customer experience. Some of these activities involve software deployment, but many, such as change management, involve people. SaaS and behind the firewall vendors alike need to think not just about technology but about how they can help their customers—people—to run their businesses better.

In summary, SOA is an important component of a successful SaaS business. However, these businesses need to consider much more than architecture if they are to compete effectively today and in the long term.