PUBLISHED: January 5th, 2010

This is my position paper for the CETIS – Future of Interoperability Standards Meeting 2010

Development of standards

There is a difference in developing a specification for a small community, and to develop a standard/specification with a global community.
In my view there are several challenges that need to be met and addressed.

In this position paper I will only mention the language challenge, and the possibility to participate in vocal discussions and read and write documents.
To ensure a more equal opportunity to participate, the value of a written process should not be underestimated.

However, another observation I have made in participating in internationals standardisation for some time is the understanding of the process, and what is discussed, and the tools that are used to support and foster the discussion.

In my view one of the bigger challenges in standardisation is to achieve a common understanding of what is discussed, and the level of precision in the discussion, and the actual problem addressed. Since people are participating in the process, and these people have different background and different understanding of the domain, and different understanding understanding of the problem that are addressed. Since we are working with ICT standardisation – level of technological understanding is also a challenge.

To achieve a better process – there is a need to harmonise the progression of standardisations development and to better identify the different stages of a standardisation development, and to agree on what the standard should specify, and what need to be left to the application developer. To support this separation of discussions we should also use different tools to describe and express the different stages. Different tools have different strengths in describing different aspects of a standard.

This is also important so that all participants could start at the same level of understanding, or almost at the same level, and to ensure that everyone will have the same opportunity to participate and contribute to the development of the standard or specification.

This is my proposal of stages that the development process could be separated into in the development of a standard, and where different tools could be used. It is also important that the previous stage is visited before one moves to the next, to ensure that the stages are coherent. It is also important to be pragmatic, and realise that as different stages are passed increased understanding of the problem could lead to changes in earlier stages, it is therefore important to update the result of the earlier stages to reflect this increased understanding.

1) Well defined problem

It is important to have a well defined problem, with scope, boundaries, what’s included and what’s excluded. This is a necessity to have as a starting point for the discussion.

To achieve a well defined problem use-cases and practical examples could be used to better understand the problem, and to identify boundary objects.
If the participants in the development of a standard or specification do not achieve common ground in defining the problem it will be harder to achieve agreement at the other stages.

2) Concepts

When the problem is well defined, the concepts involved and related to the problem need to be identified and expressed. When discussing and expressing concepts it is important the focus is on discussing concepts.

3) Properties

When the concepts are defined it is time to start discussing the properties of the concepts. What are the properties, what should be described as a part of the standard, what should be left to application profiles. Depending of the nature of the problem addressed, the types of properties that are needed would differ, and the number of properties that should be a part of the standard.

4) Datatypes

When the properties are defined, then the type and nature of each property need to be specified.

5) Controlled vocabularies

If any of the datatypes are strings or could consist of a set of variables the discussion should be on the need of a controlled vocabulary or the nature of the possible string values.

Tools

Example of tools for the different levels that could be used:

1. Archimate, text documents
2. cMap tools
3. UML
4. UML / Database Schemas
5. Tables, text documents

If the discussions are separated on more abstract levels, before we are approaching more detailed levels the process of developing standards and reaching consensus would/could be more effective. It is crucial to spend enough time on the abstract levels before we start discussing how the information is to be represented. In my experience progress will be hard if we at the same time are discussing the problem, the concepts of the problem and the properties of the problem, when the discussion is mixed between the levels it is hard to agree and make progress.

The point is not to start a discussion on the suggested levels, but rather raise a discussion on the importance of separation of discussions going on. And that each level should use the tools best designed for that level. We should also have agreement on the more abstract levels, and the problems we are trying to solve before we start working on the details.
Within a group we need consensus at each level before we move on to the next level.

Since development of a standard usually takes some time, it is important that all stages are well documented so that newcomers to the project could read all documents and be up to speed without the need to restart all discussions and pass through all development stages at once. The documentation about the process, and the agreement reached at each level will also benefit the users of the standards, since they could have a better understanding of choices made in the development of the standard.