XML Project Pitfalls

XML Project Pitfalls
The components listed in Section 2.1 deal with the technical side of an XML project; this section looks at pitfalls that come mainly from the human side, including unspoken expectations, unrealistic expectations, and resistance to change. A larger XML project in a government or corporate setting will often encounter threats from several groups of people and may face more risk from overenthusiastic supporters than from opponents.

2.2.1. Unspoken Expectations
XML still gets a lot of media attention. Sometimes, managers approve XML projects simply so that their customers and shareholders will see that they are using the latest technologies. Nothing is wrong, in principle, with using XML as a marketing technique; the problem is that this goal is almost always unspoken. Nobody tells the project team that it is participating in a marketing exercise, and even if the team realizes that fact, it is still forced to act as if it were implementing a real project. In fact, the situation is worse, because often the team is the designated scapegoat, starting with a set of fictitious written goals that it has little hope of reaching, thereby setting the team up to take the blame for the project's technical failure. To make things even worse, management will often announce an excessively large XML project for maximum publicity but then spend as little as possible on development once the headlines have quieted down, starving the project of money and resources.

The best way to work around this problem is for management to be honest about the project's goals and requirements, in writing. If market visibility is one of the project's main goals, write it down, along the lines of "the major goal of this project is to raise BigCorp's visibility in the market by showing our commitment to new technologies like XML." Two years later, new managers and new team members will be able to measure their progress more fairly, and it may turn out that the project was a marketing success even though it was a technological flop.

2.2.2. Unrealistic Expectations
Difficult or impossible requirements are not always the result of devious maneuvering, however; sometimes, they come about honestly and sincerely not only from management but also from the developers. Managers and developers attend conferences and listen to zealots promoting the latest XML specifications, then rush out and make support for those specifications into requirements before evaluating their value and the level of available support, as discussed in Section 1.6. If the specifications chosen are not widely supported, the project's developers will not be able to use off-the-shelf software and will end up doing a lot of custom development to support a specification that brings little or no value to the organization. In many cases, no one has yet proved that the specifications even can be supported in a production environment.

This problem is especially common when a specification has endorsements from large companies and organizations. Those endorsements can give the impression that the companies are planning to use the specification or even to produce off-the-shelf software to support it, but that's rarely the case: Large companies wait for proven demand before making major investments in technologies. The name IBM, Microsoft, or Oracle on an XML-related specification simply means that the company authorized one or more of its employees to serve on the standards committee, not that it is about to release shrink-wrapped software to support the specification.

Starting out with unrealistic expectations can quickly leave developers and managers frustrated. The so-called standards mean more work rather than less, and there are no extra rewards for following them. The expected software and tool support never appears, and customers or suppliers that were talking about exchanging information using the new specification never get around to doing it. In the end, all the XML has to be converted back to an older, legacy information format anyway, and the XML ends up as an expensive and unnecessary extra step in the information pipeline.

The best way to work around this problem is to plan for the present, not for the future. How well is a specification supported today? How many partners, customers, or suppliers want to exchange XML-based information today? How many products and components are available off the shelf today? If the answer to each of these questions is close to zero, postponing support for the specification is probably the wisest choice.

2.2.3. Resistance to Change
Incremental technical innovations often have mild and benign social effects. For example, the change from rotary to touch-tone dialing did not initially have a major impact on people's lives, although eventually it did allow for automated telephone systems; likewise, the change from roof antennas to cable television simply built on what people were already doingwatching TVbut expanded their choice.

Disruptive technical innovations, on the other hand, have immediate and unavoidable social effects, both positive and negative, with clear winners and losers. Consider, for example, the effect of peer-to-peer file sharing on the music industry (losers) or the effect of cellular phone technology on real estate agents (winners). As happened with the music industry and peer-to-peer file sharing, the people who fear that they might be losers will fight long and hard against the change, believing that they are better off with the status quo.

XML typically falls into the disruptive group, so XML projects can face serious resistance. Although big companieseven the ones with the most to lose from open file formatshave embraced XML, XML still poses the same kind of apparent threat to individual users that file sharing poses to the music industry. The best place to start is the separation of content and formatting, one of the central assumptions of XML.

It is common in the XML world to be dismissive about WYSIWYG word processors, such as OpenOffice Writer or Microsoft Word, but authors using such WYSIWYG systems have an enormous amount of control over their work. Although they may be required to use a specific template and to follow a standard style guide, they can still add formatting directly and see more or less what the published version of their work will look like. They can add page breaks, rearrange paragraphs, add tabs and indentation, and fiddle in many other ways until their text not only reads well but looks good. Taking away control over formatting and presentation wipes out much of what gives document authors pride in their work.

It is not simply a matter of control, however, but of prestige. To balance the authors' freedom in a writing team using word processors or desktop publishing software, there is often a set of complex rules, both written and unwritten, enforced by editors and senior writers. Many of these rules are related to formatting and software; mastering these rules, especially the unwritten ones, gives the senior people a position of power over the junior ones. Switching to XML immediately weakens or eliminates that power: XML-driven editing software can enforce many structural rules that used to have to be enforced by editors or peers, and formatting rules become mostly irrelevant. The new XML-based system may be just as complex, but the senior people no longer have an advantage: They have to learn it from scratch, just like the junior people do, and probably will not be able to learn it as quickly.

A third, related problem is simple overwork and frustration, even from people who are not otherwise opposed to the project. An XML-based system often requires people to learn a software product that may be buggy and incomplete. At the same time, unless the group using the XML project is brand new, such as a start-up or a recently created division of a company or organization, the users likely have to keep up with their regular work during the transition. Structured markup requires a new way of thinking, and a new way of thinking takes time to sink in; if, as is typical, users are not given any extra timeor even if they suspect that they won't bethey will be enormously hostile to any new system, XML or otherwise.

Even the people who will not be using the system directly will likely be skeptical, as they are with any big technical change; they'll be concerned aboutor jealous ofthe resources being devoted to the XML project and will be eager to jump on the first weakness that turns up.

So, to summarize, following are four major reasons that people will be secretly or openly hostile to a new XML project in any company or organization.

Authors do not want to give up control over the physical appearance of their work.

Senior people do not want to lose their advantage of experience with the current system over the coworkers.

Users do not want to devote the time to learn a new system, risking falling behind in their existing work.

All members of the company or organization may be skeptical that the project's benefits will justify the cost.

How can an XML project deal with these obstacles? The best place to start is an admission that, sometimes, the naysayers are right. An XML project may fail or underperform, especially if it involves desktop authoring tools. Employees may initially find their work less pleasant once they've lost some control over it. Senior people are at real danger of being left behind by any technological change. Employees will find that their managers expect them to learn and to adopt complicated new technologies without any temporary decrease in productivity. All together, like most other workplace innovations, a big change like XML can make for a bad situation and, eventually, a poisoned working environment.