In this guest post from MOJ Digital and Technology, Kylie Havelock talks about how the Ministry of Justice recently integrated the 'visit someone in prison' service with their back office systems.
Creating a joined-up justice system is the most important long-term strategic goal for MOJ Digital and Technology and is closely linked to themes within the Government Transformation Strategy.
Although achieving this task is a long-term project, our work is starting to pay off as we’ve recently launched a number of Application Programming Interfaces (APIs) to integrate back office systems with one of our digital services: visit someone in prison.
Joining the digital dots
We built 'visit someone in prison' as part of the GDS transformation programme in 2014 and the service now handles around 1.3million visits a year. It is the biggest transactional service in the Ministry of Justice, allowing family and friends of offenders to maintain contact with their loved ones.
While the service has helped meet important needs for prisoners and their families, prison staff still needed to do jobs like re-entering prisoner data in different systems.
By integrating the service with a large legacy system we could reduce these time-consuming tasks. We knew that doing something this ambitious wasn’t going to be easy and our eventual success depended on 3 important factors.
1. Opportunity
When the contract for the back-end prison system came up for renewal, we imposed new conditions.
We collaborated with the Standards Assurance team in Cabinet Office to approve the contract extension, which we found really useful in working up a set of conditions which were fundamental in shaping the new service:
- restructured the technical landscape and moved towards a microservices approach
- worked with suppliers to move from waterfall to agile ways of working
- took on ultimate risk for delivery, rather than the supplier
Transferring the risk onto the business and insisting on agile working enabled us to remove the usual waterfall-style request for service, inevitable hefty quote, big design up front, and so on.
With the contract in place, we brought together a multi-disciplinary, multi-supplier team working in the same location. Our Technical Architects worked collaboratively with the supplier and became increasingly hands-on in delivering the networking and infrastructure required.
2. Perseverance
Even with the new arrangements, achieving our single largest goal of connecting to the database meant we had to solve two major challenges:
Supplier delivery processes not suited to regular software releases
We initially had to go through multiple approval gates, where people outside the team scrutinised delivery outputs.
To overcome these non-agile approaches, we’re now working with our suppliers to streamline the deployment process and decrease the time to release.
Information assurance processes not aligned to iterative software development
The legacy system we were integrating with used traditional security risk management tools and annual IT health checks processes.
We overcame this by creating a blended approach. The business maintains their familiar process for its legacy system while we managed risk for the new APIs through a continuous security risk management with regular penetration testing by our ethical hackers.
3. Pragmatism
We’ve adopted a thoroughly pragmatic approach throughout. Rather than delaying delivery by starting a lengthy discovery phase, we aimed to learn ‘just enough’ about the legacy system to propose an achievable solution.
Recognising that the risk of failure is higher when working with complex architecture, we started with a low-risk product that would still function adequately without the API.
When we found there was no inbound Internet connection to the data centre, we established an outbound connection using a websocket product then upgrading it to bi-directional communication. This wasn’t just cost-effective but it also saved the team from the engineering effort of developing its own solution.
To deliver value more quickly, we recommissioned some end-of-life servers to provide a virtualization layer we could deploy to. The API has gone live on this hardware while new servers are being commissioned.
Finally, we built the APIs required for our digital service ‘just in time’. Building a general purpose API, rather than one that is specific to our product needs, has meant that other services can make use of the same API calls.
Delving into the technical details
One of main aims is to break down large, siloed systems and enable a microservices future.
As a result, we simplified a complex asynchronous approach, and built an API that allows reading and writing data in real time. Here’s what our solution is based on:
- a Java API service that connects directly to the legacy system, designed iteratively and collaboratively between us and the supplier’s team of Oracle developers
- virtual machines for the private network built using Packer and deployed by us
- API Gateway used for API client authentication and authorisation, build by us using Golang. Deployed on Amazon Web Services (AWS), using Packer build Amazon Machine Images and Terraform to orchestrate AWS components
- boundary controls have a classic firewall sandwich around a reverse proxy upstream from the API application server which communicates directly with the legacy database
Another new thing…
Defining a support model for an evolving, temporary architecture is tricky. The team was able support the integration with Prison Visit Booking service as staff use it during similar working hours to us.
However, as we expand the use of the API, we need to define an appropriate support model. We’ll be looking to the platforms and components guidance to ensure the technology we build can be properly and cost-effectively supported.
The beginning of the beginning
So far we have one product using the API, and 3 more digital products that will soon be integrated.
However, we’re planning to expand the number of APIs that will give more services access to the valuable data in currently locked legacy systems. This will help us deliver better digital services.
There’s a long way to go but this work has been an important step in moving towards our goal of a joined-up Justice system that’s faster, simpler and more effective for users.
Kylie is a Product Manager who leads end-to-end service transformation at the Ministry of Justice.
You can sign up now for email updates from the Government Technology blog or subscribe to the feed.
Follow Kylie on Twitter.
1 comment
Comment by Shane D posted on
I absolutely love this sentence 🙂
"boundary controls have a classic firewall sandwich around a reverse proxy upstream from the API application server which communicates directly with the legacy database"