Who Will Be Your XML Expert?

by Bill Trippe

If you've been looking at content management or enterprise application integration technologies, you know there's a great deal of technical implementation work to be done involving XML. The question is, who's going to do this work for you?

Take content management, for example. Vendor offerings differ in many ways, from the kind of repository they use to the programming languages required to support them, but they all use XML under the hood. Some use XML for storing the content itself; some use it for metadata and other supporting data files; some use it for data interchange; some use it for all these things and more. To get the most out of these systems, the implementation team should use XML and associated technologies such as XSLT.

Organizations typically have three options for getting technical implementation work done: contract with the vendor, contract with a professional services or consulting company or do it internally. In reality, project teams often adopt all three approaches. For example, on a large content management project I worked on recently, implementation work was divided equally among the vendor, a consulting company and a two-person, in-house technical team. The goal was to get the system up and running and teach the in-house team to be self-sufficient on the new system.

If you're implementing a content management system, you'll need to develop some in-house XML skills. But how much and what kind of XML expertise do you need? Will you need specialists, or will existing technical staff be able to cover the required skills?

XML has many applications, but the technical skill sets for working with XML fall into two general areas: modeling XML data for ongoing use and using programming languages to manipulate and transform XML data.

XML data modeling is similar to modeling a relational database. Indeed, relational database developers work with database schemas, and XML developers work with XML schemas or document type definitions (DTDs). Because the analyses for creating relational and XML schemas are similar (although not exactly the same), it's reasonable to assume that your relational database administrators can learn to develop and maintain your XML data in time. However, because the two processes aren't exactly the same, it's also reasonable to assume that you'll need specific XML data modeling expertise in some situations.

Larger organizations, especially, are hiring or somehow internally developing data architects — individuals or small groups of individuals who develop comprehensive enterprise data models. Job descriptions and titles vary, but the common theme is extended experience in both relational and XML data modeling. Data architect isn't a new job title, and the goal of establishing a uniform data model isn't new. What is new is XML's inclusion in this data model, and the growing realization that XML data is a big piece of the enterprise data store. Larger organizations should consider specific XML expertise when looking at data modeling questions.

The other half of the XML skill set — manipulating or transforming XML data — is also analogous to the relational database world. Programmer/ analysts are usually proficient in connecting to databases, providing interfaces to such databases and querying and extracting data. Manipulating XML data is similar, with the important and obvious difference being that the methods used with XML are newer, less proven and less widely understood. XML also has its unique challenges: It can be quite hierarchical, for example. If you have complex, extensive XML data, you may need XML-specific expertise.

In the long run, XML will be part of the fabric of your IT organization and among the skills that your technical people will possess and build upon.

Bill Trippe (btrippe@nmpub.com) is president of New Millennium Publishing (www.nmpub.com), Boston, a consultancy specializing in electronic publishing, content management, SGML and XML.