An Opportunities and Risks Framework For Standards

Future of Interoperability Standards Meeting

I have been invited to participate at the CETIS “Future of Interoperability Standards Meeting 2010” which will be held at the University of Bolton next week.

I have been invited to submit a position papers providing thoughts or opinions on the experience of developing both formal and informal specifications and standards, working with standards bodies and potential ways forward to achieve interoperability.

I would be concerned if the development community simply revisited top-down approaches to the development of standards (“it’s a standard from a mature and well-established standardisation body”) and focussed on the latest fashionable area for standardisation, without acknowledging past failures to live up to expectations.

My position paper, given below, argues that we should be sceptical about the potential of standards and have a more realistic view of the standardisation processes. And just as in other IT development activities the outputs of standardisation activities are liable to fail if there is a lack of engagement with the end users of the standards (typically the development community). An ‘opportunities and risks framework’ is described which is intended for use by organisations considering use of open standards.

Developers Can Be Excited by The ‘Potential’

At the “Universities API” workshop session held at the CETIS 2009 conference I can recall Tony Hirst at one point getting excited at some aspects of use of ‘University’  APIs. “Potentially” I seem to recall Tony saying  “exciting things could happen” – although I forget the specific details of the exciting things (and I am paraphrasing his remarks).

A Need For A Realistic Approach

My colleague Paul Walk responded by repeating the word “potentially” in a tone of voice which suggested that he was rather sceptical of the assumption that making policy decisions based on their potential was a desirable approach to technical developments.

Paul has recently expanded on his thoughts in a blog post entitled “An infrastructure service anti-pattern“. In the post Paul provides a definition:

An anti-pattern is a design approach which seems plausible and attractive but which has been shown, with practice to be non-optimal or even counter-productive. It’s a pattern because it keeps coming up, which means it’s worth recording and documenting as such. It’s anti, because, in practice, it’s best avoided….

Paul illustrates the anti-patent which concerns him in a diagram which highlights aspects of a service “are the product of little more than speculation“.

Paul concludes by arguing that:

“In the end, the investment in creating a user-facing application based on an expectation of future demand which doesn’t materialise is wasted while, at the same time, the investment in providing unused machine interfaces is also wasted.“

Paul’s concerns about wasted investment are of particular relevance at a time when we have heard that the “Hefce budget to be slashed by £915m over three year“: an article published in the Times Higher Education – and dated 31 December (not a Happy New Year for higher education!).

Application To Open Standards

Paul’s post got me thinking about how this argument might be applied in the context of the development, selection and use of open standards.

In the past there has been a tendency for those involved in IT development work (including policy makers, managers and developers) to avoid looking too closely into the standards making process. Indeed. as in a recent post and talk entitled “Standards Are Like Sausages” I cited Charles McCathieNevile “Standards are like sausages … I like sausages – but I’m not keen on exploring too closely how they’re made!”  The sausage analogy, incidentally, seems to have been coined by Otto Bismark is relation to the process of making laws, with Keith Boone (who was a participant in W3C’s standardisation of the DOM) using it in the context of IT standards on his Healthcare Standards blog.

I’ll not go into any details about the problems with the standards-making processes –  read Keith Boone’s post for examples of the difficulties which are encountered in such activities and the reference to “stories of the battles between two of the major players on how DOM2 would go“.

But we can see an example of the time and effort which went into the development of W3C’s XHTML 2 family of specifications which included the XHTML 2 draft which was published way back in 2002 – work which officially ceased at the end of 2009. A key design principle of XHTML 2 was that “it is not intended to be backward compatible with its earlier version” – this standard aimed to start from scratch in the development of a much more robust and elegant language.

But after a period in which W3C was supporting the development of a new XHTML 2 standard and the evolution of the existing HTML family of document markup standards,  the W3C are now supporting the development of HTML 5.  And, as described in the HTML 5 FAQ, this standard will be based on patterns of successful implementation of features: “If browsers don’t widely implement a feature, or if authors don’t use a feature, or if the uses of the feature are inconsequential of fundamentally wrong or damaging, then, after due consideration, features will be removed“.

We seem to be seeing a move away from features in standards which may be potentially useful, to a more evolutionary approach to the standardisation process, in which those aspects which can be demonstrated to have buy-in from the market sector (browser vendors) become standardised.

Difficulties For The Consumers of Open Standards

If the processes for the development of open standards has such flaws it should not be surprising if an uncritical acceptance of open standards can cause problems for the consumers of open standards, such as those involved in IT development work.

As I described in a talk I gave at the CILIP Scotland 2009 conference on ”From eLib to NOF-digi and Beyond“ a number of the open standards (such as SMIL and SVG) which were felt to provide the basis for development work failed to gain acceptance. And might it not be interesting to seek to estimate not the financial benefits of use of open standards but the costs that the sector might have incurred through use of failed standards (might we, for example, have developed a standards-based 3D immersive environment based on the VRML/Web3d standard, isolating the community from the proprietary Second Life environment which became the main player in this space?).

Perhaps in the 1990s and the early part of this century there was a feeling that the high education community could force acceptance of recommended open standards through mandating their use in funding agreements.  But as we have seen in the wider Web 2.0 context, attempting to mandate technologies in this way leaves the sector vulnerable if the user community refuses to buy into the view – there are now multiple providers of solutions so a top-down approach is unlikely to be successful, except perhaps in niche areas.

An Opportunities and Risks Framework

I feel it would be appropriate to make use of an “opportunities and risks” approach to the development, selection of use of open standards. In the past there seems to have been, I feel, a largely uncritical belief in the opportunities which can be provided by open standards (such as platform- and application-independence; freedom to choose from multiple providers of solutions; cost-reduction through this freedom of choice and avoidance of vendor lock-in; interoperability and long term preservation) with little consideration of the risks.

This needs to change, I feel. Based on the ‘opportunities and risks framework‘ developed to support the use of Social Web services I feel we should take a similar risk assessment and management approach to the development of and use of open standards. And since, despite various examples of failures, open standards are regarded in a positive light, I suggest a change in the word order, so that we make use of an “opportunities and risks framework” to support use of open standards.

So using the latest version of the framework (taken from the paper on “Empowering Users and Institutions: A Risks and Opportunities Framework for Exploiting the Social Web“) we might require use of open standards in development work to document:

Intended use: The specific details of the intended uses of a standard should be provided. A recent example of the limited use of RSS (for alerting and not wider syndication) provides a good example of the need to be open about how standards are to be used – especially if third parties may be expected to make use of the outputs.

Perceived benefits: Let’s not use open standards simply because they are open. Rather there’s a need to provide specific details of the expected benefits. And a time when funding is tight, these benefits should be tangible, and not potential benefits.

Perceived risks: A summary of the perceived risks which use of the standards may entail should be documented.

Missed opportunities: A summary of the missed opportunities and benefits which a failure to make use of standards should be documented.

Costs: A summary of the costs and other resource implications of use of the standards should be documented.

Risk minimisation: Once the risks have been identified and discussed approaches to risk minimisation should be documented.

Evidence base: Evidence which back up the assertions made in use of the framework.

Revisiting The Open Standards Philosophy

I have argued the need for a user-centred approach to the use of standards and described a mechanism by which the users (i.e. developers) can help to make the selection of appropriate standards. But what about the relevance of open standards themselves?

At a time in which we have heard that “Universities’ annual funding reduced by £398m” and the JISC “Funding postponement for capital funded calls and ITTs” I feel we need to be prepared to apply a critique of the relevance of a development culture which I’ve seen encapsulated in the slogan “Interoperability through open standards“.

Do we want open standards in their own right or do we want the benefits which open standards aim to provide? And do we want open standards for which there are trusted and neutral standards organisations responsible for the governance and maintenance of the standards – or by open standards do we simply mean that the standard isn’t owned by a commercial company?  RSS, for example (in its several guises) provides an example of a format which is widely used and felt to be of importance to the developer community (see Tony Hirst’s OUseful blog for examples of how a variety of freely available tools can be used to process RSS feeds). But might not even proprietary formats and standards be relevant – after all both Adobe’s PDF format and Microsoft’s Office formats were last year adopted as ISO standards. Might not, in some cases at least, proprietary formats have a valuable role to play in market-testing standards which at a later date may become open standards?