Continue in 2 seconds

If a Standard Falls in the Forest...

  • July 01 2004, 1:00am EDT
More in

At a recent conference, I sat in on one of the sessions that focused on a company's experience with constructing a corporate meta data repository. At some point during the talk, one of the attendees asked, "Has your company defined any data standards?" The presenter, with a completely straight face, replied (and I am paraphrasing), "Yes, plenty, but nobody uses any of them." There were a few chuckles, but the comment resonated with me for a few reasons that I think are interesting to explore.

First of all, the fact that there were only a few chuckles surprised me. Data standards are defined to enforce conformance with expectations, but a standard is not really a standard if no one is complying with it, hence the laughter. An organization that has invested in the effort to define a data standard that everyone ignores has wasted its investment. My second surprise was the presenter's straight face when he replied, which implied that he didn't realize how incongruous his comment was.

My last few columns have centered on articulating the value of data standards, which are critical to any organization that exchanges information. However, this one small interchange reminded me of a fundamental concept and a fundamental obstacle to information standardization. Curiously, both are the same thing: cooperation.

Any kind of standard works because those participating agree to participate. Consider the United State's transition from using precious-metal-backed dollar bills to Federal Reserve notes. Until the switch, every paper dollar bill was effectively redeemable for its equivalent value in a specific precious metal (numismatic purists, please bear with me). But after a certain point in time, the government stopped redeeming these "certificates" for their representative bullion value, and replaced them with "fiat" money. Yet the value of a Federal Reserve dollar remains a dollar, not because there is a dollar's worth of gold in the bank backing it up, but because we (the users of dollars) and the government (the issuer of dollars) agree that a dollar is worth a dollar. Consequently, we exchange things with intrinsic value for those dollars; and, in turn, we can exchange those dollars for other things with intrinsic value.

Similarly, all participating parties gain value from the use of data standards as long as they agree to comply with those standards. I can build my supply chain system to accept electronic data interchange (EDI) transactions that conform to a standard. If your company complies with that standard when we do business, your orders will be fulfilled more quickly and my company will get paid more quickly, which provides benefits to both parties.

Alternatively, the need for cooperation is an obstacle when there is no clear benefit to be gained by one (or more) of the participants from working together. Having a strong business case that describes benefits to everyone in the room is a key artifact upon which the success of a data standards program rests. This important piece of the puzzle is frequently omitted from the "data standards negotiation." Let me give another example. In a recent meting I attended, a group of individuals representing various constituencies assembled to begin the task of defining data standards. Yet when the time came to describe how the information to be exchanged was going to conform to the standard, all of the attendees were adamant that one centralized server should be the focal point for ensuring that exchanged data complied with the standard.

As the only iconoclast present, I commented that I thought it should be up to each represented organization to provide assurance to the others that the data it would forward would meet the standard, and that relying on a centralized server for compliance checking defeated the purpose of having standard. "Clearly," I said, "if you are meeting to agree on how you are going to package data elements, you should also agree to comply with that standard and the other participants should be able to build their system based on that premise. Therefore, you shouldn't really need centralized compliance checking at all." My comments were met with significant disagreement, but it just goes to show you how difficult it is to dictate cooperation.

It boils down to this: What I think happens is that individuals are very enthusiastic about defining data standards, but are much less so when it comes to implementing them. Defining a standard is a nice show of cooperation - representatives of disparate groups congregating on a regular basis to discuss common interests. Implementing a standard is difficult, because it requires an investment of staff, money, hardware and software resources. However, the success of a standard doesn't lie with its definition, but with its use. Perhaps this explains the lonely existence of the presenter's company's data standards.

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