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 dataword-processing files, spreadsheet files, e-mail messages, HTML pages and the likethat 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 XHTMLa hybrid of XML and HTMLprogrammers can quickly create pages that can be viewed on a variety of devices. Converting IBM.com, 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 sitequality 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 systemsbut 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 partnerand 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 logicnot the data itself.