Here we go again. Whenever new technology becomes available, people expect it to magically fix all of the problems of the past – without any effort on their part. But it just doesn't happen! New technology builds on the experience of the past, but it rarely says we should forget that past. There are really no new problems (we have encountered most of them already), but new technology often offers new and innovative solutions to old problems. So it is with XML.

XML is not a silver bullet. It will not magically integrate the many redundant data versions that exist throughout most enterprises. It will not replace them with a single, common shared version of integrated data. But it will enable us to achieve the effect and many of the benefits of this Holy Grail if we use it correctly.

XML makes it even more imperative than ever that an enterprise understand and resolve the different words and meanings that it uses to refer to things important to it. To illustrate, people may variously be called customers or clients or debtors – all terms used to refer to people or organizations that buy from the enterprise. These different terms indicate semantic differences. An organization must know the different meanings of its data (as meta data) that are used throughout the business. It must then define standard terminology – and establish agreed meaning – as integrated meta data to be used by the enterprise. Only then can these terminology differences be resolved so that semantic integrity is maintained.

As data administrators and consultants, we were fooling ourselves if we thought that enterprises would throw away their many (dis)integrated legacy systems to improve semantic integrity. Pragmatically, legacy systems and databases will never be replaced for semantic purity alone. However, once we understand the semantic differences and agree on the integrated meta data, XML can achieve dramatic cost savings.

Consider XML. It enables the meta data language used by each application or department of the business to be documented in a separate language dictionary. The meta data language dictionary used by each application is documented in an XML document type definition (DTD) file. This is called "application meta data." Common terminology is then defined for use throughout the enterprise. This is referred to as "integrated meta data."

Knowing the semantic differences between application meta data and integrated meta data, XML can be used to resolve those differences. We then know that the meta data used by the order entry department for customer and the meta data used by the credit control department for client both refer to the same thing – common integrated meta data of "organization." XML transformation engines can then carry out this semantic transformation.

We must also recognize that XML alone cannot solve the semantic problems of legacy databases and systems: data redundancy. The only way this redundancy can ever be resolved is to throw out the legacy databases and systems and start again with an integrated database. As we discussed, that did not happen – and it will never happen for semantic integrity reasons alone.

Thus, the same data still exists redundantly in the customer database for the order entry department, the client database for the credit control department and the debtor database for accounts receivable in the finance department. With XML, these different data versions can easily be synchronized dynamically via XML messaging. These XML messages are analogous to the physical "change request form" that was sent to order entry, credit control and receivables notifying them of a change so they could update their respective redundant data versions; but now through XML message transformation, this synchronization occurs at electronic speeds.

XML is not a silver bullet; but if we identify meta data and resolve semantic differences throughout the enterprise, we can use XML very effectively to resolve those differences. We can use transformation engines to transform between and synchronize redundant data versions at electronic speeds. We can then reap the integration benefits as if we were truly using a single shared version of common, integrated data – without having to throw away the legacy systems as was suggested originally.

This problem of different application meta data within departments of an enterprise is magnified greatly when organizations communicate at electronic speeds through business-to- business (B2B) trading exchanges. Common message formats and integrated meta data enable clear electronic communication between buyers and sellers. XML can be used to transform between application meta data and integrated meta data. This is called enterprise application integration (EAI).

The cost savings can be dramatic. For example, typical procurement costs based on mailed or faxed purchase orders often exceed $100 per PO, regardless of the actual cost of the product being purchased. With B2B electronic procurement using XML, procurement costs are reduced significantly to less than $10 per PO (GartnerGroup). These are cost savings that go straight to the bottom line for all concerned.

XML is not a silver bullet. But when used well – based on agreed terminology and meta data that is defined using data modeling methods and modeling tools – it can deliver great cost savings and improved operational efficiency.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access