Perspective on XML: Be humble, not imperial
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
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
Uche Ogbuji is a consultant and co-founder
at Fourthought Inc. in Boulder, Colo.
He may be contacted at email@example.com.