I came across a post a while ago by Mike Herrick, ACORD is a Guideline NOT a Standard. The posting started a brain cramp in which made me realize that I agree with Mike. The word Standard is over used too many times. I happen to work for an organization that even has the word Standard in it’s name, however it makes me wonder if people actually know what that word entails.
According to wikipedia there are several definitions for a standard. Two of which I think most business to business standards, or even non-data standards fall into:
- A standard specification is an explicit set of requirements for an item, material, component, system or service. It is often used to formalize the technical aspects of a procurement agreement or contract. For example, there may be a specification for a turbine blade for a jet engine which defines the exact material and performance requirements.
- A standard guide is general information or options which do not require a specific course of action.
If we focus the discussion on B2B data standards which is where ACORD, OAGi, UBL, STAR, HR-XML, and others play. Then I would say that Mike is right, most of these are Guidelines not true standards. They aren’t specifications as they are fairly open. Of these, STAR is probably the closest to being a standard, but even it doesn’t meet the requirements to be called a specification.
OAGi and UBL are really in a gray area, as they try to cater to everybody. OAGi is a great canonical model, but because of the extension point mechanism, it will fail to become a true specification. The user area will always have one off implementations that will cause users interoperability issues.
Extensions Encourage Guidelines
The problem with most B2B standards is that they include ways for users to extend the “Standard” with out contributing changes or requirements back to the organization. This automatically opens up the message format for incompatibilities between implementations, and while it helps get something going, it makes it more of a template than a true standard. Some will say that there has to be a way to extend messages for particular business needs. That’s fine, if extension is going to be allowed then realize that there will be very little interoperability amongst the user community that uses the messages. The goal of a B2B standard is to help reduce cost, and rework that trading partners have to do during implementations. By allowing extensions, they have ignored the role of a standards organization.
With that said, I can see the use of extensions being useful if the messages are being used as a Canonical model for internal company use, and the messages are never ment to be sent outside of the company. Then the only ones affected by the extensions are the ones within the company. There is a narrower user community and scope when it comes to this, as there is a captive audience for the messages.
No Extensions, but Comminity Extends Anyway:
To try to combat this interoperability problem, a maintainer of standards can try to eliminate this problem by not providing extension points. However, unless the user community plays nicely and abides by the rules, then there will be extensions to the standard. Reasons for extensions include:
- Standard Organizations are too slow to get requirements in place.
- Thinking business needs are unique.
- Thinking it will help competitors
- Only allowing members to submit changes or modifications.
The first and last reasons the organizations themselves can partially address. The user community is right in saying that it can take way too long to get a change into a particular standard. Working with UNCEFACT at times, it can take years to work a change through the various processes. To address this need, organizations need to be willing to submit smaller releases more often. The agile discipline of small frequent releases can be beneficial to the user community. What that release schedule is, is going to have to be determined by the members and user community of the particular standard.
The last reason is one that is more difficult to address because politics start getting involved. There has to be a reason for somebody to want to join an organization, and many organizations only allow members to submit changes. I’d be interested to hear ideas on how this can be addressed, and still meet the members needs.
Guideline or Specification:
If we are being honest then one should appropriately title the messages. If extensions are allowed then it’s a Guideline. If there are no extensions, and strict rules for implementation then it’s a Specification. In order for an organization to become more specification like it needs to do the following:
- Make sure there are clear rules and requirements for implementation.
- Work with the user community to promote contributing requirements back to the organization. No “like” or one-off extensions to the messages.
- User community needs to help police the implementations, demand that trading partners follow the specification and not extend.
- Help document how the message format should be implemented, and the uses for each message.
B2B standards need to become more specification like. This in and of itself will help reduce the cost of implementations, and development for these messages. Specifications like ebXML specifications, and AtomPub are showing that this can be done. Notice that I called these specifications and not standards. The reason being is that they follow the first definition of a Standard, they have strict rules and requirements that need to be followed.
There will always be the need for Data Mappers and other tools to help profile the messages. Having messages become more like specifications, can help everybody in the long run. Maybe I’m looking at this through rose colored glasses, but I think we can get close to the dream. It just takes us looking out for the larger group instead of our little piece of the pie.