When an Energy Performance Certificate (EPC) is produced for a building, a lot of useful data about the building is collected by the energy assessor, and the Energy Performance of Buildings Register is the place where this data is stored. This data is used in research and policy making to improve the energy performance of the UK’s building stock, and following a hiatus from 2017-2019 while some data licensing issues were resolved, a set of energy performance data is again regularly published by the department on Open Data Communities.
Until now the operation of the register has been outsourced and run as 4 separate services:
- England & Wales Domestic Register
- England & Wales Non-Domestic Register
- Northern Ireland Domestic Register
- Northern Ireland Non-Domestic Register
Rather than re-procure these services as outsourced contracts, The Ministry of Housing, Communities and Local Government (MHCLG) has decided to bring ownership of the register service in-house. We will also consolidate these 4 registers into a single register for England, Wales and Northern Ireland (Scotland still has its own EPC register).
This is the first time MHCLG has taken the running of a digital service back in-house and redeveloped it from the ground up, following the user-needs driven principles of the Digital Service Standard. This makes it a significant step in our department’s digital transformation journey.
In the future we will improve the usefulness of the data published by linking the energy performance data with Ordnance Survey’s unique property reference numbers (UPRNs), which are being licenced as open data from July 2020. This will make it much easier for data users to link energy performance data with other datasets about buildings.
Beta phase “inception”
In October 2019 development began on the beta phase of the new service. We brought together a new multidisciplinary agile team and dedicated the first couple of weeks to a “project inception”. During this time the team:
- reviewed the outcomes from the discovery and alpha phase projects
- familiarised ourselves with the wider landscape of EPCs and energy performance data
- ran a series of workshops with as wide a range of stakeholders as possible, to get a deeper understanding of user needs
- came up with a set of “known unknowns” that would need further research and exploration during the beta build
- made key initial technology and architectural decisions
We chose to use common and widely-understood free and open source technologies that were already known to most of the team. These include the Ruby programming language, Sinatra web application framework, and PostgreSQL database. These choices should help reduce barriers to bringing new people on to the team in the future.
For hosting, we chose to run the new service on GOV.UK Platform as a Service. This allows the team to spend less time managing low-level technical infrastructure and more time delivering the core register service. It should also make the service easier to maintain in the future.
Beta phase development approach
Since inception, we have been building out the new service following Government Digital Service (GDS) guidelines for agile software development and industry best practice. Our working practices include:
- coding in the open – we use Git for source code version control, and all of our code is open source and can be found on the communitiesuk GitHub organisation
- writing loosely-coupled software that follows the clean architecture principles
- pair programming and test-driven development as standard. This is essential for us to be able to do trunk-based development
- trunk-based development – rather than developers working on code “branches” that are peer reviewed prior to merging into the “master” branch, pairs of programmers are empowered to push their changes straight to “master”
- continuous deployment – once a code change is pushed to master it is automatically released through a pipeline to production, as long as the automated tests pass successfully along the way (we currently release code to production up to about 40 times a day)
As with any project, we had to invest time upfront in doing the groundwork of setting up infrastructure and deployment pipelines, bootstrapping and connecting applications, and developing a security and authentication strategy. Now this groundwork is complete we are in a good position to quickly develop new features and iterate what we already have based on feedback from users.
To find out more about the work at MHCLG digital, subscribe to our blog.