BOMOS (Beheer- en OntwikkelModel voor Open Standaarden) is een hulpmiddel
van en voor de standaardisatiewereld. Dit deel bevat een aanvullende
module voor stelsels. Stelsels vallen buiten scope van het de basis van BOMOS,
het Fundament. BOMOS is immers allereerst voor het beheer van standaarden beedoeld.
Maar BOMOS kan wel voor stelsels toegepast kan worden omdat de beheerpraktijken
van standaarden en stelsels veel overeenkomsten heeft.
Status of This Document
This is the definitive version of this document. Edits resulting from consultations have been applied.
The BOMOS Substantiation discusses the components that make up BOMOS. In addition to operational, tactical and strategic layers, it also deals with implementation support and communication.
The BOMOS documentation is divided into various sections (see BOMOS-structure).
1.1 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?
Thes 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.
BOMOS Supplementary modules: Linked Data en Stelsels (this document)
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.
The Substantiation (this document) 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 substantiation 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. Structure of BOMOS for the management of trust frameworks
2.1 What are trust frameworks?
Trust frameworks or in short ‘frameworks’ are close forms of cooperation between different stakeholders from business and industry, government and research, that supply products or services based on predetermined requirements.
Trust frameworks make clear to all participating parties the rules of play for the interaction between them and for the supply of a product or service. For the users of those services, they offer freedom of choice and a quality guarantee. For example: you can choose which party will assist you in submitting annual reports to the Nederlandse Bank via SBR, and all approved parties do what they have to do.
2.2 Contents of a trust framework
The heart of a trust framework consists of the rules of play that every supplier or other stakeholder must comply with to take part or to supply a product or service.
On the one hand these rules of play offer a guarantee to the user that the product or service can be securely and reliably used, while on the other hand they are mutual agreements that guarantee the success of the cooperation. Elinor Ostrom in the book Governing the Commons, describes the conditions for successful cooperation with regard to scarce common resources (otherwise known as the commons), such as the management of water wells. These principles can be recognised in cooperation within successful trust frameworks. These principles are:
Commons need to have clearly defined boundaries in terms of shared functionality/resources and a homogeneous user group.
Harmony and balance in benefits and costs for all stakeholders.
Everyone can contribute to improvements.
Monitoring of all stakeholders (based on transparency).
Graduated sanctions on violation of agreements are in place and implemented.
Differences of opinion can be quickly and effectively solved.
Participants in the framework have the right to self-governance.
Use systems of frameworks to keep individual frameworks simple.
These principles are the foundation of agreements and rules governing the following aspects that recur as elements of a trust framework:
- Information about rights and obligations of the stakeholders: such as definitions, liability, governing bodies, management and distribution of tasks.
- Financial: the management of a trust framework and organising its management cost money: what agreements have been reached on who pays for what?
- Operational: who solves incidents? Are operations carried out subject to a label or brand? Take for example communication, brand management and agreements on operational processes.
- Frameworks of standards: what requirements must suppliers products/services meet?
- Architecture and technical aspects: for example technical standards, use cases and interface descriptions.
The Medmij trust framework (for more info: see Medmij) makes it possible for end users to securely and reliably share health-related information in their personal health environment with care providers such as a dispensing chemist or hospital. The end users select a party to supply the health environment and hospitals select a party they connect to the Medmij network. The trust framework provides the conditions for secure and reliable exchange and the technical facilities for practical operation. The scope of the trust framework is the area in which the service provider of the end user cooperates with the service provider and the care provider. There are multiple service providers on both sides and thanks to the framework, the complexity is restricted and the services and products work well together.
This layout is also known as the ‘four corner’ model. In this case, via their own broker, end users are connected to other participants in the framework. Remember: there are also other possible configurations within a trust framework, such as a central facility (3-corner) or an additional branch for example for transaction-driven accounting information (5-corner).
2.3 How can BOMOS be deployed as best practice for the management of trust frameworks?
Trust frameworks cannot existing without standards... Standards are the foundation on which interoperability and cooperation are made possible. It appears to be a combination of standards with one important addition: in the case of a framework, agreements are also reached on operational aspects of cooperation for the supply of a product or service.
To a considerable extent, the management of a trust framework and of a standard are closely related, making BOMOS ideally applicable in this broader scope. The BOMOS activities are also clearly recognisable and usable within frameworks, with the occasional exception or deviation. As with the management of a standard, in trust frameworks there are activities aimed at organising the operation, further development and management of central provisions, support for connecting to the framework and promoting use.
Based on this method, in collaboration with the ICTU, a tool has also been developed based on the BOMOS assessment, but specifically intended for trust frameworks. This can be obtained via Logius: https://logius.nl/contact
Experience has now been acquired in practice with the implementation of this specific BOMOS assessment for trust frameworks. These analyses clearly reveal the value of having a trust framework to provide structure, definitions, activities and tips and tricks. BOMOS supplies the common language and promotes understanding of each other’s roles and perceptions, thereby enabling constructive discussions.
The result of any assessment helps in the short term to arrive at a target for professionalising management, as well as identifying the steps that need to be taken in that process. If you conduct an assessment together with the stakeholders, you automatically generate the support you need to put the changes into effect.
The BOMOS foundation can be ideally used for structuring the management of new trust frameworks. In that situation, BOMOS helps to create a clear picture for a programme or for a client of the activities that need to be organised, and why. This picture then helps in setting the priorities for organising management activities and estimating the necessary resources.
It is essential to reach structured agreements between the various stakeholders in a trust framework. These harmonised agreements are reached via the governance of the framework. This requires the description of the organisation structure, and forums for decision making and roles.
The organisation structure clarifies the forums that exist in the framework of decision making and the types of decisions that are taken in each forum. The structure also clarifies how tasks, relationships and communication between the groups are safeguarded. This does however essentially require a distinction between a governing body and execution.
Agreements on how decisions are taken, how to become a member of a decision-making forum and the scope of governance can be elements of the trust framework itself, but can also be outside the trust framework, in the form of an institutional decision or covenant.
The role of watchdog is an additional role over and above the roles within standards: what organisation has been put in place to assess whether agreements are actually complied with, and what are the procedures and means of intervening if this is not the case. It is important that this task be occupied independently to avoid a situation in which the fox is set to guard the henhouse. This role is also responsible for taking appropriate measures in the case of non-compliance.
2.6.1 Vision
The aim of any trust framework must be clear and concise. At its heart, the mission of any framework is the ‘wish to solve’ a problem that is too complex and too large to be solved independently and which requires the assistance of other organisations. These organisations join forces to arrive at the solution and to reach agreements on the approach to be followed. This is expressed in a positive business case. This mission and vision are reflected in the communication released by a trust framework and create a bond between the parties active within the framework.
2.6.2 Funding
For those parties wishing to play an active role within a framework, it must be financially attractive as reflected in a positive business case if the framework is to have a future. This applies to private, public-private and public frameworks. The same business case is required to account for the fact that a management organisation needs to be established and funded over a longer period. The management organisation can be financed by the stakeholders, members of the framework or centrally, by the owner.
Roadmapping (additional activity)
Making and maintaining a multiyear roadmap brings together the strategic choices and the steps to be followed in arriving at the objective. It helps with adoption because the stakeholders know when specific functionalities will be delivered, which makes it attractive to use the products of the frameworks or to fulfil a role within the framework. Elaborating and upholding a common goal in the form of a roadmap also generates support. It describes the concrete steps that must be taken to bring about the vision.
2.7 Tactical
2.7.1 Community
Within a trust framework, the term community is less commonplace but there are organisation forms that operate at tactical level, but more in the form of an expert group or working group. These groups are involved in substantive changes to a trust framework and in drawing up recommendations on innovations and architecture. The governance of a framework issues instructions to establish an expert group or working group, with a clear assignment.
The composition of the working group will depend on the nature of the assignment. There are working groups that consist only of representatives of suppliers, but others are a combination of users and other stakeholders.
2.7.2 Adoption and Recognition
To be active in the government domain, it is useful to have a formal status for the framework, in other words an obligation or recommendation to make use of the products of the framework. Another key factor is the development of critical mass in terms of use. This is often a chicken and egg problem in which many parties wait to see who will take the first steps, before themselves joining in after large implementing organisations for example make the switch. To ensure that these developments are well organised requires a strategy with support from the stakeholders. This in turn increases the likelihood that suppliers will be able to draw up a positive business case and that new participants will join in. Governance is responsible for adoption.
2.8 Architecture
Architecture can be viewed in different ways or from different viewpoints (see Archimate): from the point of view of strategy, business, the applications or the underlying components. This variety of viewpoints often relates to the different roles the parties play within a a trust framework. In the ideal world, all those roles are described but in practice there are often differences in the level of elaboration in different frameworks. Having access to these models makes it easier to communicate together and to effectively estimate the impact and opportunities offered by changes. It also lowers the threshold for new parties wishing to become part of the trust framework.
Interoperability also plays an important role within a trust framework, as reflected in the attention paid to the architecture of the technical interfaces between the various stakeholders. Architecture also refers to the choices about which (technical) standards should be used within a trust framework, by the various participants.
Operating and jointly defining the architectural principles for a trust framework (see NORA) is a valuable tool when it comes to assessing proposals for change.
A trust framework is the foundation that enables secure and reliable data exchange between different parties. It is also essential for the governance to have a clear picture of the situation with regard to threats and risks to the framework itself. What could go wrong, what should I do to avoid potential risks, and if a threat does become reality: what steps should I take and who should I reach out to?
2.9 Operational
2.9.1 Wishes & Requirements
Just like a standard, a trust framework also develops by meeting the wishes and requirements of users. This is yet another key element of changes that make a structural contribution to the business case, legislation and regulations and measures for facing up to (future) threats to security and reliability. To manage all these aspects successfully, a trust framework contains rules on how changes must be initiated, descriptions of the decision-making process and how those changes are integrated in the trust framework and eventually implemented by the stakeholders. One key aspect in the implementation of changes in a trust framework is safeguarding continuity: ideally, you avoid scenarios in which changes are rolled out via a big bang approach; instead they are rolled out at their own pace. This can be organised by facilitating some form of backwards compatibility.
2.9.2 Documentation
The trust framework is freely available and accessible. This prevents the outside world viewing with suspicion what goes on within a trust framework as if it were a cartel. In the ideal world, the documents used are also publicly available. Transparency helps in generating support.
2.9.3 Operational handbook (additional activity)
To a considerable extent, a trust framework consists of agreements on mutual cooperation. This deals with such issues as how you respond to wishes and requirements about the change process and how you can join, how disruptions and incidents are reported and corrected, the service windows of the various stakeholders and the reporting requirements to each other and to the governance.
2.10 Implementation support
The extent to which implementation support is provided by the trust framework depends on the distribution of tasks between the participants within the framework and the framework governance organisation. It is logical, for example, that a party that enters into a contract with a supplier calls upon that same supplier for support in implementation (connection) and use. Within the framework itself, the management organisation is tasked with playing a role in issues relating to the interpretation of the framework specifications and for example connecting to the network.
2.10.1 Validation & certification
There are trust frameworks that provide validation tooling to support participants in testing their implementation. It is essential that the suppliers be involved in the realisation and assessment of these tools to avoid inconsistencies and uncertainties in the specifications only emerging at a late stage (during actual realisation).
With regard to the inspection and certification, these are normally the task of the party that fulfils the role of watchdog. The watchdog observes to determine whether the agreed framework of standards has been correctly implemented by the supplier. There are clear agreements on when the supplier should actively inform the watchdog to carry out an assessment. For example changes to processes that relate closely to the framework of standards.
2.11 Communication
2.11.1 Promotion
The advantages offered by a product or service from a trust framework must be made clear to the broadest possible public. Operating a common brand or label can be useful in promoting the recognisability of the service. The trust framework contains rules on drawing up generic expressions, brand management, what the management organisation should do and how much leeway suppliers are allowed. The suppliers are responsible for their own marketing and activities to expand their own market but are subject to the rules of the trust framework. The management organisation has a role in promoting the benefits of the framework but not of the individual services or products of the suppliers that make up the framework.
2.11.2 Publication
This includes maintaining a site that provides information about the trust framework, the use of social media and the sharing of information with specific user groups.
2.11.3 Complaint handling
As well as submitting a complaint to their own supplier, users may also feel the need to report their complaint to an independent party. A complaints committee can issue a binding judgement in situations where the two parties fail to arrive at an agreement.
