BOMOS (Beheer- en OntwikkelModel voor Open Standaarden) is een hulpmiddel
van en voor de standaardisatiewereld. Dit deel 1 bevat als fundament een
beschrijving van het Beheer- en Ontwikkelmodel; een gelaagde set van
activiteiten die relevant zijn bij het ontwikkelen en beheren van standaarden.
Daarnaast zijn rollen gedefinieerd die relevant zijn bij het beheer-
en ontwikkelproces van standaarden. Ook beschrijft het de context hoe BOMOS
in de standaardisatiepraktijk te gebruiken is.
Status of This Document
This is the definitive version of this document. Edits resulting from consultations have been applied.
BOMOS is the abreviaton of dutch name "Beheer en OntwikkelModel voor Open Standaarden". In English this means Management and Development Model for Open Standards. We will use BOMOS as a noun in the English version rather than introducing a new acronym.
We will start with a series of acknowledgements, before presenting the BOMOS ‘Commandments’, which bring together many of the elements that make up BOMOS. We will then describe the structure behind BOMOS before introducing the Management and Development Model itself in detail, concluding with an overview of the subjects discussed in BOMOS Part 2: The Elaboration.
1.1 Acknowledgements
Work on the predecessors to BOMOS was started in 2006, but it was not until 2009 that the first BOMOS publication saw the light of day, with its characteristic activity diagram. In other words, whichever way you look at it, BOMOS has been around for more than ten years.
Since then, numerous working groups have become involved, all contributing to BOMOS. A positive development, that effectively reinforces the essence of BOMOS: For and By practitioners in standardisation. BOMOS as a source of inspiration for the practice of standardisation, and use of BOMOS had undoubtedly led to new experiences and needs that in turn can be integrated in the BOMOS system. It has also led to a number of different versions and variations of BOMOS, which have not made using the system easier.
The idea behind this now famous cartoon is that the problem of too many standards can be solved by introducing a new standard to replace all the other standards. At the end of the day, the result is nothing more than the addition of a further standard. We have the same intention with BOMOS, but uphold the hope that the result will be different: a single BOMOS as the starting point for everyone.
At the end of 2018, Logius organised a session to discuss the use of BOMOS; an inspiration session attended by some 40 people, representing around 30 different organisations, all of which use BOMOS (to a greater or lesser extent). One wish that emerged from this session was to produce this new version...but who should take on that task? We raised our hand, and set to work not with the objective of making too many changes to BOMOS, but rather to create this one integrated new version that replaces all previous versions while at the same time taking into account the latest developments; after all, the world of standardisation has not stood still.
Only time will show whether we have successfully replaced the earlier work with this version, or whether we simply fell into the same old trap.
Erwin Folmer & Gül Işik & Edwin Wisse
March 2022
1.2 The 13 BOMOS ‘commandments’
‘An unmanaged standard is not a standard!’
‘It is never too early to start looking into possibilities for managing the standard.’
‘Developing and managing a standard is not a temporary project, which makes project financing an unsuitable source of funding.’
‘Developing and managing a standard is a situational process which potentially requires a different structure for every standard!’
‘A standard is never finished!’
‘How open a standard can be depends entirely on the structure of the development and management process.’
‘A sustainable standard is a standard that is open and managed.’
‘The worst thing about standards is that there are so many of them; it is crucial that they be reused (inspired by Professor Tanenbaum: “The nice thing about standards is that you have so many to choose from”.’)
‘The management of standards has a great deal in common with other artifacts (framework agreements, data, apis, ...) which makes BOMOS also suitable for use in other contexts.’
‘A standard is not good or bad, open or closed, etc.; there are many shades of grey, and always room for improvement.’
‘Without standards there would have been no pyramids (standards are as old as humanity itself).’
‘Standards, employed in architecture, form the basis for interoperability.’
‘The essence of a standardisation process is cooperation; that makes standardisation a cultural phenomenon.’
1.3 Background
The management and development of standards is no easy task. Nevertheless, standards are often developed without ever considering the further development and management of those standards. This is because standardisation is often implemented in the form of a temporary project. Based on project funding for the development of a standard or a related facility, without considering structural deployment. This matches poorly with the continuous development and management of standards.
1.4 Purpose
The purpose of this publication is to assist organisations in compiling and improving the management of standards. This publication provides answers among others to the following questions:
How can we successfully (further) develop and manage the standard in our organisation?
How can be structure development and management in such a way that it results in an open standard?
How can we improve the adoption rate of our standard among users?
These specific questions were the original reason for drawing up the Management and Development Model for Open Standards (BOMOS) with its best practice guidelines for an open structure for management. Since that time, BOMOS has been used in practice, and users have expressed the need to share more knowledge and experience with the management of standards. Other issues such as improving interoperability based on standards, transparency and the manageability of standards have been added. Finally BOMOS is now used as the common language in the world of standardisation.
1.5 Target group
The purpose of BOMOS is to support and inspire standardisation communities and their clients in the structural design and management as well as the further development of standards. Practical insights are used to provide this target group with simple and clear models and recommendations.
1.6 Approach & History
The Working Group CMO (Community Model Open Standards), a working group within the Open Standards Office (which was later renamed the Standardisation Forum) at GBO.Overheid (which later became Logius) started working on this subject in 2006. The outcome of their work, a memorandum, was made available by the Standardisation Forum and served as the starting point for the development of BOMOS version 1.
The approach selected to develop BOMOS was a structured discussion with a small group of experts from the semantic standardisation organisations, during which knowledge was shared on the relevant issues. This resulted in version 1 of BOMOS in 2009.
Following this initial publication, a new series of meetings were held in 2010, that were also attended by users of the first version. Based on their experiences and new insights, BOMOS was first expanded and extended to become: BOMOS version 2.
This approach helped anchor the knowledge available within organisations involved in the development and management of standards, including Logius, Geonovum, Kennisnet, CROW, Informatiehuis Water, Stichting Elektronische Transacties Uitzendbranche (SETU), The Netherlands Normalisation Institute (NEN), VNG Realisatie (the implementing body of the Association of Netherlands Municipalities), research organisation TNO, the University of Twente and many others.
Under the auspices of the Standardisation Forum, work was started in 2012 on an expansion entitled BOMOS2i, in which the ‘i’ stands for implementation. A practical guide for use of BOMOS in the standardisation process. Another variant of BOMOS was published by TNO under the name BOMOD. This too discusses management and development processes but in relation to the publication of datasets rather than standards. During this same period, BOMOS was (re)published in different house styles. All in all, this process did not result in greater clarity among users.
In around 2017, Logius once again started to work on BOMOS. An expansion to BOMOS2i was published with the addition of a standards framework, which was used to build the BOMOS measurement tool. This tool enabled managers to actually assess management of the standard.
In 2022, this version of BOMOS (version 3.0.0) was published to provide BOMOS users with a new fully integrated starting point for working with BOMOS.
The heart of BOMOS is the ‘Foundation’. This consists of a basic description of the Management and Development Model and a further elaboration based on literature and experiences gained in practice. In essence, the Management and Development Model is an activity diagram which also offers a definition of the roles relevant in the process of managing and developing standards.
In addition BOMOS in part 2 offers further insight in particular by sharing best practices from the world of standardisation.
Together Part 1 and Part 2 form the basis for BOMOS.
On top of this basic structure, the community has produced a number of BOMOS expansions which can be useful in deploying BOMOS in concrete situations, some of which may involve a slightly different context. We refer to these as the BOMOS Supplementary Modules or a Body of Knowledge, which will remain dynamic over time.
When we talk about BOMOS, what we are actually referring to is the basis as described in Part 1 and Part 2. Although the supplementary modules are clearly linked to BOMOS, they have their own governance, which can result in their being given their own name, their own target group, their own management system, etc. The BOMOS management process also describes the requirements that are imposed before something can be added as a BOMOS supplementary module.
If from your policy making or administrative role you are only interested in the primary level, the foundation (part 1) will offer sufficient background and context. If however you are personally active in standardisation communities, you can seamlessly continue with reading part 2: The elaboration with best practices, which includes more background and practical tips for standardisation.
If you actually intend to make use of BOMOS, it is advisable that you also study the supplementary modules. These contain examples and tools that could prove useful for implementing open standards. The supplementary modules also contain variants on BOMOS. These implementation profiles make BOMOS suitable for use with more than just semantic standards.
2. Context & Definitions
2.1 Context: standards for interoperability
The most important reasons for organisations to strive for interoperability are effectiveness and efficiency. Standardisation ensures improved cooperation throughout the chain comprising for example partners, suppliers and customers.
A lack of interoperability is not only costly but can also lead to extended lead times, as shown by numerous studies.
The costs from the lack of interoperability in the automotive industry in the United States, for example, are estimated at 1 billion dollars, and a design time two months longer than strictly necessary (See: Brunnermeier, S.B. & S.A. Martin (2002). Interoperability costs in the US automotive supply chain. Supply Chain Management 7(2), pp. 71-82.). The government also has an interest in striving for interoperability, but has additional reasons for doing so, also from a social viewpoint. For example consider the consequences in the face of a disaster if the various emergency services were not interoperable. In respect of such topics as electronic patient records and problems concerning young people at risk, interoperability issues also emerge.
Standards are important tools for achieving interoperability and also important in terms of supplier independence. Standards come in different shapes and sizes. There are numerous classifications of standard types, but within government, the European Interoperability Framework is considered the guideline. Within this framework, a distinction is made between technical and semantic interoperability which in turn leads to a distinction between technical and semantic standards. Standards focused on technical aspects (infrastructural) can often be adopted one-for-one from international consortia such as W3C, UN/CEFACT, ETSI, ISO, CEN and IETF.
Standards of a semantic nature often require a regional profile so that specific implementation requirements can be taken into account. There are user groups (communities) active in the Netherlands responsible for developing a national profile for international standards. In the context of Dutch legislation and/or Dutch specific business and government processes, it is necessary to focus international standards on the Dutch situation.
Transaction standards (for business and other applications), vocabularies (lists of values) or files (e.g. patient file) are other examples of semantic standards. Also typical of semantic standards are:
They are often a specific reflection of an international standard.
They are often intended for a specific, substantive problem:
For example ‘vertical’ information exchange for a specific sector: Geo-domain, Education, Healthcare, etc.
For example ‘horizontal’: information exchange for a specific function: Purchasing, Invoicing, etc.
They are often developed and managed in the domain (the sector) and not by formal standardisation organisations.
The heart of the standard is the semantics (meaning) and not the technical aspects.
A semantic standard never operates in isolation and often shares multiple relationships with other international standards, including also technical standards. We often also see stratification within the semantic standard: The international semantic standard which standardises the basic semantics for a specific problem domain and provides space for standardising additional agreements in a specific context (such as a country). These additional agreements on top of the international standards are sometimes referred to as an application profile, but in many cases also simply designated by the term semantic standard. Within the application profile or semantic standard, vocabularies (code lists, etc.) beyond the standard are often adopted because they have their own dynamic and can consequently be governed by other management procedures. The result is three levels of semantic standards: international, specific context (e.g. national) and vocabularies. One vital task is to maintain harmonisation with the development and management organisations for these international standards. The semantic standards, the subject of this document, can apply in the government context (G2G, G2B and/or G2C context) but in practice this document can equally apply outside the government context.
The development and management of standards differs from the development and management of other products such as provisions and software. A provision is a combination of information, system, organisation and interface required for a service. Both internally within the provision and at the interface between the provision and the outside world, different types of standards can be used, including semantic standards. This user relationship between a standard and a provision applies equally between a standard and software.
As a consequence, standards have a different set of users and a different set of challenges, such as harmonisation with communities and international standards. This does not mean that the discipline of semantic standardisation is unable to learn from other disciplines such as the software world. Models from those disciplines can be perfectly usable. In particular the BiSL framework for functional management is usable to a certain degree and was also considered in the creation of BOMOS (For more information about BiSL: Best Practice - BiSL – Een framework voor Functioneel Beheer en Informatiemanagement , Remko van der Pols, Ralph Donatz, Frank van Outvorst, Van Haren Publishing, 2005.).
BOMOS was initially developed for semantic standards; this focus is still regularly reflected among others in the best practices in part 2. However, on the basis of user experiences, we have since also learned that where BOMOS is employed advisedly, it is also usable in the context of other standards (such as technical or organisational standards), provisions, frameworks or even other concepts such as the management of data, or software. User experiences of this kind, which may result in amended BOMOS versions for use in a specific context, can be published as BOMOS Supplementary Modules.
2.2 Definitions
Management and development of standards (in short: management)
All activities focused on structurally working towards, making available and maintaining a (set of) standard(s) that always meet the latest needs of stakeholders.
It is possible to distinguish between development and management. The management of standards relates to the making available and adaptation of existing standards based on new wishes and requirements, without introducing functional extensions. In other words, this includes the distribution of the standard for example via a website, the provision of support, the gathering of wishes and requirements and the publication of new versions.
The development of standards relates to the development of a standard as a solution for a new functional domain. This can mean that on the basis of the development the existing standard is expanded, or that a new standard emerges.
Management and development in its broadest sense, for a standard, also includes such subjects as adoption and certification.
Management and Development Model
The Management and Development Model is a layered structure of subjects necessary for the development and management of an open standard, as reproduced in an activity diagram. It is the core of BOMOS.
Community
Each specific community or group in the electronic (government) field involved with the development and/or management of a specific (set of) standard(s), in response to an explicit common need. Because needs of this kind are often perceived both in the private and in the public domain, a community can be a form of public-private partnership.
Open standard There are many different opinions about the definition of an open standard. Above all because of the interests of different organisations, no successful definition has ever been produced. In BOMOS, we use a definition that was used in the initial period of the European Interoperability Framework, and which was adopted by the Dutch government. At a later stage adaptations were made, in particular more strict definitions, but the original definition is relatively the most open. What we understand by an ‘open standard’ is a standard that satisfies the following requirements:
The standard is approved and will be maintained by a not-for-profit organisation and further development is based on an open decision-making procedure accessible to all stakeholders (consensus or majority decision);
The standard is published and there is free access to the specification document for the standard or the document can be obtained for a nominal charge. It must be possible for all parties to copy, to supply and to use the standard free of charge or for a nominal price;
The intellectual property - in respect of any patents present - to (parts of) the standard is provided irrevocably on a royalty-free basis;
There are no restrictions regarding the reuse of the standard.
Semantic interoperability
Means that the collaborating parties allocate the same meaning to the data exchange.
Semantic standards Are agreements about the meaning of data.
Working group A group within the community with a demarcated sub activity with an unequivocally defined end result as its objective.
For more information about interoperability and standards:
How can BOMOS be used? There are a number of different options:
As a tool for further development of standards management organisations
As background information and a source of inspiration
As a mirror for the current management process
3.1 BOMOS as a tool for further development of the management organisations
The most important application of BOMOS is as a tool for the further development of standards management organisations. Many standards management organisations originate from an initial project or programme. This is sometimes linked to a specific service. Management of the standard can then have a dependency with the operational management of that service. To enable the standard to be deployed beyond the service it was developed for, further considerations are needed and BOMOS can be useful in that context.
Another application is the structuring of a completely new standards management organisation. If organisations opt to agree on a standard in a sector, it is not possible to avoid reaching not only substantive but also financial and management-related agreements. In that case, BOMOS can be a useful guideline for reaching those agreements.
There are a number of options:
Is there already a standard in place?
On occasion there is not yet a standard but a standard needs to be developed. In the chapter on operational management, we consider gathering the correct wishes for and requirements on the standard. The next step is bring the standard to the to the management process.
Structuring the management process
It starts with setting the scope for the management process: what does the management process need to be equipped for? To manage a single standard or multiple standards? Depending on the answer, using BOMOS, it is possible to make a choice relating to the management activities (strategic, tactical, operational) and support activities. Using BOMOS it is not only possible to deliberately choose whether or not to undertake certain management activities; the system also contains hints and tips for the structuring of the activities themselves.
Has a standards management organisation already been established?
There is often already some form of management structure. In that case, BOMOS can be used to check whether all activities comply and whether in addition to operational activities, strategic and tactical activities also need to be dealt with. BOMOS can also serve to improve the openness of the process.
Tackling specific problems
BOMOS can also be deployed to create a tailored approach to implement improvements on the basis of best practices and reference models for such issues as:
Quality: how can the quality of a standard be measured and improved?
Adoption: how can the adoption of a standard be accelerated? What tools can be employed for that purpose?
Financing: how can the financial model of a management organisation be improved, for example if funding is declining, or wishes change?
Validation and certification: how is it possible to test whether the implementations of a standard comply with the specifications imposed? What possibilities are available?
3.2 BOMOS as background information and a source of inspiration
BOMOS is extremely useful as a source of background information, for example for parties who commission standards. The BOMOS Model was in fact developed for this purpose, and lays a solid foundation. Knowledge about the management of standards is essential for everyone involved in standardisation.
In the elaboration section, solutions are presented based on practical experience: where possible, examples are used to demonstrate the acceptance of the solution in practice, to describe the standardisation organisations that have experience with that process and to present the related recommendations and advice. In other words, valuable background information about practical situations.
Together, these two elements form the basis of BOMOS, and provide inspiring background information. Another example is the use of BOMOS as a tool for administrators and policymakers to help them identify exactly what openness of standards really means. BOMOS is also used as a ‘language’ that allows clear communication about the management of standards.
3.3 BOMOS as a mirror for the current management process
Various organisations use BOMOS as a sort of underpinning or even as a guideline for the management of their (open) standard. Other organisations use BOMOS as an outline checklist and to account for and substantiate specific choices they make. However, BOMOS has no normative role. That is indeed not possible, because the structuring of the management is highly situationally dependent.
Nevertheless, conformity with BOMOS is possible. The management organisation operates in accordance with BOMOS if a management document is published in which the structure of all elements from the BOMOS Activity Diagram (the Management and Development Model) are described.
For specific situations, it is possible to define requirements/assessments for each BOMOS activity, in more detail, but these are not part of the foundations of BOMOS, because they may not be relevant for all BOMOS users.
Moreover, even if the management organisation does operate in accordance with BOMOS, this does not automatically mean that the standard also complies with the criteria for the apply or explain list of standards published by the government. However, it is clearly preferable if the registered standards do operate in accordance with BOMOS, as well as focusing particular attention on the chapters relating to the development and management organisation, openness, the operational process and the financial structure.
In linguistic terms, the word ‘Standard’ often refers to something which is jointly agreed on and laid down. In that context, we may conclude that BOMOS is a standard. A standard for (the development and management of) standards.
4. The Management and Development Model: Design for development and management
The figure below shows the Management and Development Model: a layered structure of subjects necessary for the development and management of an open standard.
The structure consists of a series of elements:
Three main layers: strategy, tactical and operational.
Two support layers: implementation support and communication.
A series of activities that can be implemented in each layer.
The structure of the development and management subjects is situationally dependent; in other words, different situations can result in a different structure for the optimum result. Every subject can be implemented in a minimum and a maximum scenario, or may not in fact be relevant for a specific organisation. In other words there is no automatic requirement that every subject is implemented. Indeed, too much emphasis on formalisation can have a counterproductive result.
The model only describes those subjects that can be implemented via activities, some of which may be necessary. It is up to the responsible officer at an organisation for the management and development of standards to select and to structure the relevant components on the basis of the model shown here. Wherever relevant, any advantages and disadvantages of a specific structure will be shown, for a subject or activity.
As a result of the situational dependence it is not possible to identify core subjects, but one thing is clear, namely that governance always has to be organised in order to make a decision-making process possible.
Depending on the situation, the next step is to determine which subjects should be given priority. The figure shows the three traditional layers: strategy, tactical and operational. These are flanked by two support processes: communication and implementation support.
The model could suggest that these subjects operate in isolation, because no relationships between them are shown. However, the opposite is the case: many subjects are related - both within a main group and between the main groups.
This makes harmonisation between the subjects essential. The model says nothing about the organisation form or its integration in a management organisation. In practice, multiple activities can be entrusted to a single organisation components or multiple organisation component can be involved in a single activity. The best practice organisation structure (Part 2: The Elaboration) discusses this in more detail.
4.2 The subjects from the model
The activities referred to can be interpreted as follows:
Strategy: Course-setting activities related to the strategic (long) term:
Governance: laying down policy for your own administrative organisation (such as the legal form); the bylaws (charter) and forming alliances with other organisations. Regulation of the decision-making process is crucial.
Vision: the description of a direction for development. This is the spot on the horizon that provides the focus for the long term.
Financing: having a financial model for the long term that guarantees revenue in line with demand.
Tactical, Activities that ensure stability in the medium term:
Adoption & recognition: Activities relating to certification, the compulsory nature or promotion of the standard.
Architecture: Layout of the standard and the related processes and techniques.
Community: Management and support for forums and stakeholders.
Quality policy benchmarking: developing policy that ensures the quality of implementations of the standard.
Rights policy: Determining the intellectual property rights.
Operational, the practical activities that lead to new versions of standards, including:
Initiation: Identifying new ideas (for example for a new specification and new work) and all activities that relate to its successful organisation (e.g. analysis of interests, business case, agenda setting).
Wishes and requirements: setting out the wishes and requirements for the specification to be developed and managed, also known by the name Maintenance Requests (MRs).
Development: the substantive elaboration of solutions for the ideas, wishes and requirements drawn up in the previous phases, at conceptual level. As far as possible, these solutions are kept separate from technologies intended for further elaboration in (a new version of) the specification.
Implementation: the actual adaptations implemented in the specification and any technical structure, based on the conceptual solutions.
Documentation: providing an appropriate record of the results of the primary management process. Not only the availability of the specification, but for example also enabling a historical overview of requests for change (maintenance requests) and their most recent status.
Implementation support, support activities aimed at promoting implementations of the standard, including:
Training: Offering training opportunities to various user groups ranging from information meetings through to online courses.
Helpdesk: Providing support to various user groups, for example by telephone or email according to a service level agreement (e.g. answering questions within 24 hours). Drawing up and updating a list of frequently asked questions can also be a helpdesk activity.
Module development: (Encouraging) the development of widely distributed software modules to implement the standard. This can be achieved by encouraging the market to develop software of, if the market refuses to move, developing and distributing software in-house, to get the market moving.
Pilot: Trials with the implementation of the specifications. Some standardisation organisations require one or more pilots to have been conducted before a standard is officially released.
Validation & Certification: Offering possibilities for testing the correctness of the implementation (validation). This can be combined with an official process which results in the certification of an organisation or product. Another option is to make completion of validation and certification processes compulsory. Module development and certification are risky activities that represent an active intervention on the market. They must be carefully implemented, as far as possible outside your own organisation.
Communication, support activities aimed at creating support for the standard including:
Promotion: Representing the value/necessity/benefits of the standard.
Publication: Announcing the standard and the current state of affairs and making them findable (website).
Complaint handling: Guaranteeing that complaints will be taken seriously by dealing with them according to a careful procedure. Complaints can also be viewed as suggestions for improvements.
4.3 Activities and Roles
The various activities must be undertaken by different roles. The NEN standard 7522:2021 ‘Health informatics - Development and maintenance of standards and systems of standards’ which provides an overview of the roles relevant in the development and management of standards, is reproduced here in slightly altered form
Owner: person with final responsibility for the development and management of a standard. The owner determines the scope and objective of a standard, and determines the (underlying) principles employed in development and management.
Financier: responsible for financing the development and management of standards.
Authoriser: approves a standard. Explanation: an authoriser can be a person, organisation or group of persons and organisations. The owner must appoint the authoriser. An authoriser often combines a representation of stakeholders, who as a person or organisation also have the role of user.
Functional manager: responsible for the process of development and management of standards within the frameworks of the agreements reached and the agreed governance. Explanation: the functional manager is responsible for the process of development and management of the content of standards. In this process, he works closely with experts, users, the technical manager and the distributor. The functional manager often has a direction-setting role. Results of the process are submitted to the authoriser.
Technical manager: responsible for the technical management of standards. The technical manager is responsible for the structure and management of a technical environment necessary for maintaining the artefacts that form part of the standard. Explanation: The technical manager is responsible for the technical environment in which the artefacts under management are maintained. The technical environment consists of the set of IT resources (tools, hardware, networks, etc.) necessary for implementing functional management of the standard. The technical manager is responsible for the possible application of version management for the technical environment and the provision and maintenance of the technical environment, in consultation with the functional manager.
Distributor: responsible for distributing standards.
Expert: provides specific necessary expertise for the development and management of standards. Explanation: depending on the standard, different types of experts may be necessary. Experts commonly called in are substantive domain experts or experts in the field of ontology, architecture, trust, information security, cryptography or privacy. It is also common for stakeholders who have practical experience to be represented, who as a person or organisation also have the role of users.
User: uses the standards directly or indirectly. Examples of these users are suppliers of components (often applications) or users of those applications (indirect).
For the roles referred to above, the role of financier, expert, user and end user can have multiple occupants: in other words, more than one person or organisation can play the role of financier, expert, user or end user. Multiple occupancy here also means that the stakeholders who fulfil these roles represent a different interest or area of expertise, which they also contribute. The other roles are single occupant only: there can only be one person or organisation in each role. Single occupancy can also mean that the role is fulfilled by an institution, for example a board or a consultation body in which more individuals or organisations are represented.
For the main BOMOS activities, the table below shows which role holds primary responsibility and which other roles are often also involved.
Activity
primary responsibility for the role
Other roles involved
Strategy
Owner, financier
Authoriser, functional manager, experts
Tactics
Authoriser
Financial manager, experts
Operational
Functional manager
Technical manager, experts
Implementation support
Functional manager
Technical manager, experts
Communication
Distributor
Functional manager, technical manager, experts
4.4 How to use BOMOS as a tool for the management organisation
Earlier, we described in which situations BOMOS can be used, here we make the step to how BOMOS can be used. This cannot be easily and uniformly defined, as it is determined by the context of the user. That context itself can be determined by mapping out the situational characteristics. One key situational characteristic is the position of the standard in the standard lifecycle.
The current life phase of a standard clearly impacts on the structure of the management. A standard still in the development phase imposes different requirements on management than a standard that has been broadly adopted and implemented. A sensible rule of thumb is to carry out a check (on the basis of the Management and Development Model) at each transition point, to determine whether your management structure is still compliant. Below is a description of the phases of the standard lifecycle, to enable you to determine the current phase of your standard.
This phase marks the moment at which a community of stakeholders and interested parties identifies the need for a standard and makes a start on drafting a standard. This does not always necessarily mean that a standard is entirely absent. Even in the event that a standard does exist with minor non-compliant specifications, a community can still reach the conclusion that the need for a new standard justifies the required effort. At this stage there is not any structured management, but the majority of activities are of a more project-based nature. In this phase, for example, it is important to think about the decision-making processes. In the case of a standard with a modular structure, some parts of the standard may already be complete, while others are still in the development phase. The term creation relates to the newly developed modules.
In this initial phase of a standard, the primary need is harmonious decision making. There must be a sound business case capable of convincing the management, the interested users and the developers of the value of the standard. There must also be a clear adoption policy. In larger organisations, it is also important for the processes relating to adoption to be anchored in the process landscape. At the end of the day, this is the ideal means of enforcing adoption via formal means.
2. Introduction phase of the standard
In this phase, a specific standard is selected to meet a particular need. This phase will be hallmarked by numerous changes. The management structure starts to become important. A deliberate and explicit choice can be made in terms of decision making, that the standard should be declared generally applicable or introduced via organic growth with gradual adoption. One example of a deliberate choice is the decision taken by government to impose a compulsory standard. Sectoral agreements or a decision by the Standardisation Forum to place a standard on the ‘Apply or explain’ list are also deliberate choices.
Also in the introduction phase, it remains important to have a good adoption plan. Reiterating the value and necessity of the standard also remain relevant. A new aspect in this phase is the monitoring of the adoption and publication of the standard. Whereas a (draft) version may not yet be available during the creation phase, there must a draft version available during the introduction phase.
3. Implementation / growth of the standard
During this phase, users deliberately opt to implement the standard. The management also takes account of the fact that not all users have a thorough knowledge of the standard. In this phase, management also means supporting and informing the users. Management terms such as ‘early majority’ apply to this phase. Your activities are focused on more professional adoption and professionalisation of the open management processes so that the upscaling of use by all parties remains in sync and the processes remain transparent. Registrations of users/customers/experts, etc. become increasingly important.
Organic adoption refers to a situation in which various (individual) parties decide to apply a standard. This phase will be hallmarked by numerous changes. The management structure becomes more important, as is adoption of the standard by the early adopters. All activities should be focused on these aspects.
4. Full application / maturity of the standard
In this phase, the standard is generally accepted and implemented. Management in this phase is focused entirely on safeguarding the stability and quality of the standard.
It is important to implement quality management and to monitor the BOMOS activities and to consider the relationship with other (international) standards. These aspects can of course also be important during earlier phases, but as a rule, it is always the case for a mature standard.
A mature standard is regularly assessed to determine whether it is still up to date. If a standard is based on an underlying standard, the manager can also check whether this (underlying) standard remains actively managed. It is also worthwhile determining whether new (international) standards have become available, with the same application as your standard. Availability of a new, international standard with international application may be given priority above the standard managed in the national context.
5. Phasing out / transition to another (version of the) standard
During the phasing out of a standard, it is important to closely monitor the relationship with different products. It is possible that the standard occupies a crucial position in the architecture landscape of third parties. It is also important to monitor the organisation structure since removal of the standard may lead to a shift in responsibilities. Decommissioning the financing is another point for attention, as is managing expectations.
5. BOMOS best practices a review - Introduction to BOMOS Part 2: The Elaboration
On its own, the Management and Development Model for standards creates a foundation, but it is not enough to solve all the standardisation issues. Choices have to be made in a number of different areas, relating to the structuring of the management process for standards. This reveals a number of different issues such as:
For example about:
Adoption: how can you encourage it?
Open: I hear about ‘openness’, but what does it actually mean?
Business case: What is the ultimate benefit?
Financing: What does it actually cost? And what are good sources of income?
The quality of the standard leads to problems and dissatisfaction.
Suppliers that want to be certified so they can boost their profile.
These subjects are discussed in detail in Part 2 - The Elaboration:
The activities from the Management and Development Model are carried out in an organisation structure, which often consists of an implementing organisation that receives orders from the governing body. The implementing organisation works with working groups to fulfil the orders. As well as working groups, separate groups of suppliers and/or advisory bodies can be established. The management and development activities can be entrusted to an internal organisation, but for specific tasks, other organisations such as formal standardisation organisations, knowledge institutions or sectoral organisations can be called in. There are different possible legal forms for the internal management organisation, the most common of which is the foundation.
Few figures are available about the revenue and costs of standardisation. Nevertheless, we do know that standards deliver added economic value. The advantages include network effects, preventing vendor lock-ins and lower transaction costs.
Apart from all these major benefits, it is sometimes difficult to prepare a balanced budget for the standard. A standard involves development costs, while it can be difficult to realise revenue from the standard, in particular revenue that is not contrary to openness. A growth model has been prepared for the revenue side. Temporary financing suitable for the start-up phase is not a suitable source of funding for continuous management. Without structural financing, the most obvious form appears to be working with membership fees or paid services. These options restrict the consequences for openness.
The business case for standards is an important subject. Here, based on experience gathered with a standard for the jewellery sector, we outline a three-stage approach to drawing up a simple business case. The outcome is not hard figures, but it does provide a picture of how the costs and benefits are distributed among the various stakeholders.
We all want open standards, but except for a definition we have few pointers as to what an open standard actually means. Based on 10 criteria, including the obvious Open Intellectual Property Rights, there are also less obvious criteria such as Open Change (who decides when a new version should be issued?) and One World (1 standard for 1 worldwide problem). The 10 criteria have been made measurable, to enable a standard to determine its own openness, and to initiate improvement processes.
Due to their relationships with other standards, semantic standards are extremely complex. To achieve interoperability, the first essential requirement is a combination of technical, syntactical and semantic standards. Semantic standards can be recognised in what is known as horizontal and vertical (domain) standards. There is also a distinction between international standards and the ways they are implemented nationally. Standards of this kind are also referred to as agreements or application profiles.
In turn, these standards use vocabularies (or code lists). All variants of standards must be managed. In other words, an international standard is not the end point; in many cases it fails to solve interoperability problems. Many semantic standards are developed outside the formal standardisation organisations (such as NEN and ISO) but they do often have a difficult relationship with formal standards, made so by the potential absence of openness in these standards. At national level, we must often deal with national implementations of international standards, a complex relationship which calls for a strategy. Do any alterations we make apply internationally to the standard, or is it simply a question of adapting the international standard? For that aspect too, strategies have been devised.
In the world of semantic standards, the Semantic Web / Linked Data concepts have been key developments for handling and recording the semantics of the data. These developments are based on a series of often W3C standards.
The value of a standard is to an important degree formed by the number of users. After all: the more users, the easier it is to exchange data via the standard, within a given sector or group of organisations. With that in mind, many standardisation organisations are keen to accelerate the adoption of their standard(s). Various different tools are available for this purpose: communication (information, promotion, etc.), financial (implementation grants and subsidies, funding of pilot projects, offering implementation tools, etc.) and legal (enforcement, for example via ‘apply or explain’). It is important to select the most appropriate tool. This depends on what is known as the likelihood of adoption in the network of organisations (collective business case) and individual organisations (business case for individual organisations).
Over time, the quality of standards will become an increasingly important issue. We often forget that the objective is not the standards themselves, but interoperability. A poor-quality standard will not lead to interoperability, and it often takes some time before we realise that interoperability has not been or is only partially achieved in practice. Research has shown that the majority of management organisations believe that the quality of the standard could be improved and that this will in turn lead to an improvement in interoperability. That makes it important to improve the quality of standards.
Based on existing models, for example from software engineering, a first version of a quality model is proposed in which quality concepts such as effectiveness, reliability and usability are further elaborated. By employing this quality instrument, it is possible to improve the quality of standards.
Gathering wishes and requirements for the standard is an important step in the operational process and can be achieved in a number of different ways, ranging from workshops to online on the web. These wishes and requirements pass through a process, before they can be included in the standard. Version management is a key issue, since too many versions can threaten the adoption of a standard. The operational process of standardisation is often described as time consuming and inefficient. Methods that make use of Web 2.0 applications or the concept of the pressure cooker can make it faster and cheaper to develop standards.
Often when a standard has been in existence for say two years, the need for certification emerges. Suppliers are keen to commercially exploit their implementation of the standard and certification can be a valuable tool. The management organisation itself could offer certification with a variety of objectives (promoting interoperability or adoption or financing) each of which could have different effects and which are not always easily combinable.
Certification is complex and the best advice is to start with validation and drawing up a list of supplies who use the standard. Validation can also be used to check conformance with a standard but enjoys a lower threshold.
Offering support to implementations is the consequence of strategic and in particular tactical choices relating to adoption and quality among others; other best practices subjects.
Hence a shorter description of possible solutions.
The above statements also apply to communication activities, but these activities must never be underestimated. At the end of the day, the essence lies in ensuring that the standard is used in practice, and this means that the standard must enjoy a high level of awareness in the professional field. Such awareness does not happen by itself.
6. In conclusion
One important subject which often remains little discussed in terms of knowledge of standards is the structure of the development and management process. BOMOS is an attempt to provide a guideline for structuring a development and management process within an organisation. It places additional focus on how the development and management can be achieved in an open manner.
The document also explains that the development and management of standards is a complex issue, comprising numerous different tasks which may or may not have to be implemented, and which can be implemented in different ways, depending on the context of the standard.
The document also shows that openness has numerous different aspects, more than can be achieved based on the definition of an open standard. Krechmer’s 10 points are sometimes forgotten in practice, leading to a great deal of concealed closedness. Based on these points, an attempt can be made to introduce a very open structure to development and management. In that process, the ten points, combined with practical tips, are above all suitable for initiating the relevant thinking processes.
The aim is and remains a sustainable standard that contributes to interoperability. Sustainability can only be achieved if the structure of the development and management process is of high quality. This document contributes to raising the level of the development and management of standards, thereby creating more sustainable standards. At the end of the day, a sustainable standard is an open standard that is sustainably managed!
To conclude part 1, we offer three concrete tips:
Describe the fulfilment of the package of tasks on the basis of the BOMOS activity model. (BOMOS Compliant)
Create continuity in the development and management of a standard by:
Ensuring a stable/structural financing model.
Entrusting the core tasks to a structural not-for-profit organisation.
View openness as a means of raising quality and simplifying adoption: use the 10 points from Krechmer for identifying improvements in openness.
Just like a standard, BOMOS itself will never be finished; based on new experiences, new ideas can emerge. And there are plenty of other possible opinions on the subject. At the same time, this document could raise questions when you start to use it. We hope to establish an active BOMOS community that will play a role in this process and will ensure that new BOMOS Supplementary Modules are made available.
