mark nottingham

Perspectives on the Addressing Experiment

Monday, 27 June 2005

Web Services

I don’t talk much about it here, but I’m honoured to be the Chair of the W3C Web Services Addressing Working Group. This is something of an experiment for the W3C, so I gave an update on its progress as part of a panel discussion at the Advisory Committee meeting a few weeks ago. I’d like to share some of what I presented there.

What’s the Experiment?

Standards can be developed in many ways. The W3C, historically, has had fairly long-lived Working Groups that strive to achieve perfect or near-perfect consensus on technical matters before shipping (this is a generalisation, but I think there’s at least a kernel of truth in it for the vast majority of cases).

This has a few effects; W3C standards tend to take a while to get to market, tend to invent new technology on the way (often becoming an unabashed Research and Development effort), and they tend to have a fairly wide scope.

While this is good for efforts that need research and development, it does place a large burden on the Working Group to get things right; because there’s so much investment in time and resources, participants have a huge incentive to make sure that the standard works, even if the market rejects it. This has caused elaborately architected, multi-year standards efforts (e.g., the OSI suite) to fail in the past, and undoubtedly will in the future as well.

“Politics is not the art of the possible. It consists of choosing between the disastrous and the unpalatable.”

• attributed to John Kenneth Galbraith

Other organisations take a different approach; notably, the IETF, with its mantra of “rough consensus and running code” cheerfully allows for technical dissent, in the interest of getting a technology to market quickly.

The role of standards will be the subject of debates for longer than I’ll be involved in them; personally, I feel that a balance between scope, speed and consensus is necessary to get technology to market, as well as provide real value.

In any event, many W3C Members, as well as some in the Team itself, felt that that balance was perhaps leaning too far in one direction with recent efforts, and wanted to shake things up a bit, by using the Web Services Addressing Working Group as an experiment in faster standarisation. Therefore, my role as Chair involves an additional task; assuring that the experiment is carried out well.

How this Working Group is Different

While the W3C has a cultural bias to sacrifice expediency for complete consensus, the Process does, in fact, give both the Chair and the Director considerable powers to move work forward. This is reflected in the Addressing Working Group’s Charter, which contains a number of measures designed to help;

Schedule-Driven — In several places, the Charter makes pointed reference to the fact that this WG will be “schedule-driven.” This has shaped our overall approach to issues and our work.

Tightly-Scoped — Likewise, the Charter delineates a specific scope of work, and does not allow us to expand upon it. This is designed to focus us only on a few things, avoiding the rampant scope creep and ‘what if’ sessions.

Good Standing enforced — The Good Standing rules in the Process are strictly enforced, to ensure that the WG doesn’t spend too much time catching people up on developments when they were absent, and so that people have to invest in participation.

So far, we’ve managed to close over 50 Working Draft issues, 100 Last Call issues, and take numerous straw polls and formal votes. Although some weren’t unanimous, we’ve only gathered one formal objection so far.

Frequent meetings — We’re chartered to have a Face-to-Face meeting every six weeks, with a two-hour teleconference every week. We also have an option to hold a second teleconference, if necessary.

Decision policy — The Charter explicitly says that when the Working Group can’t reach consensus, the Chair will assure that the issue is well-understood and all technical viewpoints have been accounted for, and then vote without looking back. This is probably the biggest divergence in WS-A from traditional W3C culture.

Submission as starting point — Finally, the Charter specifics that the Working Group will “refine” a specific Member Submission. The meaning of that word has been debated considerably.

What’s Working

So far, this seems to be working fairly well; although we’re behind schedule, we did deliver our first two Last Call Working Drafts in late March, just two months late. Considering that some people said that the schedule was flat-out unrealistic, not bad (especially when you account for the holiday season). Likewise, the tight scope has helped keep exploratory discussion reigned in.

The Good Standing rules also seem to be working well; despite being an administrative pain, and catching a few Participants by surprise now and again, participation in meetings is very good, which leads to higher productivity. It keeps people in context.

Overall, I’m impressed with the Participants in the Working Group; everyone has been willing to accommodate changes and work with the material that we have. There have been a few bumps, but there’s a genuine willingness to get this spec out the door in good quality and as near to on time as we can.

Risks

That said, there are risks going forward.

First, there may be subtle (or not-so-subtle) issues that we’ve missed. This is because it’s tricky to balance expediency and making the “right” decision; ultimately, we’ll only know when we ship.

Additionally, one of our deliverables — the WSDL binding — is required by the Charter, but isn’t fleshed out by the Submission. This will undoubtedly cause us to lag in our schedule (although the dependency on WSDL 2.0 may have the same effect).

Finally, the lack of solidly documented use cases, requirements, or indeed a standard, agreed-to Web Services architecture is a continuing source of concern.

When is Faster Possible?

I should reiterate that this approach isn’t right for every Working Group; it depends on several factors being present, including:

Well-defined technical basis — If you’re going to try to do it fast, you’d better start with something that most, if not all, concerned agree is largely complete and in the ballpark. This means that the research and development will be done by one or more of the participants privately, and brought in as a Submission.

Context between Participants — It helped us immeasurably that the large majority of those participating already knew each other from previous efforts; it avoided the acclimation process that usually consumes the first few months of a Working Group’s life.

Limited goals — The scoping really helped us in Addressing.

Limited external dependencies — A large set of external requirements and dependencies would have really slowed us down in Addressing, because of the schedule mismatches and administrative overhead.

Pressing need for a standard — If there isn’t considerable pressure for people to have the standard, it’s difficult to motivate the schedule and scope constraints.

Willingness to shift risk later in the process — It’s important to realise that taking this path shifts a substantial amount of the risk to later in the Process (i.e., after Recommendation); little details might or big flaws might slip through the cracks. On the other hand, there is enough structure in the W3C Process to force the WG to go back to Working Draft if major problems are found in interop; it just might mean a serious schedule slip if this happens.

Suggestions

If the W3C does decide to charter another Working Group like this, I have a few suggestions that I believe will help it succeed (that is, produce a quality specification in a limited amount of time);

Match the charter to the Submission’s scope — One of the issues we stumbled on was the fact that while the Charter requires a WSDL binding deliverable, there wasn’t anything to base it on in the Submission. Oops.

If a group is to do its job quickly, it has to base it on existing work, not create specs out of whole cloth; if we’d either had a corresponding Submission, or had a Charter aligned with the existing Submission, we’d be much less behind than we are.

Have use cases and requirements up front — Although the Submission contained a specification, it didn’t contain a set of requirements and use cases that illustrated why it’s needed, what can be done with it, or what the authors were thinking about it. If we had that information, it would have saved a tremendous amount of time; we wasted many meetings just agreeing on terminology, and there are still occurrences of someone realising, after interacting for almost a year, that someone else doesn’t have the same thing in mind, or even the same base assumptions.

I’m not saying that the Working Group needs to agree upon a set of requirements and use cases; merely having them would be a huge step forward, because we’d have a common vocabulary that we could refer to.

Meet more often — I firmly believe that we’re at our most productive in Face-to-Face meetings. Meeting every six weeks has allowed us to cover a tremendous amount of ground, but there is still a certain loss of context and productivity between meetings. Although it would undoubtedly be onerous for some (if not most) Participants, having Face-to-Face meetings every, say, four weeks would make us still more productive, increasing both the quality and the timeliness of the deliverable.

Limit new entrants — One of the complications we’ve faced is that several Members have joined the Working Group since we started last September. While I’m not suggesting that people shouldn’t be allowed to join late, getting them up to speed — and potentially rehashing old ground, as well as introducing awkward issues late, when they should have been dealt with much earlier — can be very detrimental to the work.

Perhaps it would help if there were incentives for joining early in the Charter. Arguably, there already are (in the form of the IPR rules, according to Hugo), but more obvious ones might help. I’m not yet sure what they should be, though.

Document an explicit discussion policy — Just as the Charter specifies a decision policy, so should it say how discussion is to take place. E.g., if technical discussion and exploration is strictly regulated in calls, it pushes it to the list, which is often a more appropriate forum. This leaves more time on calls for making decisions and more fruitful technical discussion.

One practical way to do this is to time-limit all discussions, and to require discussions to centre around proposals; if an issue has no proposals, it can’t be discussed. I’ve heard that this is used to great effect in other WGs.

Closing Thoughts

I consider it my job to “embody the Charter” of the Working Group, so that the experiment will be useful; whether it fails or succeeds, I think it’s a useful endeavor. The W3C should be neither a pure R&D endeavor nor just a mill for pumping out standards after they’ve won in the market; there needs to be a balance.