Early ASPs Saw Needs for Standards
Three-and-a-half years ago, in the first flush of the ASP boom, a dozen Internet-native ASPs banded together in a quest to establish standards that would enable their customers to combine Web-based services from multiple providers.

Calling themselves Internet Business Service Providers (IBSPs), each member of the group specialized in a single class of application, including human resources management provider Employease, e-mail provider USA.NET, time management and invoicing provider Timebills.com (now known as professional services ASP OpenAir), and several others who ultimately failed to survive (see New Group Champions BSPs).

Subsequently joined by Web services aggregator Jamcracker, the group began mapping out the technology areas where standards would need to exist in order to achieve the ultimate ideal of seamless aggregation of multiple services. They found that, the more they looked at the proposition, the more complex it became.

Integrated access was just the starting point. Once users had logged in to a package of services from multiple providers, there would need to be agreement on how to handle billing, usage reporting and session management. There had to be standards for exchanging data, and for business process integration. The group decided to concentrate its efforts on the first step, and subsequently threw its weight behind SAML (Security Assertion Markup Language).

Three years later, SAML is finally due to become a formal standard for exchanging information about user identity and access rights. Meanwhile, the evolution of Web services has begun to fill in some of the other missing elements. At the same time, there's been a growing consciousness that too much prescription is sometimes a bad thing when defining standards for integrating multiple services.

Devil in the Details
The proposals from the Liberty Alliance illustrate the virtues of this latter point of view. The group could have gotten caught up in trying to devise standards that would cope with all the niceties of privacy, security and user autonomy that might crop up when exchanging identity and access information between providers. Instead, its 1.0 specification neatly sidesteps all of these issues by creating a unique code that allows two providers to recognize a shared user, without either of them having access to any of each other's information about that user (the user could even be registered under two completely different names).

This hands-off approach to aggregating services moves away from attempting to tightly integrate services with each other — which is where the IBSPs' efforts started to get bogged down in complex details — and instead allows them to join in a loose federation. What's interesting is that a federated approach still allows the user to exchange data and link up processes between multiple services, without tying the user into a hardwired relationship.

In other words, it's an approach that lets the user control the links and connections, rather than attempting to have the system do it all, and it's typical of the newly fashionable services-oriented way of thinking about computing, rather than the old systems-centric models. Although it requires a more open-ended architecture, it provides more choice and flexibility for users to create innovative solutions to their day-to-day business needs.

This is a development that many in the IBSP movement will gladly welcome. While researching this week's column, I looked at an article I wrote in April 2001, in which Chris Haddad, then chair of the group's technical committee and also engineering manager at Employease.com, warned against having too much of a focus on data integration: "The direction the industry should take is enabling business processes and enabling services around those business processes," he said. "People should start focusing on what processes they can enable for customers rather than how we can exchange data — not 'How does my legacy system think about data?' but 'How can we do this differently?'"