Will XML be the ultimate platform? Or will it be the next EDI?
I hear it's going to cure cancer," says Tim Bray, its co-creator. "It's going to do my dishes, I hear," says Anne-Marie Keane, Staples' vice president of B2B e-commerce.
Reader ROI: Discover how companies are using XML to create business solutions today; Learn what CIOs must do to maintain the value and openness of XML.
Behind the flip jokes lies XML - a syntax that underpins a growing list of more than 300 nascent data standards. MathML, for instance, will make it possible to manipulate advanced mathematical equations on a Web page. Spacecraft Markup Language standardises databases that operate telemetry and mission control. And then there's MeatXML, a comical name for a serious effort to create a universal meat and poultry supply chain standard.
With XML going in so many directions at once, you can't blame CIOs for being confused. The hyperbole often makes XML sound like a salve for all pain. Even worse, the vendor hype is over-whelming. CommerceOne, for example, boasts that British Telecommunications will cut purchase order processing costs by 90 per cent using XML-based procurement. Software and service provider JetForm claims developers can write programs in days that would have taken months without XML.
Finding the truth behind the tales takes some digging. Technologically, XML is a giant leap for IT. It can drastically reduce development time while making data transfer over the Internet simple. If nurtured properly, it may even become the ASCII text of online business - ubiquitous and assumed. Or it could become the next EDI, fractured under the pressure of vendor self-interest. One thing is certain: for XML to reach its full potential, CIOs will have to take an active role in forcing their partners, their vendors and even their competitors toward a radically more open computing model than what exists today.
That's no small task. But some companies have been willing to take it on by implementing XML now rather than later. We found three such brave souls putting XML to work, each in one of the three areas most agree the technology will first permeate: Business-to-business data sharing, where Alistair Duncan of Visa International has built his own XML vocabulary for sharing corporate credit card information. Content management, where Gary Guilland of Safeco is using XML but is hardly ready to coronate it as the future of computing. Application-to-application integration, where Steve Morin of TAC Worldwide sees XML revolutionising the human resources industry - if 90 competing vendors can agree to cooperate.
Despite the qualifiers, all three remain confident in XML's prospects. "There's a lot of optimism," says Joe Dalman, senior vice president and COO of Minnesota-based Tie Commerce, and member of the XML registry repository working group, which is trying to set up a public network containing every XML schema. "But it's getting to the stage where people are saying: Give me more solid evidence. Put some substance behind this technology.' It's time to look at how we can adopt this stuff."
Visa: Learning to Share
XML-hyping vendors throw around terms such as frictionless data exchange when they talk about their products. But Alistair Duncan thinks differently. "Everyone is talking about XML. But when you come into our industry, many people are still on legacy systems that aren't going away - and you have to accept that."
For Duncan, senior vice president of commercial products at California-based Visa International, XML is as much about dealing with legacy systems as it is about supporting the latest technology. And there's a lesson in how he's approached XML: deliberately, in context and not at all like it would solve all his problems overnight.
Duncan was charged with building an application to itemise charges to Visa corporate cards. This would allow corporate customers to automate parts of expense reporting by electronically transmitting the itemised charges to the correct cost centres. It would also give Visa more detailed data on its corporate customers' spending.
He identified thousands of potential data elements - such as hotel charge, hotel tax, state tax and meal charge - that he wanted to capture. But rather than XML, Duncan looked first to EDI. It fitted the need technically, he says, since EDI development tools were mature and proven.
Soon, however, Duncan decided to take a chance. "We had gone quite far in putting these items into EDI format," he recalls. "But eventually we saw the market moving toward XML."
A year later XML is working with several hotels and car rental companies now able to inject itemised charges directly into Visa and Visa corporate card subscriber systems.
But Duncan says implementing XML wasn't easy.
"People are still talking over XML standards, so we had to make some definitions ourselves," Duncan says. "We developed a reasonably generic XML vocabulary called the Visa XML Invoice Specification, and we had to hope external companies would implement it."
Visa then spent time and money convincing reluctant merchants and customers to adopt Visa's XML. It worked, as more than 2000 companies have downloaded the specification.
Then Visa had to invest in training. The company had to work directly with merchants to make sure they properly integrated XML. However, some partners - such as the air-travel industry - aren't yet ready to use it, preferring instead to use their own existing standards. Visa simply can't fail to include airfares in its detailed charges, so Duncan had to build XML-to-whatever-legacy-system conversions. "You can't afford to be dogmatic and tell people they must use XML because it's so great," Duncan says. "We had to invest in conversions from their proprietary formats. And that costs money, and it slows things down."
Those conversions also make XML more complicated than the vendors claim - and it's only getting more complex. Already XML has spurred XSL, XSLT, XHTML, XLink and XPointer as adjunct standards. (These standards create such things as formats for hyperlinks and style sheets that define where and how XML objects appear.) The encroaching complexity has even spawned a backlash at sites such as XMLsuck.com and The XML Lobby (xmlbastard.com).
Duncan dislikes the trend toward complexity but accepts it as a reality of working in a legacy world. And he still thinks XML is better than any of the alternatives out there - but it's not as "frictionless" as some of its purveyors claim. "That could only be true if you're starting out totally new," he says. "But you know business. When does that happen?"
Safeco: Content to Manage
Business analyst Gary Guilland compressed a two-day process into 90 seconds. He used XML in conjunction with other tools to accomplish the task, but he's giving the technology little credit.
Guilland's business is surety bonds - his company guarantees transactions between other companies - for Safeco in Seattle. Traditional requests for surety bonds involved paper applications, signatures, photocopies, the post office and manual data entry - a process that took as long as two days to execute. The grocery application, Guilland called it: high volume, low margin; but you have to do it. The only way to make it better, he thought, was to automate this necessary evil, which meant managing huge volumes of content.
Guilland contracted software vendor JetForm in Ottawa, which had built its own XML vocabulary for forms called XFA (XML forms architecture). Together, they marked up the surety bond application with XFA and stored it as a database of XFA objects. They then built a Web site that guides applicants through the application. Each question represents an XFA object: name, address, bond type requested and so forth. Once complete, the application cobbles together the objects into the proper forms. Those forms then appear in the user's browser, ready for printing, while a copy goes to a back-end mainframe, where they're again translated for storage.
The translation tools took two weeks to write. Full implementation of the application, according to Guilland, took just about a year.
Guilland says the new application cuts the post office and the data re-entry out of the process, reducing execution time from days to minutes. And costs stayed low because XML development is relatively inexpensive, especially with a pre-existing vocabulary such as XFA.
Still, Guilland hasn't deified the technology. "All of our objects are XML based, but the application is king," Guilland says flatly. "It really was happenstance that XML was the technology back there. XML didn't make this happen as much as the [design of the surety bond] application did."
Heresy? Not really. Even Tim Bray, one of XML's fathers, says CIOs should do, to a large extent, what Guilland has done. Ignore XML.
"Assume it will be there," Bray says. "Most vendors are putting it in their software. Ignore them. XML is the easy part." Then, he says, use the time once spent building tedious one-to-one supply chain connections to instead develop reliable business processes. Guilland could be a poster child for this kind of XML temperance. He poured all his efforts into the surety bond application, the Web interface, the forms-building logic and the translation tools. At the same time, he says he probably couldn't even define XML accurately.
Whether he could define it or not, Guilland isn't done with XML. In addition to using it for other parts of the surety bond process, Guilland wants to get other companies in the insurance market to integrate XML standards, which is a diplomatic - not technical - task. "In the long run, the real value is working with our partners, getting them to convert systems according to the standard," he says, referring to the insurance industry's effort to standardise an XML vocabulary, called The ACORD (Association for Cooperative Operations Research and Development) XML standard.
Guilland also spends time rebuffing what he considers extraneous XML development. When pressed on the possibility of using XML-enabled analytic tools to mine his data, Guilland baulks. "It's always nirvana when vendors pitch this stuff, but you know it's never nirvana getting there.
"We're aware of XML," Guilland adds. "We're not driven by it."
TAC Worldwide: How to Be a Player
In the absence of XML, as Steve Morin now refers to the recent past, TAC Worldwide built one-to-one connections with its partners. Custom FTP links, custom code and "sometimes a lot of grunt brute force" helped the $US1 billion professional staffing company find and assign temporary or contract talent to its subscribers.
Now in the presence of XML, Morin, CIO of Massachusetts-based TAC, thinks he can cut recruiting time by one-third and slash his development chores in half - at least.
Morin is leaning on XML to automate huge parts of the recruiting transaction by creating a common language. His database will use this XML vocabulary, as will his clients' request forms, partners' procurement applications, job posting boards like Monster.com and even résumés.
Then, when a client asks for a Java programmer with five years experience, Morin's databases will know precisely what that request means, automatically search for the best matches and eventually send a list of prospects to the client along with contracts ready for signing. With just a few months of development, Morin says the HR industry could have a network of integrated applications more powerful than any EDI network, and completely open. He believes XML can make the Internet seem like a mildly interesting prologue to a real B2B revolution.
Of course, there's a but. For all of that to happen, everyone in the human resources industry must agree on a standard XML vocabulary.
To that end, HR industry companies formed the HR-XML Consortium. Eventually - 2002 at the earliest - HR-XML will include elements for about 20 standard HR functions, such as staffing exchange, payroll transactions, compensation and even back-ground checking. Morin is a charter member of the group. His bosses saw the consortium as great market-ing, demonstrating TAC as an industry leader. Morin, meanwhile, joined to exert influence on the standard. He just didn't know that it would become a full-time job.
For Morin, XML started as a technical boon but has turned into a full-out diplomatic grind. The challenge is getting some 90 companies to settle on the thousands of elements that will compose HR-XML. That's quite a chore, especially when you consider that e-business heavyweights such as Ariba and CommerceOne chose not to agree on XML tags as simple as a product's SKU number.
"It can get pretty political," Morin notes. "Frankly, there's a lot of dialogue now we don't even get involved in. So we let it go back and forth and wait for the vote, evaluate the proposals, and then we'll get involved." Many industries are experiencing that same political process. XML.org lists 16 projects in the financial sector alone, some complementary, some competing. And XML's elegant openness isn't always virtuous enough to make vendors cooperate. Take Visa, flush from Visa XML Invoice Specification's success. A spokeswoman said the company wouldn't cede its internally developed vocabulary for a vendor-neutral industry standard. As a result, hotels might one day be burdened with an XML standard for every credit card company and the translation tools to go between them. To compensate, opportunists are already creating tools that translate one XML vocabulary into another.
Visa's Duncan calls the translation process nearly trivial. But while that's nice for developers, TAC's Morin says it creates a management nightmare.
If vendors don't agree on vocabularies, Morin says he'll find himself spending his time downloading the latest vocabulary and all the subsequently required translation tools. "That's still creating pain," he says.
"There needs to be some consolidation of vocabularies," adds Charles Dietz, an XML specialist at Metropolitan Life Insurance Company in New Jersey. Ironically, he blames the proliferation of dialects on XML's ease of use. "XML is frankly so simple it's easy to create a vocabulary. That's good but also bad." HR-XML has tried to rein in all development under its one umbrella, but nothing would stop Morin or any other member from also creating his own vocabulary. Despite a cut-throat reputation, Morin says everyone in the HR industry seems to be cooperating. But he admits it's a leap of faith, and a hard one to make.
HR-XML faces another big hurdle too: software makers have to agree to build support for one standard and refrain from adding proprietary extensions - a level of cooperation that didn't materialise with EDI 30 years ago.
"We're asking people to practise truly open computing," Bray notes. If it happens, he says, "It would be an unmitigated win for CIOs. For vendors, the benefit is not so clear."
That's why Morin says XML's success has nothing to do with how well he knows the specs, but rather its success rests with CIOs taking charge and prodding vendors into openness.
"Oh yeah, we push them," Morin says. "We work with both Microsoft and Oracle, and we give them both very strong views of how they need to [stay open]. They need to realise that neither of them will win the entire battle. The best thing they can do is make sure when standards come out that they plug and play."
For their part, Microsoft and Oracle have both told Morin they would support HR-XML and not extend it. "They are saying all the right things right now," he says, but he admits to still having long-term concerns.
In the meantime, Morin is carrying out his pilot program - a simple application integration between TAC and an external partner, using XML to automate transactions. He's testing Microsoft's BizTalk server and Microsoft and Oracle databases, both using parts of the embryonic HR-XML vocabulary.
"There's the potential for XML to be for e-business transactions what HTML was to Web publishing," Morin says. "There's also the potential for it to be the next EDI. There's a lot of potential energy."
XML Assumptions vs Realities
ASSUMPTION: XML is a panacea.
REALITY: It's a significant step beyond things like CORBA and EDI, but it's immature, still evolving and will not be everything to everyone.
ASSUMPTION: With my applications XML-enabled and my partner's applications XML-enabled, we should be able to communicate easily.
REALITY: Possibly. But first you all have to agree on a specification. And even when industry standards would make more sense, many vendors are building their own XML specs and asking users to comply with that.
ASSUMPTION: Since XML applications communicate easily, I should start XML-enabling all my applications.
REALITY: Don't get ahead of yourself. Enabling key XML applications alone will take a significant capital investment and myriad strategic decisions.
ASSUMPTION: Don't get ahead of yourself. Enabling key XML applications alone will take a significant capital investment and myriad strategic decisions.
REALITY: Not all XML-based specifications work together, just as not all words made from an alphabet are part of the same language. Consensus is key.
ASSUMPTION: XML is a language.
REALITY: XML is actually a syntax, like English grammatical rules. You can't write actual code in XML, something you can do with a language.
Bike XML's Wheels Come Off
Creating an XML standard can be a long, uphill ride.
Leslie Bohm tried to harness XML's potential. He immediately recognised how applications using XML might advance the B2B supply chain in the bike business, where he's a highly regarded consultant.
Bohm says he sunk hundreds of thousands of his own dollars into recruiting the five major cycling manufacturers and hundreds of retailers for a supply chain that would use its own standard XML vocabulary, BikeXML, as its underpinning. BikeXML.org was launched, along with Bikecommerce.com, its B2B exchange Web site. Bohm envisioned unprecedented efficiencies in the tyre-and-pedal business, saving everyone astonishing chunks of money in order processing and shrinking turnaround time while ensuring smooth inventory levels.
Both Web sites went into hibernation in February. "They didn't get it," Bohm laments. "They could see how it simplified the supply chain, but we had a hard time with the politics. And as soon as it gets to talk of opening their platforms, they flinch. These IT departments can be empire builders. It's a real phenomenon; the executives understood it, but when the IT department had to compromise on the standard and the Web site, it fell apart."
Bohm thinks another BikeXML is two years from reality now - more if the economy continues to sink.
He is not short on advice for CIOs, either. "I would just say this: it's not about the technology. It's about the psychology. The technology's not simple, but the psychology of XML dwarfs the technology.
"You bet I'm disappointed. I feel like we missed it, the chance to really leap forward."