Technology: XML Revisited

By CIOinsight  |  Posted 02-22-2002

Technology: XML Revisited

In a perfect world, every computer, application, system and network would communicate with one another, easily exchanging data files, automatically translating foreign data and effortlessly performing complex transactions. Companies could use technology to support new projects aimed at boosting profits, find the right business partners faster, and create new, more information-rich relationships with customers and suppliers.

But such hopes remain a fantasy, just one of the many promises of the Net the business community is still waiting for. The fact is that companies still have networks and systems that can't talk to each other, thanks to a general lack of standards over which languages they should use. Technologies based on Internet Protocol, experts hoped, would allow companies to create universal applications for a wide variety of business transactions, communications and processes—everything from internal communications and intercompany document exchange to supply chain management. Unfortunately, while HTML is fine for building Web pages, just try using it to tell a computer to give certain Web browser users access to your centralized accounting program, and you'll hit a brick wall. Want to link large-scale e-business systems that require new connections for sharing data between a variety of mainframes, servers and operating systems running in separate companies? Dream on. Need to support a new marketing sequence with people from departments who have never worked together before? Forget about it. And if you're looking to develop applications that can run on any system that speaks IP, you'll find that, sadly, the widely hyped "write once, run anywhere" promise of various applications tools—most notably Sun Microsystems Inc.'s Java—has so far proved to be elusive.

Language Arts

Language Arts

Enter XML, the acronym for Extensible Markup Language. Proposed in early 1998 by the World Wide Web Consortium (W3C), XML, it was hoped, would function as a kind of Esperanto that would allow information to cross software borders, overcoming communications barriers between workgroups and organizations. Rather than simply supporting the exchange of data, XML is designed to provide the "context" for how that data can be used. "Humans understand language from context," says Rita Knox, vice president and research director at Gartner Inc. "For computers, understanding context is an enormously difficult problem." In the past, trading data in context has required special adapters that take the information from one system and recast it in the expected format and messaging context of another. XML simplifies the exchange, Knox says.

Sounds good, right? But XML is still a young technology, and like anything new, it comes with significant risks. The decision to use it depends on the business problem you're trying to solve, fix or update, the cost of doing so, and a careful analysis of the cultural and management risks surrounding its use.

How does XML work? At its simplest, XML allows users to define a set of labels for their data, a sort of standardized language to identify every piece of data in a file. That's not a big step for information already structured in a database, but it's a huge leap for the mass of unstructured data—word-processing files, spreadsheet files, e-mail messages, HTML pages and the like—that comprises the vast majority of data. But XML doesn't stop there: It also allows users to determine the ways that information should be displayed on a screen. And it can also let users define the kinds of steps that should be followed to process the data.

Suppose you wanted to regularly exchange your address book with a colleague in another department who uses a completely different personal information management application. You could output to a text file using tabs or commas to the various data fields. But manually outputting the file, and having your colleague manually input it, is laborious, especially if you want to update one another daily. But outputting to a native XML file on a Web server would mean that each of your XML-compatible applications could easily send and read the data as often as you'd like, with whomever you'd like.

Or take a company attempting to allow its customers to look at information on their handhelds and mobile phones, as well as their PCs. Traditional HTML pages can't easily be reformatted to smaller screens. But using XHTML—a hybrid of XML and HTML—programmers can quickly create pages that can be viewed on a variety of devices. Converting, IBM Corp.'s 4 million-page Web site, from HTML to XHTML wasn't difficult for programmers, says David Leip, the site's Webmaster. XHTML let IBM gain a more consistent user experience on its Web site, and now it can quickly recast its pages for, say, a mobile phone. Leip says the task of conversion to XHTML will pay off as his Web site serves more users, without significantly adding to the expense of the site. "XHTML makes governance of the site—quality assurance —easier," says Leip, who blended the conversion into a site makeover last March, fitting it into his budgeted cost. The net effect was to make the site more consistent and predictable to users, "and the value of that really catches up with you," he says.

Now suppose you want to conduct transactions with a trading partner who uses a completely different financial information system. You could install an expensive software "adapter" that would translate information directly between your two systems—but you'd have to do the same thing the next time you wanted to trade information with a new partner. But by outputting your purchase information to an XML-formatted document, it can be read by your trading partner—and by thousands of other companies in your industry as well.

All that's useful, but it doesn't tell people what to do with the data. Suppose you wanted to make an agreement between you and your trading partners about the exact steps you would all follow to process a purchase order. You could each build a custom program that knew how to read the data file you had created, defining in the software the sequence of activities for processing the order. But if you wanted to go from, say, a 10-step process to a five-step process, you'd each have to rewrite your custom applications. With XML, you can define the order-processing steps in separate business logic, so the next time the steps change, you'll only have to change the business logic—not the data itself.

Standard Procedure

Standard Procedure

But XML's flexibility has some downsides. Such a "Swiss army knife" technology can lead organizations into vain efforts to do too much too fast, thinking they can solve all their compatibility problems with a single initiative. "XML will not solve all your problems. It just provides a foundation for interactions between systems," says Jackson He, senior e-business architect for Intel Corp.'s eBusiness Solutions Lab.

Worse, organizations wanting to conduct routine XML transactions with industry trading partners either have to make up the definitions for such interactions on a partner-by-partner basis, or use one of the nascent industry-based XML specifications. Among the most advanced: the electronics industry's RosettaNet specifications; the Financial Information Exchange Markup Language, or FIXML, for the financial services industry; and those from ACORD—the Association for Cooperative Operations Research and Development—for the insurance industry.

According to RosettaNet, all its more than 100 board member companies have implemented XML exchanges with at least one supply chain partner, and most have implemented several. The largest companies, such as IBM, Intel, Compaq Computer Corp., Cisco Systems Inc. and Sony Corp., have automated many of their large supply chain relationships. Intel, IBM and a few others have gone a step further and automated exchanges with medium-size companies. By the end of 2001, Intel had 50 supply chain relationships in place out of a possible 1,000. But few RosettaNet members have started using XML with small companies with $25 million a year or less in revenues—primarily because adoption is not cheap, and many smaller firms simply can't afford to be early adopters.

To compensate for such problems, RosettaNet leaders are developing the standards, both internal and external, to help the little guys catch up. "We're taking steps to drive these standards ever deeper into the high-technology supply chain," says Mary Schoonmaker, vice president of marketing and strategic development for RosettaNet. With each extension to more kinds of companies, she adds, the cost of implementing automated data exchange goes down as organizations reuse the same XML components over the Internet.

Despite the increased use of such enterprise-wise standards in certain industries, many supply chain partners will need to be carried kicking and screaming into an XML world. Adoption of XML standards has already followed the pattern of EDI 20 years ago: The "800-pound gorilla" organizations at the centers of industry-specific supply chains—Citigroup Inc.'s Travelers and The Hartford Financial Services Group in insurance, Intel and IBM in electronics, and United Airlines Inc. and American Airlines Inc. in air travel, for example—must jump on the bandwagon to kick-start adoption. Intel was one of the first to implement RosettaNet specs in the electronics parts industry. Terry Spires, manager of Intel's Industry Solutions Group for automating partnership relations, said that by taking that first step, his company gave its many partners in the electronics industry the confidence that XML would be standardized. Adopting XML is still expensive, he says, and many companies want to see a dominant figure move before they commit their own resources.

In financial services, the picture is murkier. Plenty of financial service providers have implemented XML. But too many companies are trying to be the first to gain a competitive advantage with XML-based systems, and then force their own standards on their partners. The result: confusion, acrimony and duplication of effort, says Ron Schmelzer, founder and senior analyst with XML market researcher ZapThink LLC. In some cases, notes Gartner analyst Mary Knox, the service provider is still using an internal XML system that doesn't jibe with the industry standard it has adopted externally. And it's critical for companies in financial services to solve those problems. "The consequences of not getting there by 2003 means you, as a financial service provider, will have slower response times to customers, you'll be slower to market with new products, and you'll have less ability to work with new partners," Knox says.

Even if the switch to XML generates consensus on specifications inside the industry, that still leaves the task of getting industries to talk to one another. Newport News Shipbuilding, for example, will integrate its data internally and with suppliers by upgrading its enterprise resource planning system. But there's no XML standard for shipbuilders, so the company will have no way to communicate with banks and insurers, notes Kenny Roberts, manager of Newport News Shipbuilding's information technology business unit, Naptheon. XML-based communication with suppliers would lead to "greater reliability of parts and equipment delivered to the shipyard and better tracking of resources in building a ship," says Roberts. But converting just part of the process would mean falling back on paper processes to deal with other parties. The result: "No speed up, no effect on the delivery date," he notes.

Decisions, Decisions

Decisions, Decisions

Should you make XML part of your organization's strategic architecture? If you have disparate systems that need to communicate with each other more efficiently, it's probably time to decide whether XML can solve your problems. If you want to start trading with an organization from within your industry but you've been stymied by the technical incompatibilities between the systems, you should also be checking out XML.

But don't underestimate the cultural hurdles that have nothing to do with technology. As with the RosettaNet experience, there are still going to be some divisions and some business units that don't want to share their data with others, and that's where aggressive management from the CIO and other executives will have to come in to ease the way.

Don't wait too long to test the waters. According to Gartner, 75 percent of the Fortune 500 used XML in at least one pilot project in 2000, and the firm expects that by the end of 2001, 75 percent will have used XML in at least one application integration project in production. And that's not all: According to International Data Corp., the market for XML servers and XML databases, which was about $390 million in 2001, is expected to grow to $3.7 billion—almost tenfold—by 2005.

While this market activity is encouraging, it shows that many companies aren't rushing into widespread XML deployments. Still, over time, an increasing number of businesses will adopt XML where they can gain cost efficiencies and create new business initiatives without having to make major modifications to their existing applications. Despite the numerous challenges that adopting organizations will face—in part created by the rapidly growing popularity of the protocol itself—XML's flexibility will ensure that this new lingua franca will become an integral part of many organizations' strategic architectures.

Charles Babcock, a technology writer based in San Francisco, formerly served as technology editor of Interactive Week, as an analyst with Mainspring Communications and as technical editor of Computerworld. Comments on this story can be sent to

Strategy Map

: At Your Service">

Strategy Map: At Your Service

One way to determine the value of a new technology such as XML is by drawing a map setting forth your specific strategic goals, and then working backward to determine what it will take to achieve those goals. Can the new technology be aligned closely to your strategy without completely disrupting your current business operations and breaking the bank? The example below posits an imaginary product-distribution company that's looking to increase revenue and decrease the cost of sales by upping its customer repurchase rate—the percentage of customers who buy again within a quarter. Working down through the chart, achieving that top-line goal is possible only by reducing order-processing time from 10 hours to 3 hours and providing real-time order information to internal groups. Then it's up to IT to decide whether XML can help achieve that goal efficiently and economically.

XML: Strategy Map Chart

Insuring Speed to Market

Insuring Speed to Market

Before issuing life insurance policies, insurance companies typically turn to underwriters to run time-consuming background checks on prospective clients. The underwriter checks medical, government and credit sources, and enters the results in its calculation of risk. But that involves reviewing reams of paper documents as they became available, a process that can take weeks or months. By that time, anxious clients may pull out.

"The number of policies not taken goes up as the length of time to close the deal expands," says Scott Neumann, e-Nable's chief technology officer. "It gets very high when numbers go into 60 or 90 days." According to the American Council of Life Insurers, more than 8 percent of all life insurance applications were not taken by the customer in 2000—a lot of money considering that insurers collected a total of $35 billion in premium revenues from newly issued policies that year.

One of the databases underwriters invariably check with is MIB Group Inc., a consortium of 600 U.S. and Canadian insurance companies founded in 1902. Based in Westwood, Mass., MIB's database contains the records of 120 million people—the individual life, health, disability and long-term medical care information previously reported to MIB's members over the past five years. Ninety-five percent of the life insurance policies in North America are issued only after insurers check with MIB.

In 1999, MIB founded e-Nable Corp. in hopes of using XML to allow underwriters to process life insurance checks more rapidly. The goal: to save some of that lost business and reduce the chance that clients might misrepresent their medical conditions. Using the insurance industry's XML standards set by ACORD, the Association for Cooperative Operations Research and Development, e-Nable's service rapidly preprocesses—and in some cases approves—life and medical insurance applications before they're actually submitted to underwriters for full analysis. About 13 percent of the dollar volume of life insurance is submitted to be checked by e-Nable's system against the MIB database, according to e-Nable, and up to 40 percent of a company's applications can be approved immediately.

But while the XML system provides application processing efficiencies, says Neumann, the real savings come in speed. E-Nable's own study suggests that insurers can save between 20 percent and 45 percent of the cost of processing an application. "We have been doing everything by hand, preparing and underwriting applications," says Jeanie Herod, director of marketing for Guaranteed Quotes, an Edmond, Okla.-based life insurance preliminary underwriter and an e-Nable customer. "Requirements that would normally take us six to eight weeks can get done in two weeks through e-Nable."

How soon will it take to expend the virtues of e-Nable's services to the rest of the industry? "Most of the industry is still paper-based," says Neumann. "We are just starting to see companies move into significant implementation of XML. Life insurance companies are not the quickest technology adopters."

XML Fact Sheet

XML Fact Sheet

XML Factsheet Thumb
Click image to download printable version of fact sheet.

By giving companies the ability to share data both internally and externally, XML can provide a significant boost to strategies based on reengineering internal and external business processes, rationalizing supply chains and connecting more seamlessly with customers. But Byzantine standards have been a drag on adoption, so jump in with your eyes wide open.

XML Lets Companies...

  • Share documents between workgroups
  • Generate standardized invoices and other forms inexpensively
  • Access databases with different formats
  • Build flexible Web sites accessible through a variety of media
  • Define and automate shared business processes


  • Cost reduction: Moving from paper-based to automated processes can reduce labor costs.
  • Speed: Implementing XML can speed up the execution of business processes.
  • Standardization: In industries where standards are solidified, trading partners can initiate new relationships with minimal resources.


  • Lack of standardization: Many industries haven't yet agreed on standards.
  • Lack of interindustry support: Few industries have standards for interacting with other industries—and won't for some time.
  • Too much flexibility: XML is so flexible that users are tempted to try solving too many problems at once.


  • RosettaNet: A consortium of more than 400 companies building standards for the electronics industry.
  • FIXML: Extends the Financial Information eXchange (FIX) protocol for securities transactions.
  • ACORD: Standards for the insurance industry.
  • COVISINT: Auto industry consortium setting supply chain XML and e-commerce standards.

Major Players

  • Microsoft Corp's. BizTalk Server: Currently, the leading XML vendor.
  • Software AG's Tamino XML Server: The leading native XML database system. Has been an early implementor of W3C's XQuery.
  • Ipedo Inc.'s Ipedo XML DB 2.0: A native XML database system that has won recognition for its data integration capabilities.
  • Ixiasoft's TEXTML Server: A native XML database emphasizing flexible, dynamic information storage and retrieval of XML documents.
  • X-Hive Corp.'s X-Hive/DB: A database that supports multiple versions of XML documents.
  • dbXML: A native XML database for use by open source developers produced by the dbXML Project.

The World Wide Web Consortium's central XML site
A site for XML standards coordination, sponsored by OASIS
Organization for the Advancement of Structured Information Standards, a sponsor of ebXML
An O'Reilly & Assoc. Inc. XML portal
A reference list of XML standards and activities
Insurance industry standards
Electronics industry XML standards
Open Applications Group, the sponsor of 122 XML standards