Introducing the Data Design team
Mike Rose — 2024-05-10
What’s that you ask? Where has that come from? Is this a bunch of new people joining the programme?
Don’t worry, it’s a logical update to the name of who you might know as the Data Standards team. For a while now we have been thinking about what the team offers and how our team name doesn’t accurately reflect that offering.
A data standard is an output from a process looking at the data that is needed for planning. We run that process. In short…
- Someone identifies a need for data for planning purposes (a planning consideration)
- We screen that consideration to understand what it is specifically
- Is it driven by a legislative need?
- Is it driven by a policy need?
- Is it driven by something else?
- We then research the consideration to understand it fully
- What is the specific driver? What exactly does it say?
- Is there data already available? Where does it come from? What does it look like?
- What is the planning need? How will the data be used in the planning process? What do data consumers want?
- Then we look at whether we need to co-design a specification for the data (a specification is the data model, the data we think we need, documented in a manner that allows others to understand)
- Finally, we decide whether that specification needs to be formally / legally mandated as a ‘standard’ under the Levelling-up and Regeneration Act (LURA) 2023.
This whole process (which obviously I have simplified) is us designing the data that we need for planning.
This process and therefore this team, as reflected by its current make up, needs to have a series of different skill sets. We need to understand the technical aspects of data, building good data, displaying and sharing data but also we need to understand the legal and policy elements of planning and data too as all of these factor into designing data.
We have noticed, in thinking about our process, confusion around roles across the programme. For example, we use the term ‘platform’ to describe a capability and a team. We also have (had) a Data Standards team and a Data Management team, which are often conflated and shortened to the “planning data team”.
We wanted to try to clear that confusion up and we think our name change helps.
The Platform team is accountable for maintaining and running the capability of planning.data.gov.uk.
The Data Management team is accountable for taking the specifications and standards (after the Data Design team has designed them), sourcing that data, and getting it onto the platform (capability) for people to build services on. The goal is to get to production-quality data - high quality data that is from authoritative sources.
The Data Design team requires the platform (capability) to test potential specifications and standards to co-design them. But unlike the Data Management team, which delivers production-quality data, our process will only produce indicative or experimental data - data that is good enough to test standards and start building and testing services but not yet good enough to use in production.
By being clear about our name, it’s easier to see the role we play across the programme. We are applying the “Ronseal Test”.
For example, local plans clearly need a lot of data to be produced. To articulate the role of ‘data standards’ in this is hard, as potentially a lot of the data used (for example, flood data and road data) will not need a DLUHC defined data standard.
However, it WILL need DLUHC to design processes and approaches to that data to ensure we understand what we are asking of LPAs and other stakeholders when using that data to speed up local plan making.
What this means for the team is that over the next few months we will be clarifying roles and developing capacity to do more data design activities:
- We want to be able to move through the backlog of planning considerations we have using our data design app (which codifies our process).
- We want to be able to gather data that could seed a future specification - this could be by scraping LPA websites or processing LPA pdfs. This would not be gathering ‘finished’ data for the production platform (capability) but gathering test data so we understand the specification better.
- We want to be able to build quick alpha demonstrator services on that seed data so we can illustrate the benefits of data provision to LPAs [in this context calling them alpha means unsupported and likely to be turned off].
- By defining our remit more clearly, we also want to develop stronger links across the programme. For example we want to use the skills and capacity of the communities team, the platform team and others in the right way.
- While we are doing this we want to be developing the expertise of the data design team and the wider programme - capturing knowledge and transferring it into DLUHC capability.