One of the LinkedIn Groups I subscribe to is the "Informal Network of Standards Professionals". There have been a few interesting threads over there, including one about how standardization processes have changed -- or need to change.

In the case of information and software-related standards, the issue is simply that standards development methodologies haven't kept up with the pace of change in software development methodologies.

Software development methodologies have undergone revolutionary change in just the past decade. By comparison, the development methodologies of most SDOs and consortia have remained largely the same. SDOs and consortia tend to be the last great bastion for "death march" projects and "waterfall design". Under traditional standards development approaches, the balance of development time is spent in upfront design and drafting of specification documents. Key quality assurance processes, such as testing and the development of reference implementations tend to be activities that happen at the very end of the standards-approval project (if they occur at all).

What is needed?

• Realistic planning and estimation of what it will take to get a standard to a reasonable state of maturity.
• Some notion of iterative and test-driven development.
• Better delination of roles and responsibilities among a broader, more inclusive set of standards stakeholders.
• Better specification of requirements and interim testing and retrospectives as means to ensure requirements are effectively dealt with.

The rise of the API as a means to deliver services and other business capabilties from the Internet isn't a new development. However, it is a safe prediction for 2009 that the number and variety of APIs for accessing business services will continue to proliferate. In theory, industry standards should benefit as more service providers look for proven models to put up new APIs. You'd also imagine that customers would be demanding adherence to industry standards in the hope that standards would be of help should customers want to get their data back from "the cloud" (see Vinnie Mirchandani's related advice for customers as they move into the cloud).

The reality regarding the role of industry standards as the basis for APIs is messy. In the next several posts, I'll take a look at some of the opportunities and challenges for industry standards. First, I'll take a look at how the licenses under which standards are offered by different standards organizations help and hinder standards adoption and convergence.

Derivations and Modifications

I'm not an IP attorney, but you don't need to be an IP attorney to realize that the lack of a standard license for business language standards adds costs, complexity, and poses a barrier to opportunistic use and convergence of industry standards. The matrix below isn't intended as anything like an in-depth analysis of the IP policies of different standards organizations. But then again, most developers and implementers don't do much research into these licenses anyway. They simply assume freely available standards are available for use without restriction - which isn't always a good assumption. While not wildly divergent, the licenses described below do illustrate a few common differences among licenses.

While the pace of business change is never slow, many observers note that the current economic downturn, far from slowing the pace of innovation, is certain to increase the pace of change within many sectors. The growing attention given to "cloud computing" is one example of economic constraints driving such change.

In recent a post, I promised I'd address the relationship between standards and APIs. A broad assertion that I believe holds up fairly well, is that standards are not APIs, but that ideally good standards figure into what makes a good API. As I write this post, I notice that IBM's Bob Sutor has put up a post on his blog describing issues with the proliferation of APIs that fall short on measures of "compatibility," "interoperability," or "interchangeability." Bob writes:

With cloud computing becoming more and more important, people are correctly asking questions about standards. My sense is that virtually none of the cloud environments are interchangeable and that interoperability among them is sketchy, at best. Unless one provider ends up being overwhelmingly dominant, interoperability will need to be improved.

Many would agree that standards potentially have a very important role to play in leveraging capabilities from the cloud. However, many also would agree that there are significant obstacles to realizing anything like standards-based cloud computing.

The Challenge for Standards Development Organizations

How to Change

They say "a change we'll do you good." That "the only thing that is inevitable is change." We know change brings opportunities and challenges and that change is hard. In Part 1 of this series, I wrote about the importance for standards organizations to have a maturity plan in the same fashion that a maturing commercial product would have such a plan. In Part 2, I provided some background on HR-XML's origin and its early years. In this post, I take a look at some of the events that led to the HR-XML 3.0 project.

Tool Troubles

In business and in life in general, someone can tell you exactly what you need to know, when you need to know it, but the information doesn't always get acted upon immediately. I mentioned that in our very early days, Microsoft had helped raise our profile by allowing us to participate in the BizTalk launch. The very gentleman who had been so helpful back in 1999, visited us at our April 2004 New York meeting and gave us a review of our then 2-year-old version 2.* library. Let's just say this was delivered in the blunt manner characteristic of engineers. He covered items such as the complexity of the xsd:includes (see my Part 2 of this series), the use of troublesome schema features (e.g., the way we had used xsd:union within the date types throughout the library) as emphasizing that interoperability required a solid data model - not just XML. He concluded his presentation by saying something to the effect that we could fix these deficiencies or just become another group that travels, eats a lot of "hotel chicken," and shares a few beers together after work group meetings. The presentation did trigger a lot of discussion, but not necessarily any particular next step.

If you've worked in standards development for any time, you've likely seen skirmishes as well as major battles. Some prove to be worthy fights, while some have proven to be an absolute waste of everyone's time. Few produce absolute, bright-line resolution, but many do influence the directions of all parties - often for the better. Some are civil, while some involve behavior that we probably wouldn't want our children to emulate. However, this post isn't a rant about manners.

I'd be curious about what others who have worked in the area of business language and messaging standards would consider the most unruly standards battle of the past decade? "WS-*" web services versus ebXML? OAGIS vs. UBL? UN/CEFACT CCTS vs. ASC X12 CICA? While "REST" isn't so much a standard or specification, some of the "WS-*" web services vs REST debates have approached the same decibal levels. Even the "un-standards body," Microformats community, has had a bitter debate or two within its ranks.

While avoiding acrimony is desirable, the level of rancor within a discussion isn't by itself an indicator of progress or a lack of it. You can certainly find examples of individuals and organizations who were opposite sides of some of the aforementioned battles who have found enough common ground to be working actively and constructively on standards projects today. Really, this is the very essences of standards making -- going from the divergent to the common -- so those who have managed to reconcile differences to work with former competitors truly are the unsung heroes within their standards-making communities.