The Smoking Gun

Although everyone had a motive, ASPs will ultimately be responsible for the death of the packaged application

Stewart McKie

Sometime soon you can expect to read this announcement in your newspaper's obituary column: After a short illness, early in the new millennium, we lost a dear friend, the packaged application. No flowers please, send any donations to the ASP Industry Consortium.

Although packaged applications aren't obsolete yet, they are definitely on the endangered species list. And I'm not the only person who thinks so. Bob Crowley, president and CEO of Bowstreet said, "We think Business Web Exchange [Bowstreet's product - naturally!] will lead to the death of applications. Applications have to have APIs and have to be hard-wired into your system. With this technology you just dynamically use a service when you need it and then get rid of it" (InfoWorld, March 17, 2000).

The Shortfalls of Shrink-Wrap

Browsing the shelves of software stores has been a favorite occupation of consumer computer users for more than a decade now. But for businesses, delivering their applications as shrink-wrap packages has never been ideal. As soon as they are delivered, packaged software and manuals are essentially out of date, necessitating the regular application of service patches and replacement of obsolete manuals. Each release revision from the vendor triggers a major IT change management exercise at a user site. Furthermore, recycling packaging, manuals, CDs, and disks is a major cost and time burden for large organizations. And despite slick installation wizards, software vendors never quite got packaged software to install incident-free every time.

For these drawbacks alone, IT departments will probably not mourn the passing of the era of packaged applications. But the blossoming business love affair with the Internet is what has driven the nail into the packaged application's coffin.

ASP Bite

Cleopatra was killed by a bite from an asp, and another kind of asp - an application service provider (ASP) - may prove just as lethal for packaged applications. ASPs manage applications hosted on servers connected via the Web and accessed over the Internet. Today, ASPs offer hundreds of applications, ranging from desktop productivity tools such as Microsoft Office to full-blown ERP systems such as Oracle Applications or SAP R/3. In addition, the ASP rent-an-application model is as appealing to small businesses with little or no IT resources as it is to Fortune 1000 corporations with armies of IT staff.

Because ASPs manage the technology infrastructure to run the applications, businesses don't need to worry about upgrades or data backups. Increasing the number of users, wherever they are located, is as easy as clicking an "I Agree" button. Furthermore, the monthly user or transaction-based subscription model is easy to understand and the costs scale predictably, helping CFOs with their cash-flow models and ROI calculations. Although legitimate concerns about security, service downtime, and an inability to customize the applications do exist, you can mitigate these issues with provisions in the service level agreement (SLA) that you negotiate with the ASP.

If Internet capacity can keep up and broadband connections become more widely available, hosted applications will probably prevail over packaged applications. Certainly all the analysts are predicting stellar growth in ASP revenues over the next five years - an IDC study, "Partnering with ASPs - An IDC Priority Partners Study," predicts that spending on ASP services will grow to $7.7 billion in 2004 from $300 million in 1999. But until all applications in every business are hosted, businesses will need Internet application collaboration (IAC) middleware.

Internet Application Collaboration

For some years now, enterprise application integration (EAI) has been all the rage as a result of the need to integrate mission-critical "legacy" applications with the new ERP systems many larger businesses rushed to implement in the 1990s. But traditional EAI's focus on integrating applications running "inside the firewall" is switching to a combination of packaged in-house and hosted external applications that will demand a new category of middleware, IAC software. IAC can be software or services, and vendors such as OnDisplay Inc. (recently acquired by Vignette Corp.) and Tibco Software Inc. already deliver what some might term IAC software. This new generation of EAI software expects to work with data sources located on the Internet and recognizes Web-based data formats such as HTML and XML documents. Other vendors such as Jamcracker.com are focusing on a service to help manage multiple hosted applications and eventually help them talk to each other.

As businesses transition from the use of in-house managed packaged applications to a mix of in-house and hosted applications, IAC software and services will become a vital part of the IT management landscape. However, in order to succeed, IAC depends on some standard mechanisms being in place to facilitate application-to-application and server-to-server collaboration - which is where extensible markup language (XML) comes in.

XML Interfaces and Exchanges

XML, with its ability to describe data and its context, provides the ideal mechanism to make IAC a reality. XML stands a chance of becoming what EDI and Microsoft's COM initiative both failed to become - a pervasive, cross-platform standard for application-to-application data interchange. But before this paradigm shift can occur, a number of other events must happen first.

First, every application needs to expose an XML interface for the purposes of sending and receiving data between applications. Specific applications need to support specific XML schema standards, such as the XML-based financial reporting standards proposed by the XBRL body (see www.xbrl.org) to manage common types of information exchange that business-to-business (B2B) buying and selling activities require. Independent industry bodies should formulate these standards to ensure they remain open and not dependent on any one vendor's proprietary technology. Then, companies need a way to manage these XML-based IAC transactions securely and reliably.

Market leaders such as IBM, Microsoft, and Oracle all recognize the importance of XML and have announced strategies and delivered tools to help accelerate the momentum of IAC. As usual, Microsoft's efforts in this area have achieved high visibility via its BizTalk Framework initiative and impending BizTalk Server product release. But many other best-of-breed vendors are also operating in this space, and which company will dominate this critical market is still unclear.

What is clear is that you do not need to install new XML exchanges in-house to reap their benefits. An ASP can host the software to manage XML exchanges, which can act as a Web-based collaboration hub to connect businesses in a many-to-many fashion. Clearly, this business is an attractive model for Microsoft and others, because the potential for capturing tollbooth revenues from growing B2B application-to-application Internet traffic is enormous.

The potential of an XML interface in every application will certainly enable a boost in B2B e-commerce, but it may also change the way that applications themselves are expected to function as they switch from a tightly coupled to a loosely coupled mode of operation.

Loosely Coupled Apps

An ERP system's major attraction is the tight integration between a functionally broad and deep set of modules. But the drawback of this tight integration is that it makes it harder for vendors to "rev" isolated parts of their application to combine their modules with another vendor's modules to keep up with best-of-breed applications or technology broadsides such as the Internet. Both the demand for Web-enabled applications and the interest in integrating ERP with customer relationship management (CRM) suites have exposed this drawback: ERP vendors are scrambling to partner with e-commerce and CRM application vendors in order to plug these gaps in their ERP deliverables.

But once every application contains an XML interface, applications will begin to operate in loosely coupled mode. An application will not be a single package but a sum of parts comprising packages and services from multiple vendors or ASPs that appear to function to users as a single whole via portals that represent their "workview."

Loosely coupled applications also signal another death-knell for the packaged application because companies will not want to buy a single all-encompassing package from a single vendor. Instead, they will want to plug-and-play at an application module level in order to take immediate advantage of new releases of software and services - instead of waiting for ERP vendors to acquire or ally with the desired vendor of the package or service. As an example, SAP is already showing one direction that loosely coupled apps could take with their MiniApps initiative, which encourages third parties to build applets that can be added to SAP applications to enhance or extend their functionality.

But eventually, even ERP suites may no longer exist. Instead, vendors may deliver an application framework into which applications can be plugged to run in conjunction with other applications. A key part of this framework will be its ability to use an XML exchange server for app-to-app integration and the managing of business document exchange transactions. The ERP vendor may supply some or many of the applications in use, but these will be supplemented by other best-of-breed and hosted applications loosely coupled together via the framework.

What Does It All Mean?

The impending death of the packaged app has already caused its first casualties, the disappearance of the Egghead Software store and others like it from your local mall. But it also has many other implications beyond ending the hassle of figuring out what to do with old software CDs, including:

• More software vendors becoming ASPs and delivering their software wholly by rental, fundamentally changing their business model in the process
• The extinction of software piracy (Other than hacking in, how do you copy a hosted application?)
• The increasing importance of the software license, in the form of an SLA, in the customer/supplier relationship, with consulting firms offering SLA analysis and negotiation services
• The media giants, such as cable and TV providers, eclipsing the biggest software providers because of their familiarity with subscriptionbased sales and delivery models and their access to large consumer user bases
• XML exchanges and plugandplay application frameworks becoming a vital part of every IT infrastructure and every application becoming an "open" application via an exposed XML interface
• Whole business processes, such as the timeconsuming compilation of monthend financial statements in multinational businesses, being wholly reengineered as hosted applications that communicate with each other and automatically generate "firstcut" consolidated financial statements for electronic dissemination around the world
• Finally, another major benefit from the use of hosted applications over packaged applications results from clickstream analysis. Providing they have optin permission to do so, the ASP hosting provider managing the application can collect a lot of useful clickstream data about how an application is being used.

And because ASPs collect this information across multiple users and multiple clients, it will be an invaluable way of:

• Improving the application delivery infrastructure to reduce performance bottlenecks
• Improving the application functions to fix bugs or make the function easier to use
• Crossselling other products or services, such as more training courses or consulting.

Hopefully, the results of this clickstream analysis will benefit both the ASP and the application users by resulting in faster, less error-prone, and more functional applications. At least that's the theory.

Packaged apps won't die overnight, so you'll be stuck with shelfware for a while yet. But someday soon you'll be able to show your children a little urn in some museum somewhere containing the ashes of the last packaged application. RIP.

Stewart McKie is an independent software analyst and technology writer who can be reached via his Web site, www.cfoinfo.com.