Building our in-house Engineering capability
Meet Jose. He’s a Principal Software Engineer at the Home Office, with an unconventional background in tech. Having studied Chemistry – even beginning a PhD in Organic Chemistry – he’s maybe not the usual archetype of a Software Engineer, but with over a decade of experience including being an instructor for Android Development and a Solutions Architect, he’s had a stellar career. We’ve been lucky enough to sit down with him and discuss the latest transformational project he and his team have been working on.
What is the current project you are working on as a Principal Software Engineer?
We’ve been involved in a transformation project that covers a number of services the Home Office provides, for example, Asylum Support, for all those who need to claim Asylum, and EU Settlement, which I myself used to secure my settled status in the UK. We also have internal services that allow civil servants to perform their duties, such as immigration case working databases and systems that link various important databases together for different users. This particular project will see us take on the Level 2 Support that was previously outsourced.
What is its aim and how did it come about?
We’ve been lucky to work with great vendors such as IBM who have done brilliant work taking care of L2 support services, which are critical for the maintenance of public services, but there’s a need now to restructure and become more efficient. The strategy now is to build an in-house team to help reduce costs across the board. This applies not only to our Software Engineering and DevOps work but also to the support and maintenance of all those services. So, we are hiring to support these teams.
With a project of this size, there must be challenges and you must have to rely on a good multi-skilled team. How do you manage to do this at the Home Office?
In the past few months, we’ve increased the number of people working on the project and split it into three different streams of work.
1. Transition, which is focused on the onboarding of the services. This applies to the transition from IBM to both ITOC (IT Operations Centre) for the 24/7 monitoring, and to internal L2 support team
2. Support itself as internal teams need to be created. This includes the hiring of Support Engineers, training and knowledge transfer from IBM
3. And lastly, transformation, where my team is involved with the aim to add consistency and standards to the services in order to facilitate their onboarding and support moving forward.
How has Agile helped with this project?
There are so many different moving parts that if we weren’t working in an Agile environment, it would be very difficult. This is because things that we were thinking a few weeks ago are not valid in the present moment and we need to reconsider and improve the way we work continuously. We realised if we need to do transformation for the services in order to get them onboarded, we have to do that transformation on a one-per-one basis and that would take a long time. So now we’re working on frameworks to do it more rapidly and easily.
For example, we chose FLAPI, a Front-Line API (Application Programming Interface) used by the police. We took this as a test-and-learn project, progressing end-to-end in an Agile environment going through the process and learning the small bits and pieces that we wouldn’t be able to foresee otherwise. Now we’re using all those learnings on the rest of the services.
How do you scale up to make sure you can support each of the 109 services included in this project as they all have different needs and user outcomes?
That’s a good question. Well, part of the scale-up comes from the framework that we’re building. When our developers create a new service, they’ll get a default structure already in place without having to do anything at all.
On top of this, they’ll be able to add custom Service Level Indicators and Service Level Objectives related to their specific user journeys, but having the framework makes it so much easier.
Why should any DevOps engineers come to the Home Office?
For this project, DevOps is critical to delivery – for alerting, monitoring, pipelines etc. After all, we provide a service but it’s also about the reliability of the service as well as maintenance and availability. Not everyone is interested in Site Reliability Engineering (SRE) or Platform work, but we have a spectrum of things that can be done. The organisation is building internal teams and we are looking to grow massively, which means that there are always going to be interesting projects in a growing organisation with lots of learnings and career opportunities. You’ll also be making an impact to everyone in the country. As I’ve said, in some cases, I have used some of these services myself too.