Cloud adoption at DVLA – in the beginning
Cloud adoption is now mainstream, but making the move to cloud when you have a significant on-premises estate can be challenging. This is the first in a series of blog posts looking back at how DVLA adopted cloud, how this has evolved over the years, and looking forward to what the future holds.
Cloud adoption at DVLA can be traced back to 2013 when the Government Digital Strategy committed Departments to the redesigning and rebuilding of 25 significant ‘exemplar’ services. We were responsible for 3 of those services (View Driving Licence, Vehicle Management and Personalised Registration), with the challenge to make them so simple and easy to use, they became the first choice for customers. Like many other organisations, our IT estate was centred around large monolithic proprietary legacy systems. These systems had grown over decades and were difficult to change, with many legacy constructs baked in. Almost 80% of the IT budget was spent on standing still, split between licensing costs, operating as a managed service, and tech refresh. This was also all set against a backdrop of austerity. Doing nothing was no longer an option, and the drive to adopt more agile working practices alongside open standards and cloud could not have come at a better time.
All of our exemplars were successfully delivered. A number of these services won awards, some of them reduced the customer journey time down from weeks to minutes. All of them delivered value to our customers. On the surface it is a good news story. With the benefit of hindsight, it’s interesting to look back at what worked well and why, and where we needed to improve.
The biggest catalyst to our cloud adoption was the exemplar programme itself, and the backing of the Government Digital Service (GDS). Organisations typically have an ingrained culture and established way of working. Trying to challenge this can be problematic, and needs support and buy in from the very top. The exemplar programme itself provided the executive support and commitment to change to make it happen.
The next critical success factor was the drive to deliver at pace. Commitments had been made for delivering the services in a given timeframe. Although this may sound counter-intuitive, it helped to focus the mind. It brought a realisation that the service didn’t need to be fully feature complete to be put in front of customers and add value. The question became “what would we rapidly deliver?”, with a series of iterations of continuous improvements following along afterwards. The adoption of agile thinking moved the agency away from conventional waterfall delivery. It meant we avoided the paralysis of wanting to understand everything before we began, or the fear of getting something wrong.
The final critical factor was partnering with smaller external suppliers that had experience in working in this new way. This was an opportunity for us to do something new and different, and our partners allowed us to avoid making obvious mistakes and gain from their expertise. They were also able to lend their weight to challenging the existing approaches, and bringing a more modern cloud native mindset.
The exemplars showed that the new approach to delivering digital services in the cloud could deliver customer value far quicker. But this did not mean that all was rosy. This new way of working allowed us to easily spin up virtual machines in the cloud. There were no long forms to fill in. We could have a new compute environment in minutes. The elastic nature of cloud also meant you didn’t worry about a hard capacity limit, you could spin up more virtual machines, and if you were hitting constrains you could request virtual machines with more memory or CPU. Our services were delivered and initially run by outsourced teams. Each of these teams had their own cloud engineers, and were responsible for owning the full stack including cloud platform. We mandated principles around automation and infrastructure as code. However, we had no existing standards and patterns for cloud first architectures. Our outsourced delivery teams were autonomous, and this led to differences in approaches and variations in technology stacks. By the time we brought them back in house to put us in control of our own destiny, we had to support multiple different technologies and standards. It was clear that although the rapid delivery of the exemplar services proved the value of the new way of working and moving to cloud, the approach taken was not sustainable in the long term.
In the next post we will talk about the changes we made to grow our internal capability and become a learning organisation, create a ‘paved road’ for our teams to deliver at pace, all whilst reducing running costs by over 70% through cost optimisation.
