How Kainos applied product thinking to speed up justice reform

Kainos applied product thinking to the Microsoft Azure cloud platform for Her Majesty’s Courts and Tribunals Service (HMCTS). From a platform that was previously thought of as an operational cost, it now holds intrinsic value to the organisation becoming a force amplifier for teams through focusing on developer experience, ease of use, reliability and performance. This has enabled HMCTS to deliver services more quickly to the people who need it through releasing small, incremental improvements continuously to improve developer productivity and reduce cost. 

“We are delighted to have Kainos on board as a cloud partner. They have a strong track record of delivering to the highest standards and their expertise in Azure Engineering and legacy modernisation is invaluable.” – Linda Green, Head of Platform Operations at HMCTS. 

In 2016 HMCTS embarked on a £1bn programme called Reform, involving over 50 workstreams to bring new technology and modern ways of working to the courts and tribunal service. The original vision for Reform - to modernise and upgrade our justice system so that it works even better for everyone - remains true, providing new, user-friendly digital services and improving efficiency at the same time. 

As a trusted partner to HM Government with extensive experience of helping government departments overcome their toughest digital challenges, Kainos took responsibility as digital delivery partner to reinvent HMCTS’s platform operations.  

Kainos have been a part of the HMCTS reform journey since the beginning and at its heart, it is focused on accelerating justice through technology and using modern user-centric end-to-end service delivery, leading on digitising divorce in the UK prior to the no fault divorce coming into force in April 2022. 

When we set out to create a platform to build and run all the services at HMCTS we first had to ask, ‘what is a platform?’. A platform can mean many different things to different people. To answer the question, we started looking at all the things that would need to be built and thought we could define it by describing all the component parts: a collection of environments, tooling, servers, build pipelines. 

We realised that this wasn’t enough, it wasn’t just a collection of things. We started to think about everything that happened around a platform and added things like ways of working, principles, best practices, and so on. This just added more words to the ever-growing list. We needed a more concise definition. 

We applied software engineering principles to the entire platform which meant adopting an ‘everything as code’ approach to pipelines, automated testing and the cloud infrastructure itself. Traditionally infrastructure platforms like this are designed with a fixed state, deployed by a central team and any extensions/releases can often be a slow, high-risk process with dependencies across several areas.  

We wanted to enable developers to quickly deploy, configure and iterate their infrastructure, taking on ownership for their service end to end. We applied the same continuous delivery rigour to platform concerns which allowed developers to deliver a change all the way through to production minimising dependencies, context switching and costly interrupts. We adopted a platform engineering approach focused on creating the tools which enable teams across HMCTS to self-serve - We wanted to do the hard work, so users didn’t have to. 

So how do we deliver platform features continuously without introducing breaking changes for platform users? We publish platform standards, version them and widely socialise across the organisation. We also created and actively maintain a Smoke Test application which exercises all aspects of platform functionality. We deploy this application on each code change ensuring that we always ‘eat our own dogfood’ before we expect our users to do so. 

• No breaking changes
• Do the hard work so that users don’t have to
• Everything is automated and tested

Every pain point that our users felt is also felt by us. This proximity to user needs provides significant motivation to improve, optimise workflows and just generally make things easier. Through our self-serve tooling we aim to make things as intuitive as possible for our end-users doing the ‘hard work’ on their behalf. Detecting features and applying sensible default configuration so that they didn’t have to, alerting users when they were using deprecated features and providing simple mitigations for common problems. 

Tim Jacomb (Lead Software Engineer at Kainos) said “the deprecation alerts helped me ensure my service was taking advantage of the latest platform features, I was able to quickly make changes to my application using the suggestions provided to keep my service running smoothly”. 

All of this means that by focusing on the small details of improving developer experience, shaving seconds off developers build cycle, we can save vastly more by removing wasted time. Whenever there is a hand-off or delay, we look to remove it so that developers can remain focused on their task. 

Trimming seconds off your pipeline won’t save millions, but if you can get buy-in from developers and build an ecosystem around it, then you open yourself many advantages: 

• Faster feedback loop for developers means faster time to market
• Free from lock-in to particular technology
• Consistency across technology estate without mandating choices
• Ability to innovate quickly and safely

Products used: 

• Azure Kubernetes Service (AKS) 
• Azure Front Door 
• Azure Firewall 
• Azure Application Gateway
• Azure Postgres
• Azure Cache for Redis
• Azure CDN 
• Azure Key Vault 
• Azure Storage 
• Azure Log Analytics Workspaces 
• Azure Container Registry (ACR) 
• Azure DNS Zones 
• Azure Traffic Manager 
• Azure Virtual Networks 
• Azure Active Directory
• Power BI
• Cosmos DB