Enterprise mashups: a lesson from history

A group of breakaway ASPs grappled with exactly the same problems back in 1999/2000 that Web 2.0 pioneers face today in bringing mashups to the enterprise.
Written by Phil Wainewright, Contributor

David Berlind wonders what obstacles to mashing up mission-critical enterprise applications we're not paying attention to, citing identity management as the biggest unnoticed elephant in the room. Well, here are some more.

More than half a decade ago, a group of young startups formed an organizationTranslating mashups into enterprise-class applications is different story called the Internet Business Services Initiative (IBSI). Regarded at the time as a breakaway group of ASPs, they were early precursors of what we now recognise as Web 2.0. Here's a hauntingly prescient quote from Doug Sallen, senior VP at On The Go Software, one of the charter members, from a news story I wrote about IBSI's formation in December 1999:

"The real promise of the web is with applications that are written in HTML and Javascript and allow you to use all the scalability and power of the web but not in the old outsourced fashion."

AJAX and mashups do exactly that, but although the Web 2.0 generation takes this kind of application for granted, it faces exactly the same problems of integration that IBSI faced back at the turn of the new century. While it's true that the emergence of web services standards have made mashups much easier to create, translating them into enterprise-class applications is a different story.

The problem for IBSI's members, offering on-demand applications before the era of the mashup, was that they were all one-trick companies — On The Go offered an expense management application, other members offered book-keeping, timebilling, online procurement, sales force automation and so on. They realized that as soon as they started to get traction in the market, customers would want to start integrating these various point applications, and they needed a set of specifications that would enable them to do this.

It took them till the following October just to agree the full list of specifications they needed to define:

  • Integrated access
    Single sign-on
    Account provisioning
  • Integrated usage
    Consolidated billing
    Common look and feel
    Co-ordinating support and SLA responsibilities
    Shared reporting metrics
  • Data integration
    Key data sharing
    Data extraction and backup
  • Business process integration
    Workflow integration
    Policy integration

They managed to get single sign-on ticked off the list with the creation of SAML, which several members participated in — including Jamcracker, who I wrote about last week  — but by then the dot-com crash had wiped out many members and the group had already disbanded.

Five years later, some of the other points on the list are starting to get covered off by WS-* and related web services standards, such as BPEL. But look at my 'integrated usage' heading in particular and you'll see how much ground still needs to be covered. That's why 'Web 3.0' is my shorthand term for the technology that brings Web 2.0 and on-demand applications into the enterprise — to underline just how much further we need to progress before we're there.

Editorial standards