>One of the fundamental problems with Business-To-Business interoperability of data standards are the many one-off variations that occur. This is compounded by the inclusion within these standards custom extensions to the specification. While this may seem like a good idea from a implementation point for the one person needing to extend the standard quickly; it’s bad for the person that has to support not only that extension but the extension of 20 to 100 other trading partners as well.
One of the reasons that standard organizations add extension mechanisms to their data standards is the fact that they aren’t setup to adopt quickly to the changing needs of their membership. The process of getting a change into the standard can take months to years to get officially incorporated, in the mean time the member requesting the change has real world business concerns that need to be handled now. So they extend it, and never bother asking for the change to be added to the standard. Some people will just say that is the way it has to work, that standard organizations are bogged down by politics and too many committees. Maybe it isn’t the standards that are the problem, but the way they are developed.
I’ve worked over the last three years to help try and prove that Business-To-Business standards don’t have to be the slow monolithic monsters they have become. They can be quick, nibble, and agile. The same concepts of the Agile Manifesto can be applied to the development of Business-To-Business standards. However, it’s not just changing the way the standards are developed, but it’s changing the internal attitude toward how they can be developed.
Concepts such as Unit Testing, Iterative Development, Product Backlogs, and Continuous Integration, can all be applied successfully to Business-To-Business standards development. I presented a paper on these concepts at the XML 2006 conference entitled, “Agile XML Schema Development”. It reviews from a development standpoint the criteria we followed to move our development process over to Agile techniques. The best thing from a standards organization standpoint for implementing this is that it can be done with open source tools. In fact, our main development environment is based on eclipse and the Web Standard Tools platform. We give this same development environment to our members as well.
The biggest challenge though is getting the members of the standard organization to try and change the way the standards are developed. Resistance to change is one of those things that is difficult to over come, many just don’t understand how it will improve things. The best advice I can give here is to just try it with a small project and implement the processes in stages. It took us about a year to get everything setup, but the membership saw benefits sooner than that.
Standards don’t need to be slow and cause implementation headaches with all their variations. They can be nibble and agile. Hopefully they make life easier instead of harder. After all, that is what the goal of a standard should be.