Development
This section unpacks the ‘development’ stage to open standard development, with focus on how you can work in the open with a wide community to create and test your open standard
Last updated
Was this helpful?
This section unpacks the ‘development’ stage to open standard development, with focus on how you can work in the open with a wide community to create and test your open standard
Last updated
Was this helpful?
In our research, ‘’, we found that developing a successful open standard means involving a wide variety of people and organisations.
Having contributions from people with different skills and backgrounds can bring constructive tension during the development of an open standard.
To create a successful open standard, consider involving:
researchers to continue research from scoping and starting, including how adopters find and use the standard and data produced using the standard
developers, data modellers and data experts to create the technical documents which will make up the standard, including schemas, specifications, models, and vocabularies
managers and others in positions of influence as early adopters and champions for the open standard
domain experts who understand the areas, sectors or industries the open standard will operate in, and provide expertise
business analysts to capture and reach consensus on the needs of representatives of the industry or sector
community engagement managers to keep in touch with the people and organisations involved with the open standard, data, or related products
project managers and product owners to coordinate and facilitate development
standards developing organisations to provide expertise in open standards development
It is important to ensure that everyone is clear on their role and responsibilities when developing a standard. We've identified and documented some key roles involved in developing a standard, including the .
The shares lists of nationally or internationally recognised who may be able to support your standards development.
In ‘Scoping and starting’, we recommend choosing a development infrastructure to support the development team and share progress with the standards community.
For the development infrastructure, consider a repository or platform that:
allows public sharing of the open standard so you are developing in the open
allows public sharing of test data or test models
supports automated testing where needed
tracks changes so you have an audit trail and can remove changes if needed
supports contributions from a variety of people so you can accept community contributions or fixes if needed
Your development infrastructure should also include tools and platforms that:
support creating guides, resources and other documentation in the open
allow participants to report bugs or issues in the open
help you keep in touch with your community during development
make it easy to find, use and share data developed to test the standard
It is useful to consult your development team or the owner of the standard as they may have preferences for tools and platforms.
With your team assembled and development method and infrastructure in place, you can start developing your open standard.
As open standards can be mixed and matched, your open standard may use features from each of these types to achieve the intended impact.
For example, development may involve turning conceptual models (described in ‘Scoping and starting’) into technical documents like specifications, schemas, and models.
Other ways of turning the identified problem or need into a reusable agreement include:
agreeing and clearly defining words that will be used in standards containing shared vocabularies
In ‘Scoping and starting’, we recommend making testing part of the development plan.
Testing helps make your open standard more robust, which can improve trust and confidence and result in increased adoption rates.
Regardless of the development method, testing should be regular and rigorous.
Testing should cover:
the open standard
data produced using the standard
tools produced to support adopters, including developers, data publishers, and data users
resources like code libraries and websites that are used with the standard
integration with other standards – for example, where vocabularies are reused
a variety of likely scenarios adopters could encounter in real-world situations
Where possible, automate testing and share test models with the standards community for review and feedback. If early adopters are implementing pre-launch versions of the standard, they may be able to provide useful scenarios for testing.
Open standards are often technical documents specific to a particular technology or area of expertise.
To make standards easier to find, adopt and use, you can create guides and resources for different audiences.
An open standard for data will affect more than data users and data publishers.
When creating guides, consider who will use them, the language you use must meet the needs of the potential users.
It’s useful to ask:
How do we communicate the standard to each group?
Which metaphors are useful in explaining complex concepts?
How will each group find and use the standard and guides?
Do documents need to be translated into other languages?
Should documents be available as hard copy, online, in accessible formats?
Recognise that open standards have a varied audience and aim to provide additional support through guides and resources to support adoption. For a different perspective, encourage early adopters to share their experiences with others.
Progress and activity should be shared regularly with stakeholders.
These are the people and organisations who will use or be affected by your open standard, data produced using the standard, or related products and services.
Sharing your progress may involve:
working in the open to keep in touch with your community
regular contact between participants to focus on important issues
tracking issues by collecting comments and resolving issues
producing regular drafts that can be reviewed by the community
clearly communicating milestones to provide opportunities for feedback
sharing test resources such as plans, test data, or test results for review
You can share progress online or offline depending on the needs of your stakeholders.
Typical outputs at the end of the development stage include:
working versions of the open standard in the form of stable machine and human-readable versions of the standard
guides and resources that explain how to use the standard, including tutorials for learning, explanations to improve understanding, how-to guides for step-by-step problem-solving and references, which could be the standard in human-readable form
translations of the open standard, guides and documentation and website content (if supporting multiple languages is necessary)
test suites of data or models that both conform and break the standard to demonstrate scenarios adopters will encounter, handle or report
tools for converting, validating and viewing data that uses the standard
code libraries for processing or analysing the standard
early adopter experiences which can provide guidance to other stakeholders and feedback for the review stage
development infrastructure for the development team to develop the standard and share progress
Depending on the being developed, this can mean drafting guidance, creating a dataset of shared vocabularies, or creating a format for data exchange.
creating user stories (short, simple descriptions of features) when using an
drafting documents using rules from a formal standards organisation — for example, the BSI’s
designing standards to exchange data using vocabularies like , , or
In our research, ‘’, we found that a successful open standard is one that has been tested and implemented.
Your audience may include people and organisations involved in policy, legislation, technology and more. Read ‘’ to understand who open standards affect.
This may mean using repositories like , online reports, paper reports, noticeboards, and in person at workshops or other events. Progress updates can be shared at fixed stages or throughout the development process.
Review the ’s method to understand how a formal process works
See how uses an agile process: ‘’