My son just turned two last month. He's been speaking a lot lately. My husband is French, so we're raising him bilingual. He's picking up both languages equally well. Of course, he often mixes them together and will say things like "drive the voiture" or "more fromage."
He also doesn't quite have sentence structure down, so he'll come out with "mommy car drive." I realize he's not letting me know that mommy's car can drive, but sometimes he means that he wants me to drive the car, and other times he wants to pretend that he can drive mommy's car. So I have to find out what he really means.
Then there's the overuse of the word "no," which he'll use even when he means "yes." And he's recently added "never" to his vocabulary to distinguish the "no" that means anything versus when he really means "no." Fortunately, I'm smart enough to realize he doesn't quite get the meaning of "no, never" when I ask him if he wants his diaper changed.
In the systems world we suffer from the same confusion. It's as if we fill the room with two-year-olds from all parts of the world, then expect everyone to be able to understand what everyone else is saying–in other words, there is complete chaos.
If you break down any language, it really is a data model. In English, you have things like subjects and verbs and adjectives. You also have a way to assemble them so that the meaning is properly conveyed. We all know that "I have no chocolate" means something very different than "No, I have chocolate." Yet, the sentences contain the exact same words.
To reach the level where systems can communicate seamlessly with one another, a data model is an absolute necessity. A data model defines not only the terms that the systems must be able to understand and translate correctly, but also how those terms relate to one another. In English we have subjects, verbs, adjectives. In insurance, we have people, addresses and insurance coverages. In English, the subject must be before the verb, and the adjectives describe a noun. In insurance, the address is tied to the person, the insurance coverage, or is a standalone thing that's related to either the person or the insurance coverage.
In the past, organizations attempted to build enterprise data models with little success. The data architecture groups developed enterprise data models based on the corporate assets and would advise other teams on how to design databases, yet were not given any authority. Thus, they had negligible influence or impact. So, the data models would be created and the pictures hung around the walls for all to admire, but each individual IT project would ignore this effort and build their own thing anyway. As a result, we've gotten used to believing that a data model really isn't important.
XML changes this picture. XML (eXtensible Markup Language) is the way systems are communicating nowadays. You hear about it across all industries. When I go out to the hurricane center to check the latest advisory (something I do a lot since I moved to Fort Lauderdale), I find a link that allows me to download it in XML. Travel sites, book re-sellers and banks are all communicating with one another using XML.
XML is so successful because it moves from the traditional fixed length records to a format that allows the flexibility to support multiple purposes in a single data transmission. Its biggest strength is the constructs provided that allow you to develop standard vocabularies that can be enforced during communication.
Any XML implementation must define and utilize an agreed-upon vocabulary. If you want your hotel to appear on a third-party travel site, you must be able to share the necessary information using the vocabulary the travel sites require. And ideally, all the travel sites have agreed to utilize a single vocabulary so that a little bed and breakfast does not have to write hundreds of separate interfaces in order to gain some exposure.
All of a sudden those largely ignored enterprise data modeling efforts are pushed into the forefront and become mission critical to the long-term viability of any XML implementation.
The modeling work needs to be done before the XML can be designed and the data transmissions created. Otherwise you're creating a private vocabulary that can only be understood by the two systems who agreed to use it for a specific purpose. So, while we are now all connected, we still won't understand each other without an awful lot of costly translations.
By creating a data model first, XML second, companies begin to think beyond the point-to-point messaging approach. Instead of creating a separate interface between each and every system pair, a single interface can be used to communicate with multiple systems. Imagine that a hotel can read a rate quote request and provide a response that can be used against every third-party travel site. In that model, it's obvious that managing the data interface effort becomes much simpler over the long haul than it would be if each separate communication required a private vocabulary and thus separate programs to create and maintain it.
Companies that maintained their investments in their enterprise data efforts are best poised now to see the maximum benefits of XML, should they apply those principles to their XML work. Companies that abandoned the whole enterprise data group concept for lack of funding and support must now scramble to put the equivalent together so they can realize some benefit from their XML investment.
The downside to creating a data model that stands up to the data requirements across a corporation is that it is a costly, lengthy endeavor. So, companies are tempted to skip this step to streamline the process of getting XML-based processes up and running.
It's the first project in an attempt to communicate in the new world of XML that will take the hit. It will take longer and be more costly than if the architects just created an interface for that first project. But the long-term costs of maintaining interfaces slapped together for one purpose at a time will skyrocket as soon as you introduce the second one.
If you want systems to be able to communicate with one another, you must go through the work of building a data model. Otherwise, you may think I have no chocolate, when I really mean "No, I have chocolate." And you may not understand that "never" is a really long time.
© Arc, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.