Columns

Perspective on XML: Be humble, not imperial

• By Uche Ogbuji
• December 1, 2004

Information systems have earned an unfortunate reputation as a retardant of business innovation. Structured programming and modern database design methodologies have established a mandate to closely control business analysis.

In many ways, the entire discipline of software development has evolved through insistence on nailing business factors into a tight box, which conflicts with contemporary management ideology.

It's hardly a stretch to connect this disparity to the well-documented decline of the IT function among business hierarchies. The function of IT, especially internal software development, has been demoted over the past decade from the expectation that it is the savior of companies and yardstick of competitiveness, to an almost contemptible cost center whose main charge is to stay out of the way of progress and contain damage from the expectation of systems failures.

The root of this decline lies in how established professional practices for code and data design encourage what I call "imperial modeling,” in which developers fight for total ownership of the environment from which software emerges.

The revolt against imperial modeling of code has already taken shape in the form of languages and agile methods. Agile programming emphasizes highly iterative development in close collaboration with the eventual users of the product. Even more important, it stresses the inevitability of change and evolution. In effect, agile developers pride themselves on being able to rapidly accommodate change.

The same revolution is in the offing for data modeling. There have been some developments in agile databases which, literally, adapt the ideas of agile programming to the design of (usually relational) databases, but there is also progress occurring in semi-structured databases and, in particular, XML.

The success of XML has so far stemmed from the success of the Web as an integrating platform for applications and data sources. However, many companies that appreciate the clear power and flexibility from applying XML to Web solutions are looking to drive XML more deeply into business information systems.

XML's basic nature abhors imperialistic design and supports agile development.

It exposes a simple structure in which annotated text serves as the natural unit of business information.

XML's power comes from transparency; these information units are easy to search, retrieve and view, restoring human interpretation to information structure. Imperial modeling squeezed out interpretation, sacrificing tremendous flexibility.

As XML becomes a more important data format, developers must strive for "humble modeling," in which the developer makes as few assumptions and imposes as few constraints as reasonably possible on the system. It is a defensive practice to anticipate change, seeking to minimize the costs of change through flexibility, rather than through the imperialistic doctrine of change control.

In my experience, one important XML design practice that supports humble modeling is to provide liberal areas for anyone to add structured or unstructured annotations to XML documents, and to account for them in supporting applications.

Such a simple step goes a long way toward helping restore balance between IT control of data and business control of the expression represented in the data.

It takes an expert touch to find the right balance in humble modeling, but it's worth the effort, as I've observed from the surprised gratitude of managers who are realizing that they can expect rapid and positive response from developers rather than the usual resistance to jack-in-the-box change requests.