XML: The E-Business Jack-of-All-Trades

by Bruce Silver

It seems that the answer to any information exchange problem today comes down to the same magic bullet: XML. Need to personalize Web content? XML. Need to build an online catalog? XML. Need to repurpose content for print, Web and wireless? XML again. How about integrating back-office systems across your supply chain? B2B commerce, including emerging Web services? OK, you get the picture.

XML's power lies in its simplicity. Like HTML, it is tagged text, readable not just by humans but also by any kind of system, without APIs and expensive EAI. But where HTML defines form, XML gives structure and meaning to the content. Information elements in an XML document can be large unstructured blocks - what we commonly call Web content - or structured data, or both. To XML, it's all the same. Also, because it is inherently hierarchical and self-describing, XML provides both the richness necessary to describe the data exchanged in today's extended business processes, such as B2B commerce, and the flexibility to accommodate the wide diversity of information elements required by each participant in the process.

Thus it should be no surprise that as companies roll out their e-business initiatives, they're starting to get large volumes of XML. Now they have to deal with the obvious problem of how to manage it all. Web content management technology is doing a good job with the "unstructured" part - the content on the Web site, including online catalogs - but what about the transactional data itself. The order quantities, part numbers, and shipping and billing addresses flowing between buyers and sellers are all XML as well.

Initially it was just assumed that in data-centric applications XML would be used simply as an Internet-friendly pipe between existing relational databases. But the "information democracy" enabled by XML does not always fit easily with the traditional relational model. Remember, EDI "failed" because it could only be applied where a large company had enough market power to force its suppliers to use its rigidly defined data structures, regardless of the impact on the suppliers' existing systems. XML-enabled e-commerce was supposed to break down that rigidity, more flexibly accommodating the diverse requirements of all members of the commerce network.

But to the relational database at the hub of such a network, diverse and changing information structures present a massive problem. Designing that database means carefully organizing all the information it manages into rows and columns of relational tables, a complex process that typically represents more than half the entire system development effort. Accommodating unique data elements needed only by one trading partner leads to inefficient and slow databases, and the time and cost of responding to new and changing requirements can derail the whole project.

Standardized, application-specific data structures called schemas are the industry's proposed solution to this impasse. But as in all such work, there are competing groups, standards progress is slow and continually changing and adoption is spotty. In B2B initiatives, designers often have to plan for XML based on no standard schema, multiple schemas or schemas that will change significantly within six months.

The next obvious question is, why not use an XML database to manage the information in its native form? Native XML databases can manage XML data without knowing its schema, or where no schema exists - a key advantage over relational databases - and there are now several of them on the market. Most are based on document object models (DOMs) that essentially parse XML into a data tree in memory. The main problems with native XML databases so far are slow performance (particularly as the data volume increases) and huge storage requirements. A new company, NeoCore, Colorado Springs, CO, is taking a radically different approach based on pattern processing, and it is achieving query transaction rates measured in thousands per second, hundreds of times faster than both relational databases and DOMs, even with gigabytes of XML data.

One of the most exciting applications of the new generation of XML databases will be mass customization of services. Consider this example. A leading national provider of wireless services sells consolidated provisioning and billing to large corporate customers, who in turn allow their employees to configure and activate their individual accounts online. The provider's system must handle not only the unique data required by each corporate account's back office and e-procurement system, but also the myriad geography-dependent hardware configurations, rate plans and billing systems.

Only a fast XML database could handle the data diversity and change demanded by the wireless provider's ever-growing list of corporate accounts. At the same time, it would also have to meet the performance demands of thousands of individual employees obtaining online self-service.

This sort of mass customization of outsourced services on a common information platform has applications from HR benefits administration to procurement networks, payment processing or group insurance. Now a company that provides a service for one or two customers, perhaps just internally, can cost-effectively "repurpose" that service and customize it to the needs of additional customers, creating powerful new business models. How is this possible? Simple... XML.

Bruce Silver (brsilver@earthlink.net) is president of Bruce Silver Associates, Aptos, CA, 831-685-8803. Reports are available at www.brsilver.com.