October 13, 2003 4:00 AM PDT
Software makers look for profits in e-forms
- Related Stories
Adobe e-doc format under siegeSeptember 18, 2003
Online forms standard gets a pushAugust 5, 2003
Adobe expands e-forms pushJuly 15, 2003
Will firms balk at Microsoft's program?March 6, 2003
Microsoft moves ahead on XDocsFebruary 10, 2003
Microsoft, Adobe in document duel?December 23, 2002
Adobe extends server push to AcrobatOctober 20, 2002
Microsoft, Adobe and others are pushing XML-based electronic forms as a way to automate business processes and make it easier for corporations to take advantage of their data.
The forms metaphor offers a useful interface for getting data into corporate computer systems and allowing it to be shared by various departments, but e-forms projects are only a midlevel priority for most businesses now.
The sudden rush into the market is being fueled by the potential for big profits. Right now, American businesses alone spend upward of $15 billion transferring data from paper-based forms such as loan applications and purchase orders to their computer systems, according to analyst estimates. Software makers are banking on a desire among businesses to trim those costs.
The software companies' interest in e-forms also stems from the growing adoption of Extensible Markup Language (XML) as the common language of business data. Collecting data electronically is only half the problem--it still has to be easily transferable to whatever department needs it. XML-based forms are designed to automatically shuttle data to various back-end systems, such as corporate databases and customer relationship management (CRM) setups.
"We feel like Microsoft and Adobe have cast a big spotlight into the e-forms domain," said Dennis Clerke, CEO of Cardiff Software, one of the smaller companies jumping into the fray.
Microsoft is set to intensify the scramble for customers in the nascent e-forms market later this month when it releases InfoPath, a key new application included in Office System, a family of applications that revolves around the company's widespread productivity software.
While InfoPath is expected to be used mainly by employees for internal business processes, Adobe is looking to tackle a wider swath of customer interactions with an e-forms approach that casts its widespread portable document format (PDF) as a basis for creating and processing easy-to-use e-forms suitable for loan seekers, online shoppers and other members of the general public.
A host of smaller companies, meanwhile, hope to play it down the middle with e-forms packages based on various flavors of XML, including the recently finalized XForms specification from the World Wide Web Consortium (W3C).
Although each e-forms approach shares common goals for automating business processes using XML to exchange data, the strategies differ in key areas.
Microsoft's arguments in favor of InfoPath include a presentation format that mimics other applications in the Office System. Instead of looking and acting like a jazzed-up Web page, InfoPath forms will appear to users as a slight variation on the types of office documents they already work with, said Rajesh Jha, Microsoft's general manager for InfoPath.
"You get not only the flexibility of the document but all the power of a form; all the business rules are maintained," Jha said.
That means sharing of forms is limited, however. Any XML-capable application, such as a Web browser, can view data output from InfoPath, but users will need the full $199 InfoPath client to input data. Analysts say that means InfoPath adoption is likely to be restricted to internal processes, such as human resources tasks, rather than connecting with clients and general consumers.
"They really designed it for addressing workgroup, workflow problems, and I think Microsoft has a pretty compelling argument there," said Joshua Duhl, an analyst for research company IDC.
But is it too complex?
InfoPath has also drawn criticism for the complex interface users must master to create forms and link entries to back-end functions. That complexity is likely to prevent InfoPath from gaining the same widespread acceptance as other Office applications, analysts say.
"To construct a form (in InfoPath), depending on how sophisticated a form it is, that can be a fair amount of work--a couple of days worth for a well-trained programmer," Duhl said. "There's some scripting you have to do, some Web services calls--you have to have a knowledge of your infrastructure."
Although the more technical aspects of InfoPath development are likely done by information technology departments, Jha acknowledged, the less technically inclined can still be productive with the application after a little training. Beta tests showed that midlevel managers found it useful and practical to create forms to address department-level problems, he said.
Jim Fulkerson, manager of marketing field communications for Hewlett-Packard, said InfoPath helped improve the process his department goes through to put together Web-based sales materials. Previously, one of his workers would manually aggregate information from sales and marketing meetings into a Word document that was placed in a content management repository. "It was a four-hour process at least, just to do the cut and paste to produce the document," he said.
Using a trial version of InfoPath, his team developed a form that automatically routes sales data to appropriate channels. Putting together a sales document takes only a few minutes now, and data from one document can more easily be reused in others.
Meanwhile, Adobe's approach to e-forms revolves around PDF, the format most organizations already use to electronically distribute forms for home or office printing. Existing or newly created PDF forms can be teamed with Adobe Document Server to turn them into intelligent documents. The server software connects XML data embedded into the form to automatically route data submitted in each field to relevant back-end computing systems.
Harry Vitelli, Adobe's vice president of business development, says a PDF-based approach has a number of benefits, including the widespread adoption of the free Adobe Reader software for viewing PDF files, and the ability to easily turn existing print-oriented forms into interactive documents.
"You're not going back and redesigning all your forms, because most of them are already in PDF," Vitelli said. "For the user, the great thing about PDF is that it's familiar and reliable--it always looks, smells and tastes like paper."
While most computer users are familiar with PDFs as static documents, Adobe added interactive potential last year with Adobe Document Server, server software that also helps leverage existing resources by serving as a neutral intermediary between the Reader client and back-end systems. The server software reads XML data embedded in PDF forms and uses it to route data to appropriate databases and other resources.
Ron Schmelzer, an analyst at research company ZapThink, said familiarity with PDF as a distribution mechanism will help establish it as the preferred format for handling external e-forms, as opposed to InfoPath's focus on internal processes.
"I think it'll be PDF that's more the solution for communicating across the firewall, and that's really a matter of mindshare," Schmelzer said. "When a company thinks about distributing documents outside their firewall, they don't think about (Microsoft) Word; they focus on PDF."
"Acrobat (Adobe's family of PDF authoring tools) has that mental leadership," Schmelzer said, "and it has the perception of being good at retaining formatting wherever the document goes, which is really important in forms--everything has to be in the right place."
The middle ground
Between software giants Microsoft and Adobe are many smaller companies offering e-forms packages that use XML and usually require nothing more than a Web browser as the interface for data input.
Cardiff Software, which started in the early 1990s by selling server-based software for managing e-forms, sells Liquid Office, an application that uses standards such as Java and XML to parse online forms for consumption by back-end software.
"Our business model is predicated on the servers that automate the business processes behind the forms," CEO Clerke said. "We let the user decide what format may work best for them for a given business process."
Cardiff plans to support InfoPath and already works extensively with PDF. Clerke expects Cardiff to provide some of the server capability missing in both companies' e-forms approaches. "We're embracing the same messages they are," he said, "but both of them are focusing on the client. Our approach is all about embracing open standards. Our view is to take a server approach and be client-agnostic."
As part of its standards approach, Cardiff is supporting XForms, a forms-based XML specification published by the W3C, the main governing body for Web-related standards. ZapThink's Schmelzer says XForms has the potential to alleviate confusion among different XML dialects supported by e-forms companies, but it will take time.
"It's XML, so theoretically anything can produce or consume it, but it's a very specific vocabulary for whatever approach you take," Schmelzer said. "XForms could help people centralize on one vocabulary, but there are very few servers now that are capable of handling XForms-submitted information. I think it'll take a few years before XForms gains any widespread attraction, just because of the processing challenges."
Early XForms backers include PureEdge Solutions, which created and published one of the first XML-based forms specifications, XDFL. PureEdge CEO Mark Upson expects XForms will help the e-forms industry standardize, as the format matures.
"We think it'll be an important standard moving forward, but they haven't really taken it to the level where it needs to be," Upson said. "It will probably be in XForms 1.1 or 1.2 where it has all the functionality companies expect."
Upson said that as more companies experiment with e-forms projects, they'll come to insist on straight-up XML, without proprietary document formats or data approaches.
"A lot of the hard work with Microsoft and especially Adobe solutions is going to be just feeding a database," Upson said. "Customers are not going to put up with large integration projects much longer. They want vendors who are going to deliver business value quickly and enable them to accomplish specific business tasks on top of their existing infrastructure."
Early e-forms adopters have included government agencies. The U.S. Air Force recently switched 18,000 online documents from an early proprietary system to an XML-based package from PureEdge. Carolyn Watkins-Taylor, director of the Air Force's Departmental Publishing Office, said an XML-based approach was critical to allow data submitted via forms to circulate among the disparate government computing systems.
"It's very important to have something that can interact with legacy systems," Watkins-Taylor said.
Such government agencies are emblematic of the organizations with massive paper-based forms processes that have already embraced the concept of e-forms. Further adoption will take time, Schmelzer said.
"I can't say we've heard e-forms being a top priority for anyone," Schmelzer said. The (return on investment) is there for a company that spends a lot of time processing forms--think of something like an insurance company handling claims--but most organizations aren't like that."
IDC's Duhl agreed. "There are bigger challenges competing for attention now," he said. "It's not like Sarbanes-Oxley compliance, where IT departments are really under pressure now."
Duhl expects enterprise software sellers such as SAP to play a major role in promoting e-forms projects, as they provide a friendlier interface for consuming back-end data, likely spurring greater consumption of back-end resources.
"SAP is very interested in this area, letting you go from the SAP infrastructure out to a form and back again," Duhl said. "You don't have to use the SAP front end anymore; you can use a nice (user interface) you've built for your work flow."