First steps

This section unupacks the ‘first steps’ stage to open standard development with focus on useful considerations for creating a standard before starting development

Frame the problem

Before you create a new open standard, you must understand the problem the standard will solve or need it fulfils.

Framing the problem means being clear about the problems currently being experienced, the benefits an open standard will deliver, who will use it, who will be affected by it, and why it is the right solution.

Open standards for data are most useful when many potential users work together to support the production and use of data in repeatable and reusable ways.

Start by commissioning a proof of concept to explore options, or work through a discovery phase to investigate the problem and potential solutions. The solutions may include using or extending an existing standard.

Framing the problem will mean engaging with people and organisations who have the same problem or existing open standard communities. Engage early and continue through developing or adopting an open standard. When adopting an existing open standard, engagement can lead to new relationships and improved community support. When creating a new open standard, engagement can significantly impact the success of your open standard by helping to build your standard’s community.

Identify the type of open standard that will deliver the most benefits, or what features might be combined from each.

We identified three types of open standards for data that can be used to:

  • share vocabularies and language using common models, attributes and definitions, with outputs like: registers, taxonomies, vocabularies and ontologies

  • exchange data within and between organisations and systems using common formats and shared rules, with outputs like: specifications, schemas and templates

  • provide guidance and recommendations for sharing better quality data, understanding processes and information flow, with outputs like: models, protocols, and guides

Understand the ecosystem

‌When framing the problem, it is useful to understand the ecosystem the standard will operate in. The ecosystem is the people and organisations who produce, use or share data, the relationships between them and the existing data infrastructure.

Understanding the ecosystem can help clarify the problem and position of the open standard. A tool like an ecosystem map, can help you understand where and how data is produced and used, and what can be done to support better quality data.

You can combine the ecosystem map with the open standard for data canvas, itself designed to give a single view of the pillars that support your open standard: the problem, solution, resources, risks and impacts.

Working through the canvas will help you outline how your standard will deliver benefits to stakeholders and what you need to begin development.

Part of understanding the ecosystem is checking for existing standards or other tools that might solve the problem and removing the need to create an open standard, or provide the building blocks for a new open standard.

A new open standard can build on existing standards in many ways including:

  • extending the features available – for example the Initiative for Open Ag Funding, which aims to end hunger and food insecurity using better quality data, built on the International Aid Transparency Initiative (IATI) data standard to meet its goals

  • using common models or shared vocabularies like identifiers or code to ensure it works with existing standards – 360Giving, the standard for grant making in the UK, uses codes from a number of authoritative and established registrars including the UK’s Companies House

  • adopting open formats that describe how data is structured for sharing or storage like CSV (comma-separated values), JSON (JavaScript Object Notation) and XML (eXtensible Markup Language) over proprietary formats – the Fiscal Data Package standard for government budgets uses the JSON format for packages and plain text CSV format for data files

Identify the community

Framing the problem and mapping the ecosystem includes identifying who will use and be affected by the open standard.

In our research ‘User experiences of open standards for data’, we found successful engagement with the right people is essential for a successful open standard that supports better quality data.

Stakeholders can include:

Decide who to work with

Once the standard’s community is identified, decide who the early adopters will be. These are the people and organisations who first use the standard and are likely to be involved in the scoping and development process.

Deciding who to work with is an important step as early adopters will:

  • help shape the standard through feedback and requests

  • be advocates and ambassadors for the standard which can help adoption

  • help test the standard in real-life situations to ensure it is robust

Early adopters may include people who can engage with and persuade executives, management and other decision-makers to contribute to the standard.

In our research into user experiences of open standards for data, we discovered anxieties around politics, monopolies and control of standards. Engaging early and often with early adopters and clarifying who will own and maintain the standard can help to ease these concerns.

Consider sustainability

Creating and sustaining a standard is a time- and resource-intensive – but worthwhile – activity that combines elements of technical activity, stakeholder coordination and community engagement.‌

Ensuring sustainability can include securing funding, resourcing development, testing and support, creating documentation and guidance, and engaging in activities to promote your standard, including advocacy, promotion and other forms of engagement.

Where possible you should adopt or extend an existing open standard rather than create a new one because it can reduce the time, effort and cost involved.

Where a new open standard is necessary, consider collaborating or fundraising with people and organisations with the same problem or need. Pooling your resources builds the community around your standard and can reduce the cost of development for the organisations involved.

You should consider creating a lightweight standard that is tested, robust and focuses on the core features to solve the problem or meet the need. In our research ‘User experiences of open standards for data’, users suggested that a successful open standard is robust and simple. Simplicity also makes the standard easier to manage.

‌Once your standard has been developed, tested and launched, it may require updates to keep it relevant. Stakeholders can make requests for new or updated features, errors may be unearthed, or changes in the wider landscape (like new legislation or resources) can prompt a review of the standard.

Stakeholders may also need help with adopting the standard and guidance, or other documentation may need to be refreshed. Take into account the level of technical expertise adopters will have and how much support they will need.

‌Consider how changes to the standard will be managed by deciding what the governance process should be and how frequently the standard will be updated.

Governance can be lightweight or more formal. When choosing a governance process, balance the expectations from the people and organisations using the standard, with the resources available.

Choosing a lightweight governance process to start with could make your standard more sustainable. See ‘Managing change in open standards’ for more on the governance of open standards.

Include advice for data publishers

Open standards to exchange data help data publishers produce and share new data.

The data is used by a variety of people and organisations, including people and organisations who use data and develop tools and services for research and more.

To support a variety of stakeholders, consider advice for data publishers that makes data better quality and more accessible for data users, including:

  • how frequently data should be published so that data is up-to-date and useful – transit agencies sharing public transport data using the General Transit Feed Specification (GTFS) are encouraged to publish fluctuations to timetables, or trip updates, in real time

  • sharing publication schedules which sets out how frequently data should be published – guidance for Brownfield Site Register Open Data Standard, the national data standard for brownfield land registers, advises local planning authorities to share data annually

  • sharing how up-to-date data sets are so that data users can determine if the data is useful for their purpose or update their versions – data publishers can provide publication dates as part of a data release using the Open Contracting Data Standard

  • advice on where to share data so that it is easy to find – organisations using the International Aid Transparency Index (IATI) add data sets to the datastore which combines all data published to the standard for easy querying

  • using similar mechanisms to share data so that developers can find and use data that complies with the standard more easily – Open Banking, the standard for creating, sharing and using banking data, developed an Open Data API specification so providers like banks could easily and securely share data with developers and other parties

PreviousThe standards lifecycleNextScoping and starting

Last updated