Kitchen-sink standards may disguise failure to standardize processes and identity
by Rick Jelliffe
But my contact had two particular gripes. The first was that the standardization process was addicted to making new vocabulary items, to the extent that talking about standardizing other things had never worked: the consortium was for making schemas not solving problems! In particular, while there was a lot of attention paid to describing what each field meant, there was no facility for comparison or identification: to say that "this address is that address" or "this person is that person" or "this agent is that agent" except by accidental string matching. So electronic forms using these schemas could be filled out, but data could never be integrated.
The second gripes comes out of the first. Because of the lack of ability to integrate and identify data, it all had to be kept together or messaged around in a bunch. So the schema for a complex process has to include fields for everything in that process except for trade secret fields, which wouldn't be interchanged anyway: the consortium is made up from fierce competitors with a religious belief that their internal processes will be different from the internal processes of any other company in the same industry. Originally many participants would not even disclose the field names in their databases, they regarded them as so important—only to find that ther field for address was not so interestingly different from their competitor's equivalent field.
So the result: kitchen sink standards that include so many optional or process-particular fields that the consortium is now having a problem that not enough vendors are able to implement the whole thing. However, underlying this is the problem that without even a simple process model, where each stage of the process could have a fat-trimmed or specific schema, one size has to fit all.
So my contact actually saw the standard as dying rather than thriving: the mania for new elements and structures bloating the project in the direction of unworkability coupled with a refusal to look at standardizing even basic process models or identity/tracking/aggregation capabilities.
I guess it is easier for some groups to toy with extraneous details of a complex standard rather than get to the heart of the issues. In cases like this, to keep things moving forward, it is often easier to modify the applicability of the standard so consensus appears withing reach. If the subject standard is so important that there is a possibility that it would be mandated by a regulatory agency, the modified standard can be approved, and tougher issues can be sorted out later and the standard modified, or a new standard developed. I think stakeholders are come to the table with the impression that only one standard can be developed, when there is an opportunity for many, each one 'fit for purpose' for some standard users, but maybe not for others. I have come to understand that most problems in standards development stem from the participants just not understanding the process or how to navigate the process.
|Thomas M Kurihara
|More then process, understanding the goals and objectives, including the performance of an information exchange system that is designed to conform to that standard, among others. Discussions regarding architecture, use of a common lexicon, and models showing the actors characterized by the standard are elements of getting throguh the process. Without a common framework within which the process is to work and an agreement to use the process, inordinate amount of time is spent discussing and rediscussing the meaning of terms and concepts. Apply principles of standardization to the process to get the promise and benefits of standardization. Lots of luck, intuitive and firm leadership, and responsive and dedicated experts are some of the ingredients for a recipe for a successful outcome.|