A good starting point when developing an open standard is a shared understanding of why it is needed and what it will cover. The canvas is a way of documenting and sharing that understanding
Last updated
Was this helpful?
The is for anyone thinking of using or developing an open standard. The canvas will be of most interest to organisations, people and groups that are:
using or developing an agreement based on sharing data
exploring how an open standard for data can solve their problem
interested in sharing data with at least one other party
The canvas is a single view of the pillars that support your open standard: the problem, solution, resources, risks and impacts. It outlines how your standard delivers benefits to stakeholders and what you need in order to begin using or developing the standard.
The is based on the and licensed under a . Please attribute The Open Data Institute.
The is not:
a detailed document: the canvas is high-level so you can quickly spot gaps and clarify assumptions
a roadmap: you can use the canvas to outline and share the initial solution to the problem you want to solve. The canvas will help you develop a roadmap during the later scoping and starting stage
a complete guide: the canvas focuses only on key areas to get you started so you can prepare more detailed documents as needed
The canvas details the most important things to consider when you start developing an open standard for data.
The canvas is built around three sections:
Why the standard is necessary
Who the standard will affect
How the standard was or will be developed
In the sections are nine building blocks. These are the pillars that support the open standard for data. The canvas covers:
the people and groups the standard will deliver benefits to
how they will use the standard
how you will develop the standard and measure its impact
Expect to complete the canvas at least once and update it as you clarify each section. It’s fine to use placeholders and update these as you make progress.
Step one: Start by outlining the vision – a single question that clarifies the vision for the standard and how it solves the problem. Try writing this as a short and simple what-if question.
Step two: Now complete the other high level details: the standard’s name and the organisation’s name. Use placeholders if necessary.
Use the 'Why' section to make the case for the standard – the information here will be useful in building a business case, engaging stakeholders and demonstrating you have done your research on existing standards.
Step three: Start with 'The standard' pillar to say what the open standard offers and what type of standard it is.
The standard could be a guide, a shared vocabulary or might provide a format for sharing and using data. Keep this section as concise as possible and make sure it aligns with the vision.
Step four: An open standard is developed to solve a particular problem. Use ‘The problem’ pillar to clarify what the problem is.
It’s a useful way to summarise a problem that might not yet have been solved.
Step five: Use ‘The solution’ pillar to share why the standard is the right solution for the problem.
With the problem clearly stated, it’s useful to say why the standard is a better solution than others currently available.
Step six: To tie the standard, problem and solution together, use ‘The use case’ pillar to share how the standard will work.
This section should clarify how the vision will become reality.
Successful engagement with the right people is essential for a successful open standard for data. Use the 'Who' section to establish who will be affected by and use the open standard. Say how you expect to communicate with them.
Step seven: In the ‘Key stakeholders’ pillar, make a note of the key stakeholders. These are the people and organisations that will own, fund and develop the standard as well as those who will share and use the guide, vocabulary, format or data produced.
Step eight: Next, share who will be the early adopters. These will be the people and organisations to first use the standard and likely to be the most involved in the development process.
Keep the ‘Early adopters’ pillar as specific as possible by naming the people and organisations.
Step nine: The people developing the standard will keep in touch with early adopters and other stakeholders. In the ‘Engagement’ pillar, it’s useful to consider where stakeholders can be found: Online? Offline? At networking events? In workshops?
At this stage, the first six pillars describing the nature of the standard ('What'), and 'Who' the standard is aimed at have been completed, leaving the final section – 'How'.
These three pillars focus on impacts, risks and resources – what benefits the standard will bring, what could derail the standard and what’s available to help the standard deliver those benefits.
List the strongest benefits, the major risks and known resources. Keep in mind that unexpected benefits, new risks and unknown resources may come up as you assess or develop the standard.
Step 10: In the ‘Key impacts’ pillar, share what will change once the standard is developed and adopted. What benefits will stakeholders see?
Step 11: Next, share known risks in the ‘Major risks’ pillar.
These should focus on things that could derail the development or adoption of the standard.
Include technical, legal, social, environmental, or political challenges or weaknesses. Where possible, briefly describe how risks will be mitigated.
Step 12: Open standards aren’t developed in a vacuum. Developing open standards requires resources like funding, existing tools, support for legislation, and more.
Use the 'Key resources' pillar to share the main resources that the open standard will need to deliver the key solutions.
Once you have completed the canvas, you will have an overview of your open standard. This can guide the development or adoption of the open standard including any additional documents you need to prepare or gaps in your understanding that need to be filled. You will now have a single page overview to guide the development or adoption of the open standard, prepare additional documents and investigate gaps.
Sharing the canvas for comment either as a public document or directly with key stakeholders and early adopters will open you up to useful feedback early on.
It’s worth returning to the canvas as you progress to keep your development on track.
This was the question that triggered Google’s (GTFS) and provided the vision for the standard
The above description of makes it clear that to deliver public transport information easily, the focus must be on making transit information work together so it’s easy for public transit agencies to supply and developers to use.
From , the problem GTFS is trying to solve here is information not being consolidated, which makes it hard to find transit directions in unfamiliar cities. This supports the vision and accords with the description of the standard.
Here, the key reasons why GTFS is the solution to the problem are shared: the public uses navigation products to get directions, so it makes sense to shift the focus here.
The GTFS example is explicit about how the key solutions will work: transit agencies will produce feeds that transit developers can consume for a variety of applications and processes.
For GTFS, there are two main groups to consider besides Google, who are the primary owner, developer and sponsor of the standard.
The initial GTFS development had two main organisations involved in the alpha or first phase of development.
GTFS began with workshops (offline) and migrated to Google Groups (online).
For GTFS, this outlines the benefits for key stakeholders as well as the benefit for its key stakeholder – the general public.
From , the main risks were one stakeholder gaining all the benefits (social), keeping file formats simple (technical) and ensuring transit data was open (legal).
The above list reflects the key resources for the alpha or first release of GTFS, where Google provided the funding and TriMet Portland the expertise.