Betwixt and Between: ASPs Meet Web Services

by Michael P. Voelker

• A Sampler of Web Services Offerings (PDF, 631K)

Conventional wisdom has it that the application service provider (ASP) model — defined as renting applications hosted by other providers — is dead. But perhaps the rumors of this market's demise have been greatly exaggerated.

It's true that first-generation ASPs, which delivered entire content management applications via the Internet, have hardly lived up to heady predictions of success. Out of 21 content-focused ASPs Transform profiled in an article in May 2000, only 13 have survived. Fewer still can be said to have flourished.

According to Nadia Khair, an analyst with London-based Ovum, system architectures were a leading cause of failure for first-generation ASPs. "Taking an application that wasn't really written for the Web [and providing it via the Web] is difficult," Khair explains. Compared to applications written with Web delivery in mind, traditional client/server applications "take a long time to get up and running."

Grandiose ambitions also hampered first-generation ASPs. "Some of the first iterations wanted to outsource SAP or something that's more core to a company," says Buck Flannigan, chief technology officer for software services at Chicago-based Divine. "[Applications] that are more along the edge of the enterprise are a better model" for the rented paradigm.

Despite the flaws and failures of first-generation initiatives, technology forecaster IDC of Framingham, MA, says ASP spending in the U.S. has steadily grown from $770 million in 2000 to $1.2 billion in 2001. The firm's March 2002 forecast projects continued growth to $10.8 billion by 2006 — an increase of more than 53 percent over the next five years. IDC says about half of that spending will be on content and collaboration technologies.

Poised for Rebirth

How can these robust figures be reconciled with perceptions of failure? The answer lies in the way the model for service delivery has evolved. Among the categories of ASPs that IDC tracks, Web-native services — characterized by such offerings as Projectplace.com, Atomz and Cytura — are growing much more rapidly (measured by user base) than either first-generation ASP offerings or "software-centric" hosted apps, where the focus is more on the platform being provided rather than the service itself.

Traditional client/server architecture vendors are also making commitments to the Web-native ASP space. In January, Lotus, Cambridge, MA, announced the pending deployment of its Sametime collaboration suite — which includes chat, whiteboarding, presence detection and object and application sharing — as an IBM-hosted, browser-accessed service to complement its client installations and current ASP partner offerings.

"What we're doing will be different from our [ASP] partners who may take our application, customize it and aggregate it into a [vertical market] solution," says Jeremy Dies, offering manager of Lotus' collaboration products. Dies calls the Web-delivered version of Sametime an "e-utility," a use-based system (with charges yet to be determined) that can be deployed without or in connection with a traditional installation of Sametime.

Lotus' direction in its hosting venture also reflects an evolution of the ASP model from providing monolithic applications to delivering single application components. This evolution is being enabled by the development of Web services standards and technologies, an area that is drawing the interest of vendors that had previously targeted traditional ASPs.

Consider Pleasanton, CA-based Documentum, which launched its ASPire program in early 2000 to encourage providers to offer subscription-based use of its 4i eBusiness edition content management platform.

"The market adoption of an ASP model was far less than people had envisioned," says Whitney Tidmarsh, vice president of product marketing at Documentum, adding that the company is making no significant future investment in the ASPire program. "A primary reason we're not making significant future investment is because Web services promise to present a different view of that selling model."

Enter Web Services

Like so many concepts in technology, the term Web services means different things to different people. For the purposes of this article, Web services are applications that interact with other applications via XML-based simple object access protocol (SOAP) messaging. This interaction is typically via the Internet, with universal description, discovery and integration (UDDI) and Web services description language (WSDL) helping users to locate applications. The applications themselves might be offered by ASPs or a collaborative partner. Additionally, Web services technologies can be used to integrate content management and other application components within an organization.

Web services offer programmatically addressable interfaces, allowing their capabilities to be invoked by other applications. Promising flexibility and rapid deployment, Web services will enable businesses to pick and choose best-of-breed technologies in developing customized content management applications.

While no developing technology in IT is ever a sure thing, Web services are definitely not vaporware. In fact, IBM, Microsoft and BEA, which each have competing platforms, recently created a software group to facilitate the development and interoperability of Web services by promoting standards.

What makes Web services particularly promising is the fact that companies will be able to start with point solutions and evolve into an enterprise strategy. As long as the point technologies embrace standardized interfaces, they won't (at least in theory) become a hindrance down the road.

"I consider Web services more of a technical heir to what ASPs were supposed to do, with two differences being that ... they're not monolithic, and they're not people to software; they're software to software," says Matthew Berk, analyst at Jupiter Media Matrix of New York.

Flannigan of Divine notes that true Web services won't encounter the same architectural roadblocks that hampered client/server-based ASPs. "Web services are an evolution, an iterative step, in the ASP model," he explains. "They will allow second-generation ASPs to conduct their business models and realize their potential by breaking down the barriers that firewalls presented to the first round of ASPs."

Last year, Divine acquired content management system vendors OpenMarket and Eprise (among other companies), and Flannigan says the company wants to offer its software as a service wherever possible. Brian Platz, vice president of product management at Divine adds that "the ASP model is due for a massive resurgence, and Web services technology will be a huge catalyst."

Because of their component nature, Web services are particularly good fits for certain types of content management applications. "Something that formats transformations is a perfect candidate," says Tidmarsh of Documentum. "Say you author in Word or HTML; you may want to use a rendering service to [transform] that content to XML, HTML, PDF or wireless formats. Another [candidate] is metatagging — something that can scan through content and extract key words and categories and classifications and store those properties remotely. It's a back-end service that would be a perfect add-on to, for example, a Web content management installation." Tidmarsh concludes that even core content management capabilities could be a candidate for Web services.

It's not surprising that many traditional content and collaboration application developers are building with Web services in mind. "When we develop the APIs, we'll make sure that they work with [Web services] standards," says Lotus' Dies, reflecting IBM's commitment to Web services. "That's a corporate decision."

Entrants in the newer, Web-native application space also are positioning their platforms for this model. Atomz, of San Bruno, CA, offers two Web-native applications: Atomz Publish, for Web content management, and Atomz Search, which brings search capabilities to any Web site. Both products are subscription-based applications. Fees depend on site size and number of users, with typical contracts priced between $20,000 and $50,000 per year.

"We are entirely built on an XML infrastructure," says Seth Brenzel, product manager at Atomz. "All of the elements were built in a way in which we could not only create a Web site management tool, but also open up APIs for import and export of data. We're well positioned to go into the Web services space very quickly."

Roadblocks Remain

Some of the problems related to ASPs, such as bandwidth, won't be alleviated by Web services technologies. Additionally, some technological issues surrounding the software-as-a-service model haven't been solved. In fact, with Web services' potential to deliver components, rather than a single application, some issues become even more problematic.

When creating an application from numerous components, "you may be turning to more than one provider, so ownership of data becomes important," says Berk of Jupiter Media Matrix. "Quality of service on the network is equally [important]."

On the other hand, Berk says, the stability of providers may not be as big an issue with Web services as it was with ASPs because a component from a different provider could be quickly swapped in.

"What is different is that you're not trying to support people [with Web services], you're supporting programmers and systems, and in that respect it's easier to see where the real problems are when they occur," he says.

Management of content raises special issues for those looking to host or consume applications. "There is a real problem with ASP-based document management," says Berk. "Consider that you have a Word document, and you're turning to a provider to manage knowledge about the document, instead of the document itself. There would be a disconnect between the document that lives locally and the data about the document that lives remotely."

This problem is accentuated when turning to a hosted application to control document access and location, if you need to access a document and move it from point A to point B. However, it's less of an issue when using an ASP to manage content — information that's independent of format.

"If you're looking just at content that lives in a database, it doesn't matter if it's ASP or local," says Berk.

Perhaps the biggest concerns about the traditional ASP model for many IT departments have revolved around where the application resides. Worries about the location of an application have both technological and cultural components. Web services can address the first but do little about the second.

Culturally, the main inhibitors around ASPs include control over the data, both from confidentiality and vendor stability standpoints. "If you have financial data or critical information that's sitting in someone else's data center, that really keeps people awake at night, and I don't think that's going to change," says Flannigan. "I don't believe that any technology standards or underpinnings will be a panacea to organizational issues. If you're dealing with data that is core to a company's business processes, that's something a lot of CIOs don't want to outsource."

If Not Now, When?

Even with the potential advantages of Web services, widespread use in content management applications is still months, if not years, away. Most agree with a Jupiter Media Matrix prediction that Web services will have little effect on business models or processes within the next 18 to 24 months.

"If its software-to-software integration within a single company behind the firewall, there are innovators who are using Web services for that now," says Berk. "Developing an infrastructure where your software is a rented Web service, that's farther off. [Developers] first need to come up to speed on new toolsets and approaches."

"We've seen mass support for Web services, but not adoption," says Tidmarsh of Documentum. "We need to see implementation from the other key vendors that make up the rest of e-business architecture. Content management is a component, but not the only one. CRM, billing applications, databases, commerce servers — to really get the benefit of Web services, they all need to adopt and implement the model."

While Web services may well define the future of the ASP model in content management, companies can expect to find more traditional methods of content management applications coexisting with hosted delivery well into the future.

"I would fully expect the prevailing model in the long term to be an outsourced managed model ... but it does need to happen in an evolutionary path," says Flannigan of Divine. "For many years, we'll have to work with a hybrid model of some software deployed in a traditional sense as well as software delivered as a service."

Michael P. Voelker (mvoelker@goequinox.com) is principal of Equinox Communications, Cleveland, WI.

THE ROAD TO WEB SERVICES

The promise of Web services is that they will enable streamlined Web-based business transactions across corporate firewalls. But for now, while issues of security and transaction management are still being worked out, the first practical use of Web services is as a new type of middleware — a way of using standards to simplify application integration.

Web services are self-contained, modular pieces of programming logic that perform specific business functions. These services are accessible over networks in a platform-independent, language-neutral way. Once published, Web services can be located using Universal Description, Discovery, and Integration (UDDI), and they can be invoked across the Web with Simple Object Access Protocol (SOAP).

What does it take for a software developer to extend existing software as Web services? First, the software needs to run on a Web services compatible platform such as J2EE or .NET. The software must be able to accept SOAP requests and pass them along. The software must contain at least one Web Services Description Language file, which describes how a Web service works and how to interface with it.

Software developers must also decide which functions are to be exposed as Web services. "[Software] vendors will say they are opening their applications to Web services," notes Rob Perry, senior analyst at the Yankee Group, Boston. "I'll say, 'have you broken it down to the logical pieces you want to offer as Web services?'"

For example, a vendor may want certain stages of its workflow software to be available as Web services, rather than the entire workflow.

When considering a software vendors' Web services strategy, Perry advises, "You need to look at how the vendors have chosen which functions to expose, and make sure their choices match your needs and the way you want to integrate with the software. You should look at the tool sets the vendor is using. If you're using a BEA application server, for example, make sure the vendor you're working with is compatible with that tool set."

The table below presents a sample of recent Web services announcements from leading content management and portal vendors. Some software suppliers are making their applications Web-services-accessible (accommodating UDDI, SOAP and WSDL) so that other Web services can work with them and pull data from them. Others are also presenting a portion or several portions of their software (such as portal "gadgets" or workflow modules) as Web services that can interact with other applications.

ASP SURVIVOR STRATEGIES

In May 2000, Transform profiled 21 document management ASPs, 13 of which are still in business today (see "21 ASPs and What They Can Do for You," in the archive at www.transformmag.com). We talked to two survivors to find out how their offerings have changed.

Cylex, Boca Raton, FL, continues to offer its iDox document management application, which is built on Documentum's content management engine. Jim Sheen, CTO, reports that Cylex has rewritten iDox using active server pages (versus the original, proprietary technology) and has worked to optimize thin-wire and wireless document viewing. The company also developed a software developers' kit offering Web services APIs based on XML and SOAP to allow customers to tie iDox into their own applications.

Why aren't ASPs doing as well as everyone thought they would? "A lot has to do with marketing and not technology," says Sheen. "Do you provide a horizontal application to a broad market, or do you focus on a vertical market? We've chosen the second [route]. Our end users are independent software vendors that want to enable their offerings with content management, and we know exactly what they want."

The effort to refocus has paid off, according to Cylex, with the company's customer base increasing by more than 50 percent in the last year and many larger deals driving up revenue.

Enterprise content management vendor InterTech of Atlanta launched a hosted offering of its DocuPact software in 2000, but the company has since shifted its ASP business to focus exclusively on clinical coding, a niche market in the health care industry. With a shortage of clinical coders in that industry, health care providers have turned to remote and home-based workers to apply standard codes to medical bills. InterTech's eWebCoding service is based on the ASP model. Like Cylex, InterTech says the changes have paid off. "The last year has been great," says Beth Friedman, director of marketing at eWebCoding. "We have 120 implementations, and the past six months we've been profitable, whereas before we were relying on venture capital. We sign multiyear contracts with hospitals, so we have a steady, projected stream of revenue."

SAFEGUARDING YOUR ASP STRATEGY

If you're considering working with an application service provider (ASP), assess the data security and migration policies in place. Data backup policies and clearly defined "up-time" schedules are, of course, critical in working with an ASP. However, the devil is definitely in the details, and a well-refined contract will mitigate the risk of failure.

"Both sides must develop an exit strategy that defines the key resources, assets and process requirements for continued, effective delivery of the services formerly provided by the service provider," warns Christopher Ambrose, a research director at Gartner, Stamford, CT. "Sourcing agreements often end early for a variety of reasons — cause, convenience, bankruptcy, unusual business changes and changes of control — and contracts must provide for these events as well."

Service recipients must rely upon the ASP to properly protect the most important assets — the data, the application code, business processes and other components that constitute the customer's entire "environment." Beyond the basics already mentioned, customers should also consider the following:

Adhere to industry standards. It's best to work with ASPs that embrace industry standards. Standard database platforms, programming conventions (Web Services, XML, UDDI, SOAP) and commercial off the shelf software will ease transitions that would be more difficult with proprietary alternatives. Mandating the use of industry standards is a reasonable request, and it will ease the pain when and if a transition must take place.

Use a third-party escrow agent. Third-party escrow agents can store and maintain copies of data that must survive the contract. Audit processes should be in place to ensure that the ASP is conforming to its obligation to keep these copies up to date. There should also be a "cure" clause that defines what takes place if these escrow relationships are not established or if data is not regularly updated in accordance with a mutually defined schedule.

Define software ownership. This issue must be clarified at the onset of the relationship. In some cases, the ASP has clear title for the software, while in other cases it is the service recipient who maintains the title. The contract should specify what takes place if the ASP fails and how ownership issues will be resolved, especially if software is being paid for over a period of time.

Develop a transition/exit strategy. If the ASP isn't performing effectively, your contract should give you options. Your strategy should anticipate how the environment and data could be exported to alternative offerings and formats. It's important to regularly verify that the transition strategy accounts for changing data structures as well as updated application source and object code.

— Russ Edelman and Wes Settle