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.

My copy of Todd Biske's new book, SOA Governance, arrived today. It is mainly well done. Before you order you should know that this is much more in the genre of a management book than a technical reference. Much of the book uses a narrative about a SOA implementation at a fictional company, Advasco, as a device to explore SOA implementation and governance issues. The book isn't likely to solve all your SOA challenges, but it is useful and an easy read. Among the material that is particularly valuable are the role/position descriptions for a SOA team in chapter 8.

While I'm generally positive about the book, I do have a few issues it. As you might expect, there is a division in the book between "design-time" SOA governance and "run-time" governance. While Biske talks a bit about "design-time checkpoints," he only really talks about testing and measurement as a post-launch, run-time task. For example, Biske writes "the final process associated with SOA governance is that of measurement and improvement". I think something that is missing is a specific mention or any emphasis of the role of iteration and testing during design time. For example, if you read through the section on developing a "canonical model," it sounds more like a classic "waterfall" approach that is highly dependent on accomplishing the correct upfront research and the right agreement among stakeholders ("Consult all potential service consumers," etc.). My own advice would be for SOA implementers to expect model development (perhaps the most important "design time" activity) to be highly iterative and to be test-driven as much as possible.