A few months back, I devoted a column to highlighting the differences between data models and data standards for exchanging information (see the January 2004 issue of DM Review). Since then, I have continued to think about the use of data standards, particularly because I have heard a lot of people clamoring for the definition of data standards (especially using XML). Yet, I conducted a Web search to find out why people want to define data standards, and I was a bit surprised at how little discussion exists focusing either on what is expected from a data standard or what benefits there are to using a data standard.

Perhaps the expectations and benefits are so obvious that they don't need to be stated? Or, perhaps the common utterances of" some of the time.) Just the same, I intend to take a stab at it anyway - this month's column will articulate what I suggest my clients can expect from a data standards project.

Expectations
To begin, it must be clear that data standards are used when information is exchanged between two or more collaborating stakeholders. Everything related to these standards, therefore, must be directly important to those stakeholders. Consequently, the usefulness of developed data standards is reflected through four aspects of what is to be expected by the relevant stakeholders, namely:

Definition, which focuses both on the business-oriented aspects and the technical infrastructure for defining concepts, instances of representations of those concepts and the mechanics by which those representations are managed.
Context, which describes the participants and environments in which information is exchanged.
Agreement, in which the participants agree to the content (i.e., names and meanings) and structure (i.e., what the data looks like) as defined in the standard.
Conformance, which specifies that the participants agree to abide by the syntactic, semantic and policy implications of the standard, as well as how conformance is determined and audited.
The following subsections provide details to these aspects.

Definition

The aspect of definition comprises definitions of business terminology, the data types used for representing information and the valid data domains from which data elements may draw their values.

Business Terminology: As part of the data standards definition process, all common business terms used throughout the enterprise and their definitions should be enumerated and published in a catalog made accessible to the stakeholders.
Data Types: In addition, all common data element types that are employed for representing the values assigned will also be enumerated and documented.
Data Domains: Any explicit domains of valid values associated with any data types must be exposed and/or referenced.

Context

The context of a data standard focuses attention on the types of parties that share information and the administrative exchange contexts, the definition of data presented to the viewer and the framework used for exchange.

Exchange Contexts: There will be an enumeration of all contexts in which data is exchanged, such as between trading partners, companies and regulatory bodies, or intra-enterprise communications.
Presentation: There will be a default mode of presenting a visual representation of each data type when displayed to an information-worker, such as MM/DD/YYYY for dates.
Exchange Framework: There will be one or more formal mechanisms for representing the structure and mechanisms by which information is exchanged such as using flat files by FTP or sending XML messages via Web services.

Agreement

A draft standard cannot be approved as a standard until the relevant stakeholders exchanging data agree to what is defined in the standard, both in content and structure.

Agreement to Content: For each context in which data is exchanged, the relevant stakeholders will agree on which data elements comprise an exchanged record or message.
Agreement to Structure: Each record or message that is exchanged will have a defined structure for exchange.
Conformance

Lastly, even agreement to abide by the standard does not influence achieving the desired goals unless the parties conform to the standard. Conformance requires complying with the semantics of the standard, the syntactic representations and the policies governing the interactions.

Semantic Conformance: Each data element represents a value associated with one of the common business terms.
Syntactic Conformance: Each data element has values that belong to the associated defined data element type, and each takes its values from any restricted data domains.
Policy Conformance: All participants in an exchange context agree to abide by the standard, there are agreed-upon methods by which compliance is measured, and there are agreed-to consequences for non-compliance.
I have stated these expectations as assertions to separate the intentions from any implications. In fact, each one of these expectations may wreak havoc with production applications because changes to the way information is exchanged may reverberate across the information hierarchies within an organization. Not only that, agreement to a standard is more of an academic exercise, while agreement to abide by a standard (as well as pay the consequences for not complying) requires what may be a painful session in long-term change management.

In upcoming columns, I will address some of the benefits of using data standards as well as some of the issues necessary for successfully introducing standards into an enterprise.