BOMOS: Elaboration 3.0.1

The BOMOS activities diagram summarises the various activities that can take place in a standardisation community. The Figure below illustrates the outline organisation structure. One key starting point is the division between substantive activities in the implementing organisation and decision making by the governing body.

It is the task of the governing body to commission a (not-for-profit) implementing organisation that is responsible for the majority of the management tasks. The governing body brings together the needs in terms of management expressed by its grassroots and has the mandate on behalf of those grassroot players to reach decisions on issues relating to the standards in question. The governing body and implementing organisation preferably work together with a single contact point at each organisation. The governing body is primarily charged with the task of ‘decision making’. In practice, the governing body meets a couple of times a year, a fact that should not obstruct the desired decision-making process. The governing body must grant the implementing organisation sufficient mandate. In practice we do see certain decisions being submitted to members of the governing body in writing (email) for approval or that the responsibility for specific activities (for example communication) is entrusted to a single member. This makes it easier to hold bilateral discussions between the implementing organisation and the member of the governing body who is responsible and to reach interim decisions (this approach can also serve as an alternative for the single contact point at each organisation).

The essence is that there must be a clear record of which decisions have to be taken at a meeting of the governing body; which can be submitted in writing (email) and which can be taken by a specific member of the governing body, and for which decisions the mandate lies with the implementing organisation. In practice, annual plans are often used for the formulation of the assignment awarded by the governing body to the implementing organisation. On the basis of reports about the annual plan, the implementing organisation is then accountable to the governing body. The annual plan describes the tasks that need to be undertaken; which working groups are in place or need to be established, and what the objectives of the working groups are, etc. The annual plan is approved by the governing body, which effectively makes it the assignment to be awarded to the implementing organisation. The Management and Development Model can be used as a framework within which the tasks in the annual plan are placed. The annual plan also makes it possible to reach agreements on the tasks to be outsourced. The actual development of standards takes place in the working groups which include in their membership actual users of the standards. The working groups are coordinated by the implementing organisation. In many cases, the actual elaborations are drawn up by the implementing organisation on the basis of discussions in the working groups. The product of the working group, a new version of a standard, can be adopted by the governing body and published as a new version. The decision-making process, who (governing body/working group) decides what must be clearly laid down.

Ideally, a distinction is made between the different weights of changes in standards, so that the lightest (least far-reaching) changes can be dealt with by the appropriate working group or implementing organisation itself, and only the most fundamental changes require the involvement of the governing body, up to the level of the governing body decision. A working group that is continuously overruled by the governing body is unworkable.

It is possible to establish an advisory body to support the governing body with solicited and unsolicited advice. The product of a working group in that case will be submitted to the advisory body as a proposal and the advisory body will advise the governing body on the issue. The advisory body should preferably consist of independent and undisputed experts and can be a means of reinforcing independence and expertise. It is essential that these experts be selected on the basis of knowledge and experience and not on the basis of the interests or representation of an organisation; after all, all that is required of them is to provide substantive advice. The representation of interests is already established within the governing body.

Typically, the category-based demarcation of working groups in terms of the content of their work will take place along the following (layered) lines:

• Architecture.
• Processes/services
• Data/information/messages.
• Technical standard/transaction standard.
• Security.

Another common approach to demarcation is based on the problem domain. SETU (Dutch foundation for electronic transactions in the staffing industry) for example worked with two working groups, namely Mediation and Processing. The Mediation working group is responsible for standards from requests for offers through to the placement of a temporary employee, while the scope of the Processing working group involves the standards from placement through to invoicing. In practice, for more complex standards, specific categories of working groups (e.g. ‘data’) will be further subdivided into working groups for each problem domain (e.g. ‘invoicing’), resulting in a combination of the demarcation approaches.

One group that deserves special attention is the suppliers. For non-profit management organisations this is often a tricky issue. Although crucial for the success of a standard (without correct implementation there can be no working standard), suppliers can also have conflicting interests. In principle, suppliers can contribute to the standard as simple participants and fulfil roles in the working groups, right through to participating in the governing body. Practice has for example shown that in many cases software suppliers make very valuable contributions to the working groups, and as such it is highly recommended that suppliers be given access to the working groups. There is often a fear that suppliers will impose too much of a stamp on the standard. One option as indicated in the above figure is a separate supplier group. On the one hand this offers suppliers a platform while on the other hand keeping them out of the working groups and governing body. In this situation, software suppliers are united in a supplier group, which can advise the implementing organisation and consult with the advisory body.

Decision making within the working group can be dependent on the possible participation by suppliers and on the attitude of the suppliers. In practice, the decision on the level of influence will depend on the way in which the community is organised; if the development of the standard is driven by the interests of the software suppliers, they will (want to) exercise a greater influence on ‘their’ standard. If the development is driven by the needs of a (government) user, then this party will (want to) exercise a greater influence.

The figure offers a simplified basic structure from the governing body, implementing organisation and working groups. Alternatively, an advisory body and/or supplier group can be added. In addition to these suggested possibilities, there are numerous other alternatives, both more simple and more complex. Whatever structure you choose, the reports of the various forums should preferably be made public.

Part 1 describes the necesarry roles in the Management and Development Model,and linked to the main activities of BOMOS. We will now look in more detail in the opposite direction. Starting with the roles, the table below identifies the BOMOS activities in which they are involved; this also demonstrates that a 1-on-1 connection between role and activity cannot work.

For the way in which management tasks are developed in an organisation structure, there are a number of different possibilities ranging from entrusting them to a standardisation organisation through to fully developing the structure within your own organisation. Creating and managing your own development organisation for every standard is not a goal in and of itself. Practice shows that few existing organisations are equipped to fulfil the complete package of tasks so that many standardisation communities have in fact decided to create their own organisation. A number of the tasks are then entrusted to their own organisation, but a number of other tasks can be entrusted to other types of organisations. The figure below lists other standardisation organisations, research organisations and sectoral organisations.

The model makes a distinction between not-for-profit and profit-making organisations. This distinction is relevant in the framework of openness (see section openess). If the management of a standard is entrusted to a profit-making organisation, then by definition that open standard cannot be open! This does not mean that commercial organisations are unable to develop open standards on behalf of a governing body (organisation) or donate their standard to a not-for-profit management organisation after it has been developed. The development and management of standards need not always take place on a not-for-profit basis although a not-for-profit organisation is the most obvious choice.

The first most obvious possibility is to entrust the management tasks to formal standardisation organisations. The world of standardisation has changed compared with thirty years ago when the majority of standards were developed by these formal organisations. In the modern era, the majority of standards are developed outside the formal standardisation organisations in various forms of consortia, and the number continues to grow. We are also seeing increasingly complex collaborative ventures between standardisation organisations. This is very much the case for semantic standards. Partly this relates to the slowness of the processes within formal standardisation organisations, but mainly it is due to the lack of substantive knowledge and expertise. After all, domain knowledge is essential for semantic standards.

This does not mean that formal standardisation organisations have no value; the opposite is indeed the case. In a number of areas, in potential they have massive added value. For example for raising the status of the standard. The NEN3610 standard, for example, was developed by Geonovum, but to give it additional status was also published as an NEN standard. Another task that can excellently be entrusted externally is secretarial support for working groups.

Nevertheless, substantive knowledge will always have to be organised internally. Research organisations such as universities and institutes are other options to whom tasks can be entrusted. The benefit is the wealth of substantive knowledge, but there is also a risk of lack of domain knowledge or knowledge of specific use. The opposite is the case for sectoral organisations; the advantage here is the excellent domain knowledge but the downside is a lack of substantive standardisation/ICT knowledge. In many cases (semantic) standards are a bridge too far for sectoral organisations. The subject is quickly rejected as being only for boffins, which essentially is not the case; specifically for semantics, domain knowledge is of vital importance.

One option is to create your own organisation, or to call in commercial service providers. This second option flies in the face of government principles. Creating your own organisation is the most often chosen option for the core task of developing management tasks. Many domains now have their own organisations that have knowledge of both the domain and standardisation, for example Geonovum, EduStandaard, CROW, Informatiehuis Water, SETU, etc. The heart of their work involves strategic management activities as identified in the model and to a considerable extent also tactical and operational activities. In this situation, certain activities can be easily and sometimes better outsourced.

A number of suggestions: Module development; Module development is a risky business if you undertake it within the development and management organisation. Selecting this option makes you also a supplier and competitor to parties in the community. It is better to encourage module development outside the development and management organisation, possibly in the form of open source software. This decision can also encourage other suppliers to support the standard and/or become involved in its development. The best approach depends on the characteristics of the community.

Certification; The independence of the certifying body is essential to certification. Standard practice is for the development and management organisation to draw up the assessment framework, before outsourcing the actual assessment process (based on the assessment framework) to external parties specifically specialised in assessment and certification.

Architecture/Roadmapping/Benchmarking; Support and implementation of these aspects are ideal for a research organisation in the broadest sense (in addition to knowledge institutions, also such organisations as Statistics Netherlands (CBS) for benchmarking). In particular when it comes to benchmarking, it is better to entrust this task to an external organisation.

Communication; Often appropriate for a sectoral organisation that has already established a communication structure. It goes without saying that there must also be a sectoral organisation that ties in seamlessly with the standard and that is willing to include communication as a core task. Communication regarding the management and development process for a standard demands specific knowledge of that management and serves a specific target group such as software suppliers. This fact must be recognised by a sectoral organisation. Other options are communication departments of other partner organisations.

At primary level, therefore, we can conclude that the choice is to entrust the development and management tasks to:

1. Existing organisations.
2. New organisations.
3. A combination of both.

Entrusting all tasks to an organisation may sound the ideal situation, but there is no single organisation equipped to independently fulfil the complete package of tasks. Even organisations like NEN, Standardisation Forum, etc. are not equipped for this role.

In practice this often means it is necessary to create a new organisation if there is not yet any organisation in place that focuses on standardisation within the domain. Option 3, the combination of the two means that certain tasks can be taken up by this (new) specific domain standardisation organisation while other tasks can be dealt with by other types of organisations as described in this section on the outsourcing of tasks.

Whether just a selection of the tasks or all tasks are to be undertaken by the new organisation, the new organisation must in all circumstances be established, according to a legal form. There are many different legal forms for organisations in the Netherlands. The openness of the standard is an absolutely essential operating principle. The definition of openness specifies that the (decision making of the) standard must be entrusted to a not-for-profit organisation. This automatically excludes a large proportion of the possible organisation forms, leaving only a few viable options, namely:

1. Foundation.
2. Association.
3. Government organisation (as collective term).

The foundation: A foundation is a legal entity established by notarial deed by one or more natural persons or legal entities. As a rule, its governing board has a chair, a secretary and a treasurer. The governing board is the only compulsory body within a foundation. There can also be a supervisory board that supervises the board of the foundation. Unlike an association, a foundation has no members. A foundation can have donors, but they have no say in the operation of the foundation. A foundation can also have volunteers.

The association: An association is a legal entity under Dutch law. An association is generally established by a civil-law notary who executes the appropriate deed. This is not necessary, but without the civil-law notary, the association has limited legal authority (the directors are jointly and severally liable). If an association is established by notarial deed, it must also have articles. These at least state the objective of the association, the obligations of the members, the convocation of the general meeting (of members) and the appointment/dismissal of the directors. As association has an objective that is aimed for. This objective may not be the distribution of profit among the members. This does not mean that no profit may be made, but any profit generated must be allocated to a specific purpose (such as the objective of the association, knowledge sharing, quality improvement, charitable acts, etc.). An association has members. These are people who are members of the association because they support the objective. Generally the members pay a contribution to keep the association running. Members can influence the policy of the association via a general meeting (of members) (AGM). Meetings of this kind are held at least once a year, and every member is invited and has voting rights. The AGM has all authorities not laid down by law or the articles, and as such is the highest body within the association.

The government organisation: Because of the possible variety of government organisations, a brief discussion is not possible. A government organisation could be deployed in one of several ways: a single government organisation as a management organisation for all standards related to government, or a single government organisation for each individual standard. Alternatively, a single government organisation could take responsibility for implementing the management tasks, but equally multiple government organisations could join forces. For example as an association. The choice of legal form must be taken with due care, also taking account of such issues as the simplicity of the establishment process. For foundations, one possible stumbling block is that it is difficult for government parties to take part in a foundation, and that a foundation is not permitted to have any members. With an association, a key issue is the considerable power wielded by the AGM. It is simple for a foundation or an association to demonstrate openness. For both the foundation and the association, the articles are essential; effectively, they regulate the mandate of the roles in the organisation.

Although a foundation is not permitted to have members, at HL7, the term members is used although in strict formal situations the term associates is used. SETU has no members but participants. A collaborative venture without legal form can work well in practice for management, but for more practical issues can be a disadvantage because the collaborative venture as such has no authority to enter into agreements; in that situation, one of the partners will always be required to enter into the agreement in question. Possible disadvantages of this construction are the loss of identity; being bound by the rules and restrictions of the partner; less effectiveness, etc. The advantage of this form of organisation is that it is easily established and terminated, without legal consequences. The organisation structure can to a certain degree reduce or at least make explicit the non-committal nature. The non-committal nature of the participants in terms of standards is certainly a serious point for attention in the framework of a permanently applied standard.

Developing a substantive vision on the direction for the standard in the context: The spot on the horizon for the long term. A compact translation for example into a fact sheet on this vision can also be extremely valuable in communication regarding the standard and promoting adoption of the standard. There must also be specific attention for innovation; many organisation use specific tools for this purpose, such as a radar or specifically a tech radar in which innovative developments are plotted on a radar screen based on time and impact. Tools of this kind are also applicable in this case. The vision for a standard is in essence no different from the vision for a business/product, etc. Hence the decision by BOMOS to not provide a specific structure for standards. The further detailing of the innovation subjects referred to in the vision will often take place at tactical level, for example as an element of the Architecture.

Although few figures are available, sufficient economic research has been conducted into the advantages and disadvantages of standardisation. The table below provides a summary based on Blind, K. (2004). The economics of standards; theory, evidence, policy):

The following are particularly relevant for (semantic) domain standards:

• Positive network effects (the value rises with the number of users).
• Preventing vendor lock-ins.
• Increased variety of products and services.
• Economies of scale.
• Lower transaction costs.

It is nevertheless possible to examine the potential cost items and revenue for the management of standards. These are summarised in the balance sheet below.

The previous section created a picture of potential revenue. The choice of which sources of revenue should be tapped into depends on the situation, but this section attempts to offer support in making the right choices for suitable sources of revenue.

The suitability of a type of revenue is broadly determined by:

• Maintaining a balance between costs and revenue.
• Openness and transparency.
• Sufficient broad-based support.

In other words, sources of revenue that enjoy no support, are not transparent and make the management organisation profitable are not suitable.

To determine suitable sources of revenue, a distinction must be made between different situations:

1. Distinction between development and management.
2. Degree of maturity: distinction between a proven standard and a standard in the early stages of its lifecycle.

We also operate three critical principles:

• Tying in with an open standard (accessible).
• Not hindering adoption.
• Payment should be made where the benefit is enjoyed.

Based on these principles, licences have a dubious status because of the way that they restrict openness but above all because they tend to hinder adoption. The same applies to paying for the specification document and paying for the use of the standard. Given the desire for openness, this is not viewed as a potential source of revenue for an open standard.

2.2.3.2 Re 2. Degree of maturity

Once a standard reaches a high degree of maturity, characterised by broad adoption of the standard, service provision by the management organisation is another potential source of income. For example various forms of service provision:

• certification
• training
• implementation support

Certification can be employed in several different ways, also as a means of generating financial revenue. In the framework of training, for example, possibilities include offering training days through to complete courses about the standard. The margin on the course can be a source of income, certainly if combined with certificates (making completion of the training compulsory for the certificate). Finally, implementation support is a tool possibly used in a more modest form by providing paid advice on correct use of the standard right through to providing complete implementation processes. This in turn makes the management organisation a market party, and that too has negative aspects.

In summary, service provision will be a source of income that as the standard becomes more mature will offer more opportunities for generating income. A source of income that does not occur commonly but which should not be excluded in the future is the donation. Above all structural donations are an attractive form of funding. This results in the following model:

It should be remembered that the costs of managing a standard also change over time. Certain cost items can change considerably. Today we se such items as tactical management rising steadily, above all due to the relationships between the numerous (international) standards that require harmonisation. If a standard is successfully adopted, another item like implementation support can also rise considerably.

The question has of course also arisen whether there are not cheaper ways of developing and managing standards. This is not easy because standardisation initiatives, in particular in respect of industrial standardisation, have the following characteristics:

• Minimum cost orientation.
• A hobby-like character in the positive sense of the word.

In other words, budgets are not well padded, and standardisation organisations need to make choices about what can and cannot be implemented within the budget. One relevant question is how wise the minimum cost orientation is in relation of the quality of the standard and the adoption of the standard.

Developing a complex standard can cost millions; the primary costs are not charged to the development of the management organisation, but the individual participants such as:

• The hours of the experts (volunteers).
• Travel and meeting costs.
• Membership fees and costs for the purchase of other standards.

It is possible to achieve more efficiency in the lead time to the standardisation process. Time is money and the development process for standards is often extremely time consuming. Any time saving in the development process could save considerable costs. Take for example the pressure cooker in the waste industry, where the foundation for the standards was laid in a week.

The different standardisation organisations in each sector also have a tendency to want to reinvent the wheel, mainly out of ignorance, and that too leads to inefficiency. For example the development and management process can probably be copied from one standard to another, rather than reinventing them. At the same time, the core of any validation service is the same for every XML (or JSON) based standard; nevertheless, many management organisations continue to build their own validation service. It can be argued in general that by using online tools, the deployment of volunteers can be made more efficient. The table below provides a summary of a number of suggestions for making the standardisation process more efficient:

Savings achieved through innovative approaches to the development process can also be a pitfall. Face-to-face meetings are a large cost item. Savings on this particular item can often be achieved via online options such as online videoconferencing, forums, mailing lists, etc. In particular, the open source community believes that face-to-face meetings have become surplus to requirement and that asynchronous communication should be sufficient, also to allow worldwide operation, in all time zones. However, developing open source software is not the same thing as open standard development. In other words, using the same process represents a pitfall. Standards often involve complex material and functionality, in which mutual understanding and trust are of key importance. Direct face-to-face communication is essential. During the COVID pandemic, online developments advanced rapidly and became accepted; it is of course sensible to benefit from these changes. Efficiency means ensuring the correct balance between face-to-face and online meetings, and use of other online tools for communication and dealing with technical issues. In other words, innovative development approaches such as the pressure cooker about the Web can generate savings, but will never replace costly face-to-face meetings.

The business case for standardisation is a commonly discussed issue. Before the decision to invest is taken, an understanding of the business case must be gained. In reality it involves a number of different business cases:

1. The business case for the standard (or the chain)
2. The business case of the individual organisation to implement the standard.
3. The business case of the new version of a standard.

The first business case is interesting for government for harmonising policy relating to standardisation. It is often part of the policy relating to a broader social or economic issues. This business case is of course also relevant for the standardisation organisation but it is beyond the capability of most individual organisations. The individual organisations need a different business case, specifically for their role in the chain.

Quantitative studies into the business case of standardisation are difficult to conduct and do not always generate valuable insights. Nevertheless, qualitative research can be relevant and can be successfully implemented. Merely understanding which part can enjoy the benefits and identifying the organisations for which there are no benefits is valuable. It is also meaningful to know which parties can enjoy relatively more benefits than other parties, even if they have the same role. For example the market leader can enjoy fewer benefits compared to the runner up, in the same way that an organisation that has a modern back office may enjoy more benefits. Based on these insights, the behaviour of the participants in the working group can potentially be explained. The quantitative business case is difficult because standards are not an end but a means of achieving the end, namely interoperability. The business case is then in fact a case for interoperability. In line with this understanding, there are often few projects in practice which have the objective of implementing a standard; instead the aim of these projects is to realise interoperability for example for purchasing. This means that the business case for the project is broader than for the standard. For example we regularly see projects that switch from a paper exchange to a standardised digital exchange in which process optimalisation will also be carried out. As such, the standard becomes an essential element of a far larger project. It is difficult to specify which revenue and costs can be attributed to the standard within the larger project. There are also quallitative benefits, which then need to be expressed in terms of quantity.

Business case type 3 deserves particular attention: Replacement standard/ new version. The fact of being a replacement or new version makes it relatively simple to draw up the business case, but it cannot be made positive, in practice. For example, the business case for e-invoicing: If an organisation already uses UBL or SETU for e-invoicing, it is difficult if not impossible to make the business case for a new standard (UN/CEFACT Cross Industry Invoice) positive. For that reason, old standards will still continue to be used for a long time (for example EDI), because there is no positive business case for the new/different standard, as long as there is no interoperability problem. One of the world’s most successful standards, RosettaNet, illustrates this fact: despite the fact that an XML version of this standard was developed years ago, there is almost no migration from the old EDI version, and adoption of the XML version has remained low, for a long time.

Despite the difficulties outlined above and the various attempts already made, we will still attempt to sketch out an approach that can offer insight into the business case. The approach described in this section has been used to draw up a business case for a semantic standard in the jewellery sector. Step-by-step plan:

1. Describe current situations and future scenarios and identify stakeholders.
2. Determine the costs and benefits in the chain based on the framework.
3. Allocate the costs and benefits to the various stakeholders (Attempt to quantify the costs and benefits for each stakeholder).

The first three steps are explained:

2.2.6.1 Step 1 - Describe current situations and future scenarios and identify stakeholders.

The first step starts with analysing stakeholders; what parties have a relationship with the interoperability problem for which a standard could offer a solution. To identify the stakeholders, the NEN stakeholder analysis can be used (zie sectie Werkgroep en stakeholders).

The next step is to analyse the current situation; what are the starting positions from which the primary stakeholders must set off? It is also important to develop a picture of the future scenario with the standard, so that the migration paths from the current situation to the future scenario are clear.

This is demonstrated in the figure for the primary stakeholder, the jeweller, in this example. Of course the intention of the implementation is to ensure that as many parties as possible arrive at future scenario 1 or 2, and start to use the standard.

2.2.6.2 Step 2 - Determine the costs and benefits in the chain based on the framework.

In step 2, a cost-benefit model is drawn up. In generic terms, what are the one-off investments, the operating costs and the benefits in relation to the standard? For many standards they will be relatively equal. This makes it possible to start with the model from the jewellery sector, in which the necessary adjustments can be made. The model for the jewellery sector is reproduced below.

Ken Krechmer developed a model that clearly describes the elements of openness and that allows him to compare standardisation organisations. In the model, he distinguishes between the various aspects of openness (requirements) and the different points of view for standards. For his points of view/roles, he has selected the developer of the standard, the implementer of the standard in a product and the user of the standard (product in which the standard is embedded). Not all aspects of openness are equally relevant for each role, as shown by the model:

For the management organisation, these 10 criteria for open standards have the following meaning:

1. Open Meeting means that everyone is permitted to participate in the standardisation process. No stakeholders are excluded. It is also important that it is possible to participate on a per-meeting basis, at low cost. This means that it is also possible for students or for SME enterprises to join in. Meetings must be clearly announced and there must be as few barriers as possible for stakeholders, to participate. A development and management organisation must be careful with stakeholders wishing to participate. In many cases, it is no easy task to identify sufficient stakeholders who wish to participate actively. In other words, rather than obstacles, it is important to provide incentives. The pitfall is to only open up meetings to a restricted and specified group of (paying) stakeholders.

2. Consensus refers to decision making within the organisation. Is there a (group of) organisation(s) that dominate? In principle, all participants should be given equal rights and contribute equally. The pitfall is to have a dominant group (for example the governing body/parties who make major financial contributions) who have full control.

3. Due Process refers to the processes that describe how voting rounds are organised and the processes for requests to reconsider decisions (appeals processes). There must be procedures for complaints and those procedures must be clear. The same applies to procedures for decision making, in particular the process for resolving potential stalemates. The pitfall is failing to organise these aspects.

4. One World refers to the ideal situation in which a single standard is used throughout the world for the same objective, also with a view to avoiding trade barriers. Naturally this does not mean that it is not possible to introduce a new standard for a specific purpose or context. It does however mean that no regional or national standard needs to be created if a worldwide standard is sufficient. In general terms, One World also means that the standardisation organisation does not compartmentalise, with a single standard developed without knowledge of other standards/initiatives. The pitfall for the standardisation organisation is to become blinkered, focusing exclusively on its own standard while other good standards are already available, possibly semi-finished. What open means here is open in relation to other standardisation organisations so as to avoid developing overlapping but related issues. Another pitfall is selecting a scope that is too limited for the standard to be developed or managed; for example national rather than worldwide.

5. Open IPR (intellectual property rights) is the aspect that has been the source of most discussion, in which ‘royalty free’ and ‘irrevocable’ have become the buzzwords for the definition of open. For a long time, standardisation organisations and suppliers have attempted to include the term RAND (Reasonable and Non-Discriminatory) in the definition of openness. It is for this reason that these standardisation organisations do not satisfy the definition of open on this aspect, which means that many standards that are perceived as being open are not in fact open on this point, according to the definition. The definition of an open standard leaves no point unclear, and prevents discussion about the meaning of RAND, for example what is reasonable? This has been the source of much discussion. The standard should be royalty free and irrevocably available. The pitfall is failing to arrive at this situation, which is often the case for semantic standardisation organisations. The intentions are good (open), but by failing to explicitly regulate, it can lead to problems in the future. Furthermore, in many cases, there are no regulations regarding the rights of the contribution made by ‘volunteers’ from external parties to the standard working groups. This is a potential risk for the sustainability of the standard.

6. Open Change: If a supplier is only required to make the standard openly available, but is free at any time to implement changes, the benefits of standards will never be achieved and the supplier retains its position of power. An open method of implementing changes to the standard is of vital importance, but to date has received little attention. Standardisation organisations that fail to comply with the open meeting, consensus and due process requirements are by definition unable to comply with the open change requirement. An open structure can be achieved by describing change processes in which no single party enjoys a special status in decision making. The pitfall is failing to structure the process of change in an open manner, often because there is no attention for this issue.

7. Open Documents means that all documents must be openly available. This does not just mean the standards themselves, but also that work in progress must be made available, together with minutes of meetings, etc. This enables users of the standard to understand the complete background. The pitfall is to only make the standards themselves openly available.

8. Open Interface is above all relevant for technical standards, and relates to leaving space for suppliers for closed extensions, as well as leaving space for backwards and forwards compatibility. The pitfall is failing to address backwards compatibility and not leaving space for temporary extensions (forwards compatibility).

9. Open Access: End users often take at face value the fact that their supplier(s) has/have correctly implemented the standards. To achieve ‘Open Access’, it must be possible to test the implementation of the standard (for conformity); this can be achieved using conformity testing (test protocols) right through to official certification. Another possibility consists of so-called plugfests in which the interoperability between the different implementations of a standard are revealed. The pitfall here is that postponement will lead to cancellation. To make open access meaningful, the standards must achieve a certain degree of maturity. Which is why implementation is often postponed. And postponement in turn leads to complete cancellation. An open structure also means being open about the use of the standard in implementations, for example by publishing implementation overviews.

10. Ongoing Support refers to the support provided to the standard throughout its lifecycle. The pitfall is to stop providing support as the interest from suppliers wanes. An open structure at the very least means that the lifecycle of the standard is described, according to which users can derive a guarantee about the support for the standard. In the ideal world, support should only end when there is no longer any interest in the standard among end users.

Many discussions about openness today consider just two aspects of openness, namely ‘One World’ and above all ‘Open IPR’. As a consequence, the other aspects often remain underexposed. When it comes to achieving a maximally open standardisation organisation, every little helps. To date there is not a single organisation that is known to be fully open on every point. Complete openness on all these points is a utopian idea, but each point is worthy of attention and can support the thinking process in achieving greater openness in standardisation. It is also worth realising that in many cases, formal standardisation organisations fail to (or only partially) comply with aspects 6-10.

Based on the above, we can offer a number of specific tips: Make decision making open by:

• Publishing the minutes of the various forums.
• Consensus decision making
• Not excluding any parties at meetings.
• Producing a website on which all documents (including drafts) are made available free of charge.
• A clear change procedure.
• Making the standards testable based on test procedures, validation, certification and/or plugfests.
• Organising structural financing.
• Focusing full attention on the relationship with other standards in the environment.
• Explicitly laying down the rights; the intellectual property rights to the standards, copyrights to documents, the contribution by individuals in working groups and in the establishment of the standards. Documenting version management: how to deal with backwards and forwards compatibility and how to record support on the basis of the lifecycle of a standard.
• Recording the development and management aspects in a document.

Krechmer’s model is an ideal starting point but in order to offer more practical tips, it can be added to. We have therefore further elaborated the criteria into variables for each criterion. These variables can be better related to the situation in practice. Eventually, scores can then be allocated for each variable; this in turn makes it possible to compare openness between standards. In theory, it should then be possible to define a minimum score for a standard to be described as open. However, this does no justice to the fact that certain variables are more important than others.

The model on the next page is based on the 10 criteria identified by Krechmer, and is a tool for implementing management activities in an open manner.

The Standardisation Forum assesses standards among others for openness for inclusion on the apply or explain list. Krechmer’s criteria are also included in this broader assessment. The model presented here is a more in-depth assessment, intended as a guideline for designing for openness, and not to be used in the formal process for inclusion on the apply or explain list. For more information about the assessment criteria, visit the website of Forum Standaardisatie.

Part of the activity diagram is module development. This refers to the ability of the organisation to (commission the) development of software in which the standard is implemented. It is dangerous for a standardisation organisation to do this itself on a ‘commercial’ basis, because this would make the standardisation organisation a competitor for other suppliers on the market. This would rapidly reduce support for the standard by other suppliers. This risk can partly be obviated by using open source for the development. The open source module in which the standard is processed is made freely available which allows commercial suppliers to continue with the process so that in the long term, the standardisation organisation itself can withdraw from the development process, entirely. As such, it is above all a means (incentive) to get the market moving.

Furthermore, Open Source Software is an excellent alternative for closed source software. The primary difference lies in the business model. If a standard is to be adopted, it is important that the standard be implemented in all software, irrespective of the business model. From the point of view of adoption, to give a specific type of supplier preferential treatment represents a certain risk, since it will create resistance among other suppliers.

Open Source Software should never be confused with open standards. They are fundamentally different concepts according to which, from the point of interoperability, only open standards are essential.

Compared with other standards, semantic standards are incredibly complex and are developed and managed in a different way. The majority of IT standards are already developed outside the official standardisation organisations (such as ISO and NEN), in so-called industrial consortia such as W3C and OASIS. However, when we look at semantic standards, we must go a step further, because for the most part these are developed internally within the own organisation.

Practice shows that distinguishing only between horizontal and vertical standards is too restrictive. International vertical standards often also require a specific structure, for example in the context of a country (such as the Netherlands) in order for them to tie in perfectly with the business processes in that context. This is vital to achieve interoperability. As a result, standards, also referred to as agreements or application profiles, are created at national level, that contain a further implementation of an international standard. In addition, specific code lists for the national context are often added. This results in the following classification:

• International horizontal standard
• International vertical standard
• National standard/application profile/agreement/taxonomy
• National vocabularies, code lists, etc.

This is also reflected in the organisations: HL7 is the international standard, but there is also an HL7 Netherlands. For international HR Open Standards, it is SETU that produces the Dutch HR Open Standards profiles.

Whatever their form, be they an international horizontal standard or a national code list, they all have to be developed and managed! This does not however mean that all four classifications must be present in a specific application domain. In practice, depending on the situation, any combination may occur.

During the adoption phase, one commonly heard comment is that people only wish to adopt the international standard, as opposed to a national version. Based on the argument that they do business worldwide, or that the international standard ties in more broadly or is more widely known. However, in practice this will result in restricted interoperability, because the international standard will tie in less successfully, and in many cases will feature too many degrees of freedom. Given that interoperability is the objective of standards, this is not a wise choice. Instead, it would be wiser to focus on the national standard that ensures tying in with international standards and guarantees optimum application in the Dutch context.

It is also useful in the management phase of a standard to continue to focus attention on international standards. If no appropriate international standard is available during the adoption phase, a national standard may be the only option. But that situation can change. One example is the Digikoppeling (Digilink) standard. Digikoppeling comprises an interface specification which serves the same purpose and application as the European eDelivery, which was adopted later. In the framework of standards management, the decision could be taken to phase out the national standard in favour of a more recent international standard. Here, too, a national profile on the international standard could be valuable. It does however mean a different role for the management organisation. If necessary, the management organisation will represent Dutch stakeholders in managing the international standard.

One vital point for attention in relation to international standards is that in the case of an international vertical standard combined with a national application profile, for example, a different name must be applied to each, in order to avoid confusion in practice.

Finally, even within the standards themselves, stratification can occur in different ways. For example between vertical and sector models and horizontal standards, in addition to which other (e.g. technical) standards are often combined to offer a total solution for interoperability.

The sector-specific approach to semantic standards raises the fear of compartmentalisation between sectors. The question of cross-sectoral interoperability is not solved and may even be exacerbated. The potential problem is widely recognised and solutions have been conceived, but to date they all collapse with very low adoption and lack of grassroots support. There are two possible causes:

1. The problem of cross-sector interoperability is not yet seen as urgent given the greater challenges present within the sector.
2. The proposed technical solutions are often extremely complex. One technically attractive solution for example is the UN-CEFACT Core Components standard. Although more than ten years old, this standard has never enjoyed broad adoption. The core of the solution is probably not a technical one, but lies with the management organisations active in the various domains. They all have to adopt a less fragmented approach and work better together with their fellow management organisations from related sectors. There have been improvements in this respect in the past few years. In part this is due to ‘open’ thinking because in a one world (see section about openess) there are no competitive standards and the standards match perfectly together.

The previous sections are clear indications that in most cases semantic standards are stratified and as such build on or make use of other standards. One interesting problem that is generic to the development of standards, but that becomes abundantly clear in the pressure cooker, is interaction with formal (e.g. ISO, CEN, NEN) standards. The basic underlying principle is that as far as possible, existing standards should be reused, rather than constantly reinventing the wheel.

There are a number of sore points when it comes to formal standards:

The inability to access the formal standards: In the pressure cooker session, it was suggested on a number of occasions that an existing formal standard could already contain a (partial) solution. However, no one knows for sure, because no one has been able to access the standard because of the related costs. Even if those costs can be limited, the threshold remains high. At the end of the day, the supervisor still had to purchase the standard, only to discover, sometimes after just three minutes, that the standard was unusable. This situation is a clear obstacle to rapid progress (in the pressure cooker). In practice, it is clear that even a ‘free registration’ (for example at Geonovum and SETU) is perceived as a too high threshold.

The costs during the development of standards: Broadly speaking, the costs for buying a formal standard (specification document) are around 100 euro per standard. A relatively small amount when it comes to developing a new standard. Nothing more than a shame if it becomes clear immediately following the purchase that the standard is not relevant. The greater problem lies in numbers; it is almost never the case that only a single standard has to be purchased. In the case of the pressure cooker for the waste sector, in addition to purchasing a DIN standard, NEN and ISO standards also had to be purchased, and the ISO standard was made up of four parts, each of which had to be purchased individually. The outcome was higher costs and higher levels of frustration about the hassle involved. That hassle often also relates to the purchasing process within an organisation. Very quickly a sense of let’s not bother, it’s probably useless anyway will emerge.

Since NEN working groups have unlimited access to the standards, this problem can be obviated by establishing the working group/pressure cooker under the auspices of the NEN. However, establishing an NEN-based working group also costs money.

Reuse: Formal standards are extremely valuable. Also in the pressure cooker for the waste sector, existing formal standards contain sufficient valuable information to avoid the need to completely reinvent the wheel. The issue that then rises is the lack of clarity about how the formal standards permit reuse. There are two options:

• Reference to the formal standard, but this results in costs for implementations (see below).
• Adopt a section from the formal standard.

The second option is particularly useful if the formal standard has a far broader application (or applies to a different domain) but with choices that are also perfectly applicable to ‘our’ standard. It does however raise questions about the openness of the end result. The rule of thumb at the NEN is that 10% may be copied, following consultation with the NEN. Permission must be sought from the NEN to allow them to check that no patents based on the formal standards are infringed.

The costs for the implementation: If reference is made to an existing formal standard, every supplier wishing to implement this standard will be required to purchase the formal standard in question. Even if their own standard is open and freely available, by referring to an existing standard, we unavoidably create an obstacle to adoption with the potential risk that the standard will be incorrectly implemented because the decision is taken during implementation to not purchase the formal standard. In other words, all implementing parties are saddled with costs thereby creating an obstacle to adoption and interoperability, which was never intended.

If we wish to use an international standard in a national, sector-specific context, we automatically create an important dependency. Depending on the context and the strategy chosen, the relationship between the national and the international standard can be implemented in different ways. Ideally, the international standard is fully adopted, but as we know from practical experience, an international standard can almost never be simply copied, one on one; in some cases the changes are limited; just a small number of extra issues have to be added for the specific national context in order to achieve interoperability.

The following situations can arise:

• The specific context requires extensions/adaptations to the standard.
• The standard includes numerous extraction issues which result in additional complexity not necessary for the specific context.
• Mistakes are found in the international standard.
• Items are missing from the standard that are not specific to the context.
• There is a need for a new standard.

Generally speaking, in these situations, the following activities can be undertaken:

• Make adaptations to the international standard (without returning the adaptations to the international standard) (Adaptations)
• Implement permitted extensions to the standard (Extensions)
• Remove items from the standard (Omissions)
• Temporarily adapt the standard (we make the necessary adaptations to the international standard, but only need a solution that is temporary, until the international standard is adapted) Temporary Adaptations)

The strategies:

In particular if the intention is to achieve international interoperability, the best solution is as far as possible to remain in line with the international standards and to select a strategy on the right-hand side of the figure, if possible compliant profiling. However, this requires harmonisation with the international standard, which involves costs for example due to attending the international standardisation meetings. If your aim is to achieve interoperability in an international context this is essential.

Linked Data has already come a long way, to the situation in which it has become the de facto standard for semantic modelling. The standards and technologies covered by Linked Data -- such as RDF, SPARQL en OWL -- are becoming increasingly widely used in practice. It started in the academic world but over the past few years has spread into both the public and the private sector.

Linked Data results in changes to the sematic standardisation discipline described by BOMOS. It is not merely a question of using new technologies and tools. Linked Data means a different approach to semantic interoperability: the emphasis is shifted from standardisation of messages (or ‘transactions’) to the standardisation of the underlying domain description; the language. The language in a domain is standardised using vocabularies and ontologies but it also becomes possible to create links between domain ontologies in such a way that Linked Data can break down the barriers between sectors, until it becomes a tool for cross-domain interoperability. In addition, Linked Data standards satisfy the open standards criteria, and a number have already been included in the apply or explain list published by the Dutch government.

Many standardisation organisations are looking for opportunities to encourage the use of their standard. This can be achieved in several different ways. The related strategy is referred to as an adoption strategy.

Working groups at the Standardisation Forum have identified a number of critical success factors that played a role in the adoption of various standards:

1. The standard must be mature; otherwise no one will be willing to invest.
2. Patience: Adoption of a standard takes time, sometimes several years.
3. The benefits must be clear to everyone, in the business process, in society and financially; there is support.
4. There must be a dedicated problem owner, specifically because adoption takes years; true commitment is essential.
5. There must be a critical mass of users.
6. A leading party or a leading process can massively encourage adoption.
7. There must be an active community involved in the development and use of the standard.
8. There must be funding for support, training, remuneration, etc.
9. Use a good mix of adoption tools.

Selecting the ideal strategy for promoting the adoption of a standard is no easy task. Sometimes there is no need for such a strategy, because the standard is fully ‘supported’ by parties in the field. However, in many cases, a standard is part of a broader development. For example a standard for the digitalisation of a chain. The introduction of the standard relates to the question of whether an organisation intends to start the process of digitalisation.

The tools for adoption can be divided into three groups:

• Financial: the ‘carrot’ that encourages adoption by facilitating use of the standard. Examples of the tools available include offering a grant or supplying implementation instruments that reduce the costs of implementation.
• Communication: the ‘sermon’ supplying information about the benefits offered by the standard to the organisations. For example by writing articles or organising seminars.
• Legal: the ‘stick’ making use of the standard compulsory. For example by including the standard on the list of open standards for ‘apply or explain’ as produced by the Standardisation Forum.

In most cases there is no single ideal strategy. The choice will depend on the existing and desired situation and numerous environmental factors. Adoption tools can for example differ in terms of or depend on:

• the choice of the primary target groups to be appealed to: all users, specific users, software suppliers.
• the tools employed: seduction, contracts, legislation, commercial compulsion
• the approach: start small or start big right from the start; first a small group, or the whole target group right from the beginning; first a small part of the standard, followed by more, later.
• the existing situation in the target group: Is data exchange already common practice? Are older or other standards already in use?
• the dominant benefits offered by the standard or the dominant problem for which standards offer a solution: Where can the greatest benefits be achieved with the standard? And where are the costs? Who is worst affected by the current restrictions?
• intrinsic aspects of the standard: How complex is it? What is its scope? What knowledge is needed in order to implement the standard?

Examples of adoption tools:

• Informing/advising.
  • Organising information events.
  • Information days.
  • Presentation at a conference.
  • Articles in magazines.
  • Advice on use of the standard.
• Involving and influencing.
  • Drafting and sharing collective business cases.
  • Documenting cases.
  • Publishing an overview with users.
  • Open standardisation process.
  • Establishing a sounding board group.
  • Community building.
  • Establishing a collaboration platform.
  • Harmonisation between software suppliers of users.
• Cooperation and facilitation.
  • Testbed for standard implementation.
  • Implementing shared pilots.
  • Organising a plugfest.
  • Establishing partnerships.
  • Validators.
  • Business case tool.
  • Reference implementations.
• Unburdening and grants and subsidies.
  • Grant for introduction.
  • Financing implementation at software suppliers.
  • Drawing up a specific action plan.
  • Introducing own implementation to serve as ‘broker’.
  • Certification
  • Free implementation support.
• Negotiation and contracting.
  • Administrative embedding at users.
  • Drawing up a covenant.
  • Drawing up a contract between the governing actor and chain parties.
• Imposing and obligation.
  • Imposing the standard via the list of open standards for ‘apply or explain’.
  • Legal compulsion.

Below we describe five steps for making the right choices to encourage adoption by specific sector organisations:

3.4.10.4 Step 4: Tool selection and planning

The next step is to identify the most appropriate tools for the likelihood of individual and collective adoption.

Where there is a high likelihood of individual adoption, the best choice is generally a communication tool. After all, whatever the case, it is likely that the organisation will decide to adopt the standard.

As a rule, an average likelihood of individual adoption will result in a financial tool. The organisation needs a gentle nudge to encourage adoption of the standard. Where the likelihood of individual adoption is low, the most successful choice is a legal tool. Unless required to do so, the organisation is unlikely to take the decision to adopt the standard.

A plugfest, plugtest (or ‘connectathon’) is an adoption tool that falls under the heading cooperation and & facilitation. The central idea behind a plugfest is to bring together the suppliers who have implemented the standard, and to use scenarios to test interoperability between the suppliers/systems, on the ground.

During a plugfest, the implementation of a standard is assessed at a meeting, by investigating whether the information exchange the standard aims to bring about is actually achieved. Scenarios can be used for this assessment procedure. In these scenarios, the steps are implemented which also have to be followed during the normal everyday use of the standard. The scenarios are focused on the exchange of information between applications.

If a scenario proves unsuccessful, the underlying cause must be investigated. The causes need not always relate to the implementation of the standard. Interoperability can be hindered by other causes. If possible, the problem is corrected on the spot, and scenarios run through, once again.

From the point of a standardisation organisation, organising a plugfest can make a positive contribution to:

interoperability: plugfests offer suppliers that have implemented the standard an opportunity to assess the implementation of that standard against other implementations by other suppliers. Any errors that emerge can be corrected immediately or at a later stage, and components of the standard that are shown to be insufficiently clearly specified are revealed during the procedure.

transparency: at the end of a plugfest, suppliers know the identity of colleagues with whom they can cooperate, on the basis of the standard. Any audience at the plugfest will be given a picture of how the various suppliers use the standard, and which applications from the suppliers work well together.

adoption: by participating in a plugfest, suppliers can boost their presence. By inviting an audience, the standard can also be brought to the attention of end users.

As a rule, standardisation organisations have above all a network perspective on the adoption of their open standards. Another perspective is that of the individual organisation. The individual organisation is required to make choices with regard to the standards to be used. The governance tools for specifically focusing an organisation on the adoption of open standards include:

Compliance management: in which an organisation defines how it deals with mandatory standards.
The IT policy: in which an organisation defines its policy outlines in the field of IT and open standards. Architecture management: the models and principles (including the standards to be applied) which make up the IT landscape.
Portfolio management: the quality criteria for projects, the deployment of tools for IT innovation, and renewal projects. This for example is relevant to the allocation of resources to a migration towards a specific (new) open standard.
Purchasing and supplier management: the requirements imposed on suppliers.

For a standardisation organisation, these are the approach points for encouraging adoption within a specific party. They also represent the link to the adoption tool the standardisation organisation can deploy. For example:

1. By using legal means (apply or explain, inclusion in the law) an organisation is compelled to determine within the compliance management process how a specific standard will be integrated.
2. By giving examples or offering reference models, it is possible to encourage an organisation to include a standard in its target architecture.
3. Financial resources can boost priority for migration to a standard in the portfolio management process.
4. Finally, for example by providing model specifications, adoption can be accelerated in relation to purchasing.

** Quality policy and benchmarking

Many organisations strive for interoperability in which semantic standards are a means of achieving this objective. Numerous semantic standards have indeed been introduced over the past few years. Nevertheless, little is known about the quality of semantic standards. This is remarkable, given that the quality of those standards will undoubtedly impact on the extent to which the interoperability objective can be achieved.

Unlike other disciplines such as software engineering, little literature or knowledge are available about what makes a good quality standard, capable of delivering an effective contribution to interoperability. This then is the perfect definition for our term quality: fitness for use! (the definition provided by quality guru Juran). Government policy is above all aimed at the openness of a standard, which is just one aspect of quality. A high quality standard is undoubtedly an open standard, but the opposite is not necessarily the case: an open standard need not by definition be a high-quality standard. In the assessment of standards for the ‘apply or explain’ list from the Dutch government, although a strong emphasis is placed on openness, there is also a recognition that other quality aspects (usability, potential and impact) must also be taken into account in assessing for inclusion on the list.

Generally speaking semantic standards are developed in-house by an organisation and not within large standardisation organisations. This can impact on their quality; at the very least, it means that for each semantic standard, the quality can vary widely.

3.4.13.1 What do standardisation organisations themselves think of quality?

A study among 37 management organisations for standards (including international standards such as XBRL, HR-XML, ACORD and HL7 and national standards such as SETU, StUF and Aquo) reveals that more than 90 percent of the consulted developers of standards believe that the quality of their standard can be improved (see the figures below). A very large majority also believes that improving the quality of their standards would contribute to better interoperability.

graph TD;
    quality(Quality model for semantic standard);
    product(A. Product quality);
    process(B. Process quality);
    practice(C. Quality in practice);
    standard((Measure within<br>content<br><i>the standard</i>));
    organisation((Measure in<br>development and<br>maintenance<br><i>de organisatie</i>));
    implementation((Measure in<br>application,<br><i>de implementatie</i>));
    quality-->product;
    quality-->process;
    quality-->practice;
    product-->standard;
    process-->organisation;
    practice->implementation;

3.4.13.4 Using the quality instrument

The relationship between interoperability and standards is that of the end and the means. Without taking account of the quality aspect, standards are far too often seen as a holy grail. The standard becomes the end in itself, rather than a means of effectively and efficiently achieving interoperability. Shifting attention to the quality of standards prevents standards becoming an end in and of themselves, thereby reinforcing the relationship between standards and interoperability.

The quality model summarised in the figure below can be a valuable tool in that process. If you choose to use it, we strongly recommend studying the complete instrument Quality of Semantic Standards, and even considering preparing a tailor-made instrument by making a careful selection from the quality model.

The quality model is a starting point to be used for evaluating the quality of a standard. Nevertheless, the model must be deployed in a cost-effective manner. In many cases, the wish is to carry out a quality measurement in just a few hours. In that case, the costs are fairly limited and the benefits will quickly exceed the costs.

It can also be meaningful to use the quality model as a form of self-evaluation by the standardisation developer who has a thorough knowledge of their own standard and who is able to use the model as a though framework/frame of reference for analysing their own standard. After all, the intention of the quality model is not to prove a right or wrong but purely to identify possible areas for improvement.

In brief, using the quality instrument for standards could deliver the following. In summary:

• a model for reviewing the standard: a fresh look / insight into aspects that impact on the quality of a standard.
• ideas for improving the standard.
• ideas for adapting the standardisation process.

It is useful for a standardisation developer to consider their standard with a fresh look as this process can give them an idea of how quality can be influenced. As they use the tool, the standardisation developer will develop ideas on how the standard can be improved or will see opportunities to change the standardisation process to achieve higher quality.

In its complete form, the quality instrument is a measuring instrument (like a thermometer) for standards; in other words a complete system including ‘tool’ and ‘user guide’. Nevertheless, if well-founded, the quality model on its own can be used as a ‘viewfinder’ according to which standards can be tested in practice.

No matter how good the quality of a standard is, if the quality of the implementations is below par, it will still not result in interoperability. This section considers the possible forms of certification, compliancy testing, validation and other forms of assessment for the application of the standard and the possible resultant reward. We will use the term certification as a container term for all these forms.

After a standard has been developed and adopted to some extent by the market, the question that almost always emerges is that of certification. Sometimes it is the suppliers, as early adopters of the standard, who wish to positively stand out on the market in the form of a quality standard (in other words they are keen for some return on their investment as early adopter). On other occasions, the call for certification for guaranteeing interoperability is raised by the fact that some implementations turned out not to be interoperable, in practice. These differences alone show that certification can be deployed in different ways as a means of answering different questions.

Perhaps the most important step is to gather the relevant wishes and requirements. This must be done both when a new standard is drawn up and when an existing standard is amended.

The reference for an open standard is that everyone is able to submit his or her wishes. In the ideal situation, this group is as large as possible - since this increases support for the standard. It is possible that the governing body of the standardisation organisation will lay down certain directions, which may introduce some restrictions. These restrictions may for example relate to the overall functional scope of the standard. There are different possibilities for gathering wishes and requirements:

• Creating an environment (such as a website, miro board, git repository or wiki) on which users can leave their ideas. In that same environment, users can also discuss ideas and proposals for changes, with each other.
• Via formal consultation. In this option, a formal request is submitted to parties related to the standard about future developments, wishes or requirements.
• By organising workshops or discussion meetings with stakeholders from the community. During these meetings, current developments can be discussed. For example there may be a new development at one of the participants that is also relevant for others. This development can result in the extension of the standard.

Whatever form or combination of forms is chosen, at the end of the day the process should produce a list of wishes and requirements that needs to be evaluated.

Gathering wishes and requirements is an ongoing process. It can sometimes be meaningful for the management organisation to inform parties active in the community of the possibilities for submitting wishes and requirements.

When drawing up a new standard, a pressure cooker process can be followed, in which the initial step towards a new standard can be taken in a short time, with a number of key players.

Not every idea or wish will automatically result in a proposal for change to the standard. Broadly speaking the following possibilities emerge:

• The idea is more a question specific to implementation at a particular party. For example when an organisation still has little experience with the standard. In such a case, the community or the management organisation can offer support in solving the problem. It is then not necessary to change the standard. A wish or idea relates to adaptation or extension of the existing standard. This may be the result of changing legislation, changing processes or other changing needs. The proposal relates to a fundamental change to or extension of the standard. For example:
  • Functional extension
  • In addition to semantic standardisation, also specifying at transport level how data should be exchanged. For example: specifying that certain XML/JSON messages can only be exchanged via REST-API.
  • Application of the standard in new sectors.

At a certain point in time, as identified by the submitting party, the wish or requirement should be included as a request for change.

Depending on the structure of the management organisation, a secretariat or support experts can carry out an initial selection according to the categories referred to above. It is also possible to make an initial estimate of the impact of a proposal for change.

By entrusting this task to a secretariat or support experts, the eventual evaluation can be completed more quickly. It is however important that the management organisation adopts a primarily neutral role: in the case of an open standard, it is eventually the standardisation community that decides. There may sometimes be wishes or requirements that are beyond the scope of the operational process or which require decision making at tactical or strategic level by the governing body of the standardisation organisation. These issues can then be directed straight to the governing body.

The list of requests for change must be periodically examined. In that process, the requests for change must be evaluated and a decision reached on whether or not a change will be made to the standard.

There are different ways in which decision making can be organised. An open standard requires a majority decision or a consensus. In a consensus, everyone must agree on the proposed change. With majority decision making, at least half plus one must agree to the proposed change.

Decisions can sometimes be taken by a working group and sometimes by a more senior body. In that case, a working group will generally provide important advice about the change. This may rely on advice from technical and substantive experts by submitting a proposal for change to technical and substantive working groups before putting the changes on the agenda for decision making. At the end of the day, the essence is that every stakeholder has an opportunity to be involved in the decision-making process.

Working groups are important instruments for gathering, preparing and evaluating proposals for change. Despite openness, participation in working groups may be limited, for practical reasons. Distinctions are often made between types of stakeholders, also because it is worthwhile for the working group to be a good representation of the stakeholders. For this purpose, NEN uses a stakeholder analysis, in which the stakeholders are identified by using a generic value chain. As follows:

In ideal terms, a standard is used by a large number of organisations. Any change to a standard will potentially have considerable impact. It can mean that a large number of systems and processes have to be adapted. As well as making a deliberate choice for each request for change, this also requires the management organisation to think about its overall version policy.

The first key point is to determine what types of version are used. There can be major releases which contain a major change, but also minor releases that involve only minor adaptations. It must be clear to users which version of the standard they are permitted to use. Is it for example permissible to use two versions at the same time, or not?

Within the standard itself, this also creates requirements in terms of migration and compatibility between versions. On occasion, provisions are made within a standard to make this possible. For example, a common choice is to make standards backwards compatible to a specified version. For example: all minor changes to a major version are backwards compatible. If such an agreement is put in place, it must be announced explicitly. In this way, users of the standard can adjust to the situation when choosing which version to use.

In many cases, there is a relationship with another standard. For example an international standard for which an application profile has been developed. As well as changes from within their own community, in such cases, account must also be taken of changes to the underlying (international) standard.

This must be recognised in the change process. There are three aspects:

• Agreement must be reached on the extent to which there is a fixed relationship between the (own) standard and the related or underlying standard: can any random version be used? Or is a particular version specified?
• In the event of changes to the international/underlying standard, a decision must be reached on whether this impacts on the own standard.
• It must be determined whether and if so what relationship exists between the release timetable and version number of the own standard and the underlying standard.

The relationship with other standards is discussed in more detail in section 3.2 Architecture.

One widely made comment is that developing standards is a slow process that can take years. This is a traditional mode of thinking, but who says that it is necessary to follow the old, traditional route to standardisation?

Things can clearly be achieved more quickly: The Pressure cooker concept was used in the waste sector to develop a standard. In just one week, standards were developed for the interfaces between the different systems in the waste sector. For example the interface between the mini container and the garbage truck and the interface between the garbage truck and the back office of the municipal waste processing organisation.

A week of working groups, each with on average 15 participants from both waste processing organisations and suppliers, in which the standards were individually discussed, was followed by two further weeks of elaboration by an external supervisor and two more weeks of review period for the working group, before the standard was delivered to the steering committee. Counting from the moment at which the working group was established, a standard was put in place within two months.

There is a risk that this accelerated process will be to the detriment of quality: a poor standard could cause huge problems in the future. The quality of the standard relates strongly to the participants in the pressure cooker. One remarkable feature is that working group members tend to establish contacts on the spot within their own organisation, as a means of gathering additional information. This situation can in and of itself be an Achilles heel: if one working group member has prepared insufficiently for his task and for example the essential information is not available on the spot, that information cannot be included in the pressure cooker. As such, the quality of and preparations by the working group members are of vital importance.

An important first yardstick is the review process; if it emerges during the review process that many fundamental choices need to be rediscussed, and those choices lead to changes to the intended standard, this is not a positive indicator for the quality of the standard under review. It should however be remembered that the first version of a standard is never perfect. New insights are always discovered during implementations, and errors regularly emerge whether the pressure cooker method is used or not. At the end of the day, a perfect standard is not the objective: instead, a workable standard that helps solve problems.

Important learning points are:

• A pressure cooker is an excellent tool for efficiently developing a standard. The quality still has to be proven, but there is a clear impression that the quality of the working group is decisive for the quality of the standard.
• Clear scope; the phenomenon known in standardisation circles as ‘scope creep’ is more clearly present in a pressure cooker situation.
• Not wanting to work too long and achieve too much: More experience is needed to be able to determine the optimum length and content of a pressure cooker process, but it is certain that there is an optimum; at a certain moment, the magic no longer works.

The use of the pressure cooker is still not common in the world of standardisation, although the idea did originate at international standardisation meetings, in which working group members also sometimes consider a standard, over a period of days. Using a pressure cooker can considerably shorten the duration of the standardisation process. It can also help make the development of standards more efficient and therefore cheaper and that is of course a good thing.

Het Informatiemodel Beheer Openbare Ruimte (IMBOR) is ontstaan vanuit de behoefte van de beheerders en assetmanagers van overheden, zoals: gemeenten, provincies en waterschappen om uniforme benamingen te gebruiken voor beheergegevens van de objecten in de openbare ruimte. Met het IMBOR wil CROW het werkveld beheer openbare ruimte een standaard ontologie bieden om de dataregistratie van gegevens voor het beheer van de openbare ruimte te uniformeren en verbeteren als basis voor een beter assetmanagement.

CROW is de ontwikkelaar en beheerder van het Informatie Model Beheer Openbare ruimte (IMBOR). Het IMBOR is ontwikkeld onder begeleiding van een Projectgroep IMBOR, een IMBOR Klankbordgroep softwareleveranciers en een groot aantal inhoudelijke werkgroepen per vakgebied.

In de beheerorganisatie van het IMBOR zijn vertegenwoordigd:

• beheerders en assetmanagers bij lagere overheden,
• softwareleveranciers die hen ondersteunen met beheerdatabases/beheerpakketten en assetmanagementapplicaties en dashboards,
• vakinhoudelijk experts die voor specifieke vakgebieden kennis hebben van de informatie die nodig is voor het beheer van de openbare ruimte,
• samenwerkingspartners van gerelateerde standaarden,
• belanghebbenden en financiers van het IMBOR.

CROW heeft de beheerorganisatie van het IMBOR daarom opgebouwd uit de volgende groepen:

• Stuurgroep IMBOR: Besluit op strategisch niveau over de aanvullingen en wijzigingen van het IMBOR en adviseert CROW over het beheer en de doorontwikkeling van het IMBOR.
• Klankbordgroep softwareleveranciers: adviseert CROW over de toepasbaarheid van het IMBOR voor beheerdatabases/beheerpakketten, assetmanagementapplicaties en dashboards, en bevordert de implementatie door het IMBOR via hun software toepasbaar te maken bij eindgebruikers.
• Diverse vakinhoudelijke expertgroepen: per vakgebied een groep deskundigen die adviseert welke informatie bij objecten moet worden opgeslagen.
• Gebruikerscomité: adviseert CROW over de toepasbaarheid van het IMBOR door eindgebruikers, en bevordert de implementatie door mee te werken aan de communicatie over de voordelen en praktijkervaringen.
• Gebruikerscommunity: de grote groep van gebruikers van IMBOR die regelmatig worden geïnformeerd over het IMBOR en via de GitHub en bij tervisieleggingen de gelegenheid krijgen om opmerkingen, suggesties en commentaar te geven.

De beheerorganisatie wordt vanuit CROW ondersteund door een IMBOR-team met medewerkers die kennis hebben van openbare ruimte, BIM en data- en informatiemanagement. De technisch experts in het IMBOR-team adviseren de productmanager IMBOR over technische wijzigingen in het informatiemodel en de ondersteunende techniek. Het IMBOR-team wordt aangestuurd door de productmanager IMBOR.

De productmanager IMBOR wordt aangesteld door CROW. De productmanager vervult een centrale rol in het beheer van IMBOR door samen met de beheerorganisatie IMBOR:

1. Een open besluitvorming te faciliteren waarin alle belangen kunnen worden ingebracht;
2. Een zorgvuldig en transparantie beheerproces te waarborgen door o.a. bijbehorende documentatie volgens common creative licentie open beschikbaar te stellen (CC BY 4.0 Intl);
3. Voldoende contacten te onderhouden met gebruikers om de inbreng van wensen en behoeften waarborgen;
4. Het gebruik van de standaard te ondersteunen door o.a. aan te sturen dat vragen van gebruikers via de helpdesk beantwoord worden.

Logius heeft de governance van het beheer van haar standaarden aangesloten op de governance van de Generieke Data Infrastructuur (GDI) van de Nederlandse overheid.

Er is een breder keuze aan digitale applicaties die gebruikt kunnen worden voor standaarden beheer, al zijn ze hier niet altijd voor bedoeld. Samenwerkingsapplicaties voor documentbeheer of softwareontwikkeling kunnen worden toegepast om beheerders en betrokkenen toegang te geven tot documentatie of zelfs om gebruikers de documentatie bij te laten werken.

Een voorbeeld is het gebruik van Git en Respec voor het operationeel beheer. Git is een applicatie voor wijzigingsbeheer bij softwareontwikkeling. Iedere wijziging wordt opgeslagen in een database nadat het door de auteur voorzien is van commentaar. Hierdoor kunnen versies van verschillende tijdstippen vergeleken worden en kan de verantwoording nagelezen worden. Daarnaast is er ondersteuning voor parallellopende versies waardoor er bijvoorbeeld gewerkt kan worden aan een ingrijpende wijziging zonder dat onderhoud aan de huidige werkversie verstoord wordt. Er is een aantal webomgevingen voor samenwerking aan code die gebruik maken van git zoals Github, Gitlab en Gitea. Een gebruiker kan ook zelf op basis van de beschikbare Git open source software een Git omgeving maken en daarmee onafhankelijk blijven van de grote Git platforms. De Git platforms zoals Github en Gitlab bieden hostingopties en een webinterface voor het doorvoeren en inzien van wijzigingen naast ondersteuning voor lokaal geïnstalleerde git-applicaties.

Respec is een applicatie om bestanden om te zetten in documentatie die online gepubliceerd kan worden. Het beheer van specificaties verloopt steeds vaker via een automatisch proces. Waar het in het verleden nog gebruikelijk was om losse documenten te delen binnen werkgroepen, stappen steeds meer beheerorganisaties over naar (git) repositories om teksten in te beheren. Hoewel deze omgevingen van oorsprong bedoeld zijn om programma code in te beheren, zijn deze ook goed bruikbaar voor het beheer van ‘leesbare’ tekst. Door gebruik van een responsive layout kan de documentatie onafhankelijk van schermgrootte leesbaar getoond worden. Respec maakt automatisch een inhoudsopgave waarmee een gebruiker snel door de documentatie kan browsen. Respec is specifiek bedoeld voor technische documentatie en het sluit goed aan bij applicaties voor softwareontwikkeling zoals Git.

Door gebruik te maken van dezelfde gereedschappen als voor het beheer van programmacode kan het beheerproces automatisch ondersteund worden. Documentatie wordt ondergebracht in een online repository. Een repository is meer dan een archief voor code. Binnen Git platforms zoals Github en Gitlab kunnen issues ingediend worden door gebruikers, zijn projectmanagementtools beschikbaar en kunnen automatische acties op een repository uitgevoerd worden. Het is ook mogelijk om automatische controles uit te voeren op de code in een repository, bijvoorbeeld op basis van toegankelijkheid of op ontbrekende verwijzingen.

In een Git platform zoals Github kunnen ook verzoeken tot wijzigingen (genaamd issues in git) ingediend worden, die dan weer tot wijziging in de code kunnen leiden. Issues kunnen in principe door iedere gebruiker worden ingediend. Een wijzigingsverzoek wordt verwerkt door de beheerder van de repository. Een issue kan worden toegewezen aan een ontwikkelaar en worden door de beheerder geagendeerd voor overleggen door ze te labelen. Door een issue een label Technische overleg te geven kan gefilterd worden op alle issues die relevant zijn voor dat overleg. Daarnaast worden wijzigingsvoorstellen gelabeld met scope (klein of groot) en wat voor wijziging het betreft (correctie, documentatie, wijziging etc.).

Omdat de wijzigingen op de documentatie bijgehouden wordt met git kunnen deze gerelateerd worden aan het wijzigingsvoorstel waar ze bij horen. Hierdoor bevatten de issues een overzicht van alle wijzigingen die daaruit voortkomen.

Binnen Github kunnen de lijsten met lopende wijzigingen bestemd voor een specifiek overleg automatisch gegenereerd worden. Vooral wanneer een beheerder een groot aantal repositories in beheer heeft is het handig de wijzigingsvoorstellen met zo'n automatisch proces overzichtelijk te houden.