Simon

Sure – working my butt off on it!

The only point on which I do not agree with you here is the analysis that businessmen do not like standards. In truly commercial, consumer markets, standards are much more common than in education.

I think that on the quality side, this comes from government’s need to regulate the red blooded businessmen (or at least the red-blooded businessmen’s desire to head off that regulation). But on the interoperability side, I think it comes from genuine self-interest, a desire to grow the market as well as fight over the cake currently in the oven. So we see data standards commonly produced in e.g. the airline industry to co-ordinate with online booking agencies. In other circumstances, the “standards maker” might be a dominant corporate interest (Microsoft for desktop computers, Apple for mobile apps). Whatever we think of this scenario, at least they knew what they were doing. The trouble in education is that the potential “market builder” are governments, who are (a) parochial in their views, and (b) do not always know what they are doing technically. That problem has been compounded by the Catch22 that comes up in game theory, I think – that people would all be better off if they collaborated on something (in some circumstances at least), but risk being disadvantaged if they try and collaborate and the other guy does not. So, going back to your original phrase, I do also accept that there is a trust issue too.

But enough of the idle chat – better get on with the outreach! Thanks for the conversation.

Crispin.

Though, maybe, my phrase points to the reality of business people being allergic to all standardization, because it does indeed mean a constraint on their freedom. They will, of course, adopt standards only if there is a business case, with a positive “bottom line”.

About scenarios, yes, we broadly agree. InLOC was set up to follow your Route 3, and it was up to the team to try to get as much buy-in along the road. Collectively, we could perhaps have done better, though we did try, and it was hard (for the reasons I have outlined elsewhere). But this is not actually the most attractive route to me (whether or not you count me as an “expert”). Route 3 is more risky and subject to the whims of luck. I hope it will turn out to have been worth the very considerable (extra) effort put in.

We are, of course, still compliant with your norm expressed in your final paragraph — InLOC was specification development; the CWA was simply an acknowledgement by our local standards community that we have done a good job; and we are not pushing for formal standardization before stakeholders turn up at the table.

And I can rely on you to help get those stakeholders to the table, can’t I? …

From my perspective, the problem with InLOC and other like projects is the lack of any implementers or key stakeholders at the table. So my tweet was not casting you as the definer of roles – the roles of standards implementer and standards creator are clear enough already without further definition. It is about pointing out that the nature of standardisation changes very significantly depending on who is doing it to whom.

My observation about InLOC suggests that the main problem with standardisation is a marketing problem – getting the implementers to the table. In my view, your phrase about collective commitment is not helpful because to me it suggests a moral responsibility to come to the table, which I think is (a) unfounded and (b) likely to make any red blooded businessman run a mile.

I agree with you that there are different standardisation scenarios. In the dimension you discuss, I would suggest 3:

1. De facto: a formal process in which existing specifications that have already achieved widespread acceptance are whisked through as-is;

2. Balanced: a negotiated process in which different community specs are aligned, preferably in a conversation which combines the mediation of standards experts, acting as shuttle diplomatists between the different community representatives;

3. Anticipatory: in which the experts create a specification and then try to “sell” it to the communities.

Route 1 may be ideal but give undue influence to sectional or anti-competitive influences. It is not very popular with standards experts, whom it reduces to the role of the Queen at the opening of Parliament, reading out a speech written for her by someone else.

Route 2 encapsulates a substantive process that delivers real benefit and gives the standards experts the opportunity to demonstrate their value.

Route 3 is probably the most attractive to the experts but may again be captured by sectional interests and is very unlikely to succeed unless the “selling” is backed by government regulation and enforcement (in which case you had better be 100% sure that the standard you are imposing is a good one).

I think we would both agree that type 2 is probably best, though in real life, a successful process may share something of all three. I suggest the problem in achieving processes which are predominantly of type 2 is (a) to encourage sufficient pre-standardisation activity and (b) to understand the motivation of the main actors in order to bring them to the full standardisation table.

Understanding that motivation, in my view, is therefore the key requirement, and marketing outreach should be the key activity. Writing the actual specs is like painting your walls – almost trivial when you’ve done the hard work which is to prepare the surfaces.

Maybe that analogy is not great because by the time you come to formal standardisation, most of the specs ought in my view already to have been written in pre-standardisation processes. The different specs are then the pieces on the board. Going back to your phrase, “formulation” should be regarded as belonging primarily to a pre-standardisation stage, “formalisation” is the primary activity conducted during formal standardisation, along with only enough formulation as is required to ensure convergence between existing solutions.

Or to put it another way, we need clear blue (green, brown, azure?) water between specifications development and standardisation – they should be viewed as separate processes. And no formal standardisation process should in my view even be contemplated without strong stakeholder representation at the table.

Crispin.