Information Age: News, analysis & insight for IT & business leaders

In enterprise software right now, one of these battles is underway. Peculiarly, though, it has not yet become one of those impassioned struggles that have enlivened the history of IT over the past 30 odd years. That may be because both sides are so strong that confrontation is unnecessary at this point; it may be because it doesn’t suit the marketers to highlight the differences in approach; or it might, perhaps, be because many people see no dispute at all.

So, to the combatants: On the one side of the debate, there is software-as-a-service (SaaS), in which applications are piped down the Internet by third party service providers; on the other, there is the service-oriented architecture (SOA), in which organisations build their own complicated service delivery and management architectures. In the former camp, Google, Salesforce, Omniture, Netsuite and RightNow; in the latter, IBM, Oracle, SAP, and most systems integrators (although some will play for both sides, the revenue sources and business models explain where the true allegiances lie).

Many experts will say that these two camps are not at odds at all, and that the whole thesis is misconceived. They will say both are all about services, some of which are delivered remotely and some of which are created and managed in-house. They will point to companies such as Microsoft, which appear to support both. So where’s the conflict?

Theoretically, this objection is fair. But in practice, the two are truly far apart. SOA is (largely) an enterprise driven, complex, managed, standards-based and highly customisable architecture, designed to enable maximum flexibility and control. SaaS, on the other hand, involves buying external, simple, semi-proprietary services that allow limited customisation. And while SOA is a usually a long term architectural project SaaS can, if need be, be adopted through an ad hoc tactical subscription.

Synthesis?

In the past, disputes of this kind have followed a certain pattern. The new challenges the old, the disruptor takes on the incumbent, and in the early stages, the whole struggle is characterised as all or nothing, one or the other. But usually it doesn’t work out that way; the struggle is resolved not by victory of one over the other, but by a new synthesis, (even if occasionally, a straight victory is recorded).

In this case, it is already clear that accommodation between the two approaches will have to be the answer. Maybe 80% of the enterprise IT world is planning some kind of SOA implementation, and maybe 50% of the IT using world is pretty serious about buying a major SaaS service. The two will have to be  somehow reconciled.

But if this is to happen, it will have to be the SaaS providers that adapt. SOA is complex and standards based because it needs to provide a framework for simple services, such as SaaS, to be effectively delivered and managed. The SaaS providers will have to start asking what they must do to participate in the SOA.

At the moment, flushed with success and gushing from fast growing revenues, few SaaS providers are thinking hard about this. But sooner or later, big businesses will want to bring all their services under control, and those which don’t conform will be isolated.

The SaaS providers already argue that they are adhering to many standards, and are likely to say they are “SOA-ready”. But this is not yet convincing: at the moment, it is right to characterise SaaS as competitive rather than complementary to SOA, and here are some reasons why.

• SOA is compositional – new applications are built by plugging services together. Lightweight ‘enterprise mash ups’ aside, SaaS services do not yet provide enough information, or conform to enough standards, to effectively participate in this plug and play aspect – yet.

• Managers of SOA projects are increasingly focused on policy and manageability. Saas services don’t yet provide enough information to participate in tightly managed architectures. How, for example, can a business ensure that all the ever changing compliance needs are being addressed? Will the service suppliers allow agents into their data centres to monitor service levels, or privacy and integrity?

• SOA processes can require information to be extracted or reported in different ways. Sometimes, it will be synchronous, sometimes asychnronous. Sometimes, it will be XML, other times through ODBC. Increasingly, it will be event driven. SaaS services aren’t yet geared up to support all these requirements – let alone do it dynamically. Some service providers still use basic .csv or Excel spreadsheet files for exporting data.

• If SaaS is to participate in the SOA for process management or compositional purposes, then the applications may need to be broken down into more granular services. That’s not the strategy of the big suppliers today – they offer complete applications. (Although some are starting to offer smaller, granularised services).

• One of SOA’s next big challenges is discovery and billing – how do you find and manage the cost and billing of services. Most SaaS services don’t address this in a standards based way that SOA management tools are able to use.

• SaaS providers such as Salesforce, Google and eventually Microsoft, are planning to build their own ‘ecosystem’ of applications, hosted on their sites. But little attention seems to have been paid as to how these will interwork with each other, let alone with corporate SOA architectures. Salesforce.com’s new language for developing applications is Java-like. That means, presumably, it is not 100% based on standards.

• The information management aspects of SOA are relatively immature, partly because most of the focus so far has been on process, rather than data. But the same is even more true of SaaS. How does the data held in, say, Salesforce.com, conform to the business’s information lifecycle management strategy? A lot more thought needs to be given to policy, security, privacy, records management and interoperability.

At present, SaaS offers such huge financial savings that many of these important strategic and architectual issues are being passed over. And why not? SOA promises flexibility tomorrow, SaaS promises rapid solutions today. But eventually, the two platforms must be brought together.

So if SaaS and SOA are to ‘mash up’, to use the former camp’s jargon, then what will all this look like? First, the ambition and possibilities of the SOA project should not be underestimated: Some SOA proponents think that, ultimately, when SOA is properly implemented, businesses will be able to offer internal services in a way that mirrors and competes with external SaaS services today – only they will be more focused and customisable, and maybe even cheaper.

Most serious business managers dealing with enterprise IT today are deeply concerned with management issues. They understand that policies and standards must be followed – these should be flexible, and not be imposed by distant suppliers attempting to meet the needs of thousands of customers. So it seems likely that while the SaaS suppliers may provide many applications or services, they won’t have a controlling role.

Ultimately, the software industry is moving towards a world that is made up of a number of internal service suppliers, a few closely trusted and probably smaller external suppliers, and an even smaller group of very large, global suppliers providing  a host of commoditised services such as search, or word processing, or Salesforce management.

At that point, SaaS won’t be a revolutionary model, but rather just another example of outsourcing based on the somewhat volatile economics of scale. The best governed, most flexible and economically creative will be using and managing these suppliers using their service-oriented architecture. But that synthesis is some way off.