Two weeks ago, I told you to start learning as much as you can about Extensible Markup Language (XML). XML is almost as good as sliced bread, and it’s destined to add tremendous value to the process of building data-oriented applications. XML is great because it lets back-end systems easily share self-describing data sets and it lets front-end applications (such as browsers) display information in an intelligent, easy-to-manage way without forcing the developer to focus on the data-management process. But XML isn't a magic cure-all for data-management woes. Improper XML use scares me; it scares me a lot. Here are selected quotes from articles I've read this past week that help to explain my concerns:
"Employees need several hundred pages worth of products, policies, and procedures to service customers. If the information in those pages can't be updated easily, it's virtually useless. Enter XML . . ."
"Unlike HTML, XML makes it easy to quickly locate and reuse data. An XML listing in a catalogue might label tags denoting the manufacturer’s name, product size, shipping weight, and price . . ."
"A catalogue listing can be re-purposed to select all instances of a particular product, select weights and prices of each and perform a cost-per-pound comparison . . ."
Simply delete those quotes and you end up saying: Updating XML data? Searching XML data? Standardizing meta-data definitions within an XML store? Those capabilities sound like standard database tasks that any application requires. Simple XML content-management systems enable developers to meet simple data-storage needs without using a robust database management system (DBMS). In some development shops, this capability will quickly lead to front-end developers devising data-management policies and techniques without the benefit of experience that database pros have. How would this happen? At one time or another, all good DBAs have fixed a data-management nightmare caused by extremely bright and talented developers who, unfortunately, know nothing about databases. The nightmare might include poor logical and physical design, inefficient data-access middleware and cursor usage, or sloppy data standardization in enterprise environments. These problems can foil an application’s success, but thedevelopment team can fix them if they catch the problems early enough. More often than not, these problems are trapped in a development cycle when the development team decides they need a little DBA help in setting up the database and the DBAs come into the project for the first time. Then the DBAs go back to their offices to stamp and stomp and scream that the developers are dumb, while the developers stamp and stomp and scream that the DBAs are unreasonable. But in the end, the project goes right—mostly.
What happens when front-end developers who are pressed for time make a complete end run around trained database people? Maybe nothing, or maybe the application ends up a big pile of unfixable junk. What if the developers do manage to make all the correct design and implementation decisions without professional data expertise, but they use an XML content-management system that doesn't provide adequate scalability, security, manageability, and transaction context control?
I'm sure you see where I'm going with this. Developers and DBAs both need to learn new skills to ensure the success of significant XML rollouts. At the same time, object-oriented database management systems (OODBMSs) masquerading as XML content-management systems need to mature, and relational database management systems (RDBMSs) need to provide more integrated, native XML support. XML-oriented application development will be a little scary until all this happens. But I suppose IT wouldn't be so much fun if everything were simple and easy.