XML: A Managers Guide (2nd Edition) (Addison-Wesley Information Technology Series)

The process and people changes just recommended help minimize the entire set of adjustment issues associated with adopting XML. They are analogous to a general program of diet and exercise to promote physical health. In cases where an individual is at particular risk for heart disease or cancer, doctors usually prescribe specific preventive actions. With XML projects, we have enough experience to identify some of these specific risks and the appropriate precautions .

The author has encountered five common problems: development team cohesion, open source management, version skew, business and development focus, and cooperation with other parties. Most of these problems are not unique to XML, but because of either a characteristic of the technology or a simple coincidence in timing, XML can magnify the risk. Understanding the dynamic behind the prevalence of the issue will help you identify it on your own projects and devise countermeasures suited to your specific situation.

The rest of this chapter examines each of these problems in detail. First, we define the problem and explore how XML magnifies it. Then we assess the conditions that make it more likely and more severe. Finally, we discuss prevention strategies. None of these strategies is perfect, and all require some type of tradeoff . On balance, however, they should help mitigate these problems in most cases and reduce the chances of project dysfunction. Table 6-2 summarizes this information.

Development Team Cohesion

Successfully deploying applications with any new software technology requires a core set of skilled developers with a thorough understanding of its mechanics. XML makes this requirement particularly crucial. The number of developers with previous structured document experiences is rather small. Moreover, the technology continues to evolve rapidly , forming a substantial barrier to entry for new developers. So finding and retaining your set of core XML developers is a challenge.

Table 6-2. Overview of XML Specific Risks

Two factors magnify this challenge. First, because XML has not fully matured relative to other technologies, developer experience is specific to both the types of applications built in the past and the particular tools used. A developer experienced with Content Document applications may not have the skills necessary to build Business Document applications. Someone with previous XML experience using J2EE platforms may take a substantial amount of time to become effective on a project using Microsoft .NET, even though he may also have C++ and Visual Basic experience on non-XML projects.

The fact that XML development teams tend to evolve an unusual amount of shared experience and lore further complicates personnel planning. Much of XML development revolves around establishing and interpreting a shared vocabulary. When an application involves external parties, this vocabulary includes a model of how these other parties operate . An XML development team functions effectively when each member leverages this common mental model to use the same programming idioms. A new developer cannot contribute to the project until he internalizes this model.

These factors boil down to three personnel- related risks: building the team, avoiding turnover, and catching up. The general shortage of experienced XML programmers and the specificity of this experience mean that finding developers who can jump right in can take more time than originally estimated. Developer scarcity and the need for common idiom mean that turnover can really hurt a project because there just may not be the time to find a replacement and train him to be a productive team member. In The Mythical Man Month , Frederick P. Brooks found that increasing development team size does not decrease development time by the same amount. If an XML project falls behind, this general problem combined with the XML-specific need for a shared mental model renders the addition of new developers a completely ineffective solution.

You can minimize these problems with several process- and staffing-oriented measures. On the process side, you must use pessimistic assumptions in scheduling. Assume the low end of productivity, the high end of feature creep, and the high end of turnover. You should also assign one of the senior architects or developers to maintain a dictionary of the team idioms. This dictionary won't eliminate the problem of bringing new developers up to speed, but it will reduce the amount of time required to do it. Finally, for those subsystems where dependencies make them critical to delivering on schedule, make sure that your top developers cross-review each other's work on those systems so they can step in if necessary.

On the staffing side, you want to make sure that you get developers with the right kind of experience and that you keep key capabilities within your control. Achieving the first aim means deciding on the development platform and environment at the beginning of the project and then selecting developers with appropriate experience. Achieving the second aim means resisting the temptation to use vendor professional services or outside system integrator resources for core development. Instead, use them as a cadre to train and mentor your senior developers. Otherwise, the ability to enhance and maintain the XML features of your application leaves when they leave.

Open Source Management

XML is the first major software development technology to come of age after the mainstream emergence of the open source movement. This movement stems from the Internet culture of individuals cooperating to provide software that benefits everyone without the expectation of commercial gain. By the time XML gained momentum, this movement had expanded to the point where major corporations contributed their code to open source bodies. As a result, XML software components from XML processors, to development utilities, to Web services protocol stacks are available through open source bodies.

This coincidence of timing affects development organizations in the commercial realm. In many cases, the best or even only component of a certain type is available through open source; there is no commercial alternative. Consider the case of Xerces, the open source Java XML processor. The contributions of IBM and Sun on top of those from smaller companies and skilled individuals have made it the only real choice for a full-featured Java XML processor. But unlike commercial software, open source software has fuzzy feature roadmaps, uncertain delivery schedules, no support, and thorny licensing issues.

Enterprise developers face this problem most often because they must build business-critical systems that rely on crucial, yet unsupported, functionality. Vendor developers may feel the most serious effects because the improper use of open source software can hamper their legal right to sell a product. For both types of developers, discovering only partial support for standards and cumbersome implementation idiosyncrasies can lead to frustration. They don't have the leverage to demand enhancements or even extract a commitment for enhancements by a certain time.

In the absence of support for open source components from commercial vendors of related software, such as development tools and application servers, the only viable approach is to appoint an internal open source guru. This person administrates an internal repository of all the sanctioned versions of open source components. He serves as the point person for customizing these versions with necessary bug fixes and enhancement, including creating regression tests to ensure that future versions include the changes. Furthermore, he cultivates relationships with open source developers by participating in associated mailing lists and newsgroups. When the organization needs information or action from an open source body, he leverages these relationships to reach a solution. Finally, he serves as a liaison with the legal department to vet the open source licensing agreements and negotiate any additional rights from the open source body.

To fulfill the role of open source guru effectively, a developer must first have expertise in XML and the particular programming language of the component. He must also have intimate familiarity with the project's code base so that he understands the dependencies on open source components and can evaluate potential impacts. Strong interpersonal skills and a tolerance for frustration are important for fostering productive relationships with open source developers. Unfortunately, these requirements pretty much mean assigning the lead role to a senior developer because junior ones won't have the necessary breadth. Combined with the difficulty of finding and retaining qualified developers just discussed, the need to assign a valuable resource to a support role imposes a significant indirect cost on the use of open source software.

Version Skew

XML has two great advantages: It addresses an extremely wide range of problems, and its inherent openness has nurtured an extremely wide range of components. Unfortunately, these advantages have a downside. Together, they make for an extremely large set of potential software combinations. Even with XML's focus on compatibility, the sheer number of possibilities increases the chance of conflicts.

Consider what a modest project would use in the way of standards and components: XML, Namespaces, Schema, XPath, XSLT, SOAP, WSDL, XML processor, XSLT processor, SOAP library, persistence solution, application server, Web server, schema compiler, data-oriented XSLT tool, HTML-oriented XSLT tool, and schema design tool. Each of these artifacts evolves on its own schedule. At any point in time, a version of one may be incompatible with a version of another.

The costs of version skew can be surprising. Obviously, the risk goes up with the number of artifacts involved. But it's very difficult to pare down the list beyond a certain number without sacrificing a large fraction of XML's benefits. For large projects where both the number of artifacts and the impact of the application are high, the potential damage from version skew can quickly accumulate. Furthermore, many components support only subsets of certain standards. When several components have overlapping subsets of partial support, defining the common subset presents a challenge, especially if the component providers do not offer accurate support information. These dependencies make it difficult to upgrade components individually, so enhancement costs can quickly grow.

There is no easy solution to this problem. A practical approach is to use a spreadsheet to build a version matrix. Make a list of each standard and component you plan to use, and then create a matrix by putting this list on both axes. Now each artifact intersects every other artifact in two places. You need to evaluate both intersections because dependencies are often directional. One component may be able to accept data from another but not the other way around. At each intersection, note the extent of compatibility. A vendor may merely assert compatibility with another component, or maybe it has tested compatibility internally. (Hopefully, it fully certifies compatibility.) Don't forget to assess the compatibility of standards with other standards. Using certain features of XML Schema 1.0 may make it difficult to use XPath 1.0 and XSLT 1.1.

Based on the planned architecture of the application, you should be able to create an initial matrix. As the project proceeds, you can more easily evaluate the impact of adding a new component or using a different version of an existing one. It is much easier when you know from the start that you have to upgrade two components simultaneously rather than finding out only after upgrading one. Moreover, during application maintenance, the matrix enables you to estimate the cost of particular enhancements better by determining how many components you would have to upgrade.

Business and Development Focus

With any new software technology, both businesspeople and developers become excited about it and want to try it out. With XML, this tendency can quickly grow out of control and knock projects off track. We previously discussed XML's breadth and the wide availability of open source XML components. These two characteristics may give the impression that XML is the solution to any problem and downloading a wealth of components to prove it is just a matter of a few mouse clicks.

Most good developers are naturally curious and looking to expand their problem-solving capabilities. XML's potential tempts them to use it without first evaluating the impact, and usually they underestimate the consequences. Often businesspeople fuel developers' fire because they want to promote the XML features of the software but don't understand the complexities inherent in deploying new technology. They usually overestimate the appeal of XML to the target users, who really just want a good solution in a short time. The loss of focus from undisciplined use of XML not only throws the project off schedule but can also severely damage team morale .

Software vendors are most susceptible to this problem. They usually lead the way in the use of new technologies so that it's often hard to distinguish between the necessity to innovate and the spurious use of XML. Also, the pressure to distinguish the product in the market can lead to poor decisions regarding the value of an XML-related feature. Enterprises building B2B applications with XML commonly experience this problem as well. The underlying problem is the difficulty of setting boundaries among business processes. Once an enterprise starts looking at one business process, that naturally leads them to another business process, and so on. Instead of trying to deploy an initial version with limited functionality, the team attempts to solve an enormous business problem and usually fails.

Preventing the use of XML from spiraling out of control while still maintaining enthusiasm for its use is a delicate balancing act. One useful approach is to make a business case for every new use of XML and countervailing risk assessment. Whoever proposes the feature must justify the benefit either from the perspective of life cycle cost or user satisfaction. The senior members of the team assess the impact on schedule and potential risks. It also helps to assign a devil 's advocate to argue against XML. Spurious uses of XML quickly become evident when the justification is weak and the risks are high. But powerful ones also become evident when the justification is strong and the risks are low. In between, where there are both benefit and risk, you must work with the senior team members to make a decision that has buy in, perhaps not killing a feature outright but deferring it to a subsequent version.

Another approach that keeps developers focused on the application goals is maintaining a "benefit-feature-design" table to track the justification behind every use of XML. A benefit column lists the direct benefit to the user, and a feature column lists the functionality that delivers the benefit. A design column describes the software approach that enables the feature. For example, "rapidly update business processes" is a benefit, "dynamic business process execution" is the corresponding feature, and "XML business process description" is the XML design. By making sure that every benefit is substantial and there isn't a better design choice than XML, this tool creates the disciplined environment necessary for success.

Cooperation with Other Parties

Because most XML applications concern information exchange, development organizations often have to work with internal or external parties to deliver an application cooperatively. For B2B applications, you must cooperate with external parties. For EAI applications, you must cooperate with internal parties. You must agree on common XML formats, common interpretations of the problem space, and a common schedule for delivery.

Reaching these agreements can present difficulties, especially when the parties have somewhat different goals and high visibility puts the pressure on everyone to deliver. There is usually little problem when the parties have an unequal power relationship. A very large customer can usually persuade much smaller suppliers to follow its lead. However, when the parties are of equal size and stature, egotism, combined with differing agendas, can stall a project. In some cases, the failure to achieve cooperation can lead to project cancellation that results in a damaged business relationship.

To avoid this outcome, you should use a process that maximizes the incentive for cooperation. The basic approach is to break the project into relatively small stages that you can use to build trust and share in the validation that each stage brings . Having a goal of "total integration of our mutual business processes" for a B2B application sets the stage for failure. Instead, define a series of steps like "exchange purchase orders," "automated processing of purchase order to generate shipment notification," and "complete the circuit of purchase order, shipment notification, receipt acknowledgment, and invoice." This approach leaves less room for pursuing diverging goals, provides learning feedback from previous stages, and builds unity through success.

Establishing metrics constitutes an important part of the staged cooperation approach. At each stage, the team should be able to point to concrete achievements and areas for improvement in the next stage. In the early stages, these metrics will be necessarily technical. For example, after the first step in the preceding hypothetical stages, the metric might be "95% of purchase order messages were accurately processed ." That would be a pretty good result and could feed into the next stage with a goal of 99%. As the project progresses, metrics naturally become more business oriented. After the last step in the hypothetical stages, the metric might be "$107M in transactions were exchanged last quarter." Team members become more committed to the project with such visible signs of success, as do management sponsors.