>Agile Standards Development

>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.

This entry was posted in agile, eclipse, standards. Bookmark the permalink.

2 Responses to >Agile Standards Development

  1. Klaas says:

    >Being active in the W3C I am very interested in delivering standards quicker than is typically done today. One very important aspects of open standards is backwards compatibility. How do you see agile standards development deal with that without forcing people to implement its at the end of all iterations instead of after every interations? Because when forcing people to wait, you end up with the same probem.

  2. David Carver says:

    >We run unit tests and user acceptance tests to make sure that we aren’t breaking anything that was working with the last published release. We run these tests during every time there is an integrated build. In our case we check for new code checked in every hour and if there is new code we run the unit tests again.The hardest part is getting the users to submit back the user acceptance tests. Which are just XML files that validate against the Schemas produced. If something that validated in the pass doesn’t validate now, we know we have a breaking change that we need to address.Unit testing and User Acceptance tests are the key to making sure that you aren’t breaking anything.The iterations are released as milestone builds, and we don’t recommend milestones being implemented in production. They are there for development purposes. If somebody implements a milestone and some change happens later that breaks it, it is up to the user to make sure they are working with the current milestones.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s