DevOps is confusing. Everyone has an interpretation. Is it a management practice? Is it a skillset? Is it a platform?
I tend to think that a Better Value Sooner Safer Happier viewpoint is useful: it’s a bit of all of these interpretations and is unique to your organisation (with some specific characteristics).
What we have now: the tech foundation
At the Home Office there is at least one firm stake in the ground.
People are working on cutting edge stuff: Kubernetes, Docker, Terraform and Amazon Web Service (AWS) across a number of platforms, with a stack of new opportunities available.
We are working in agile, interdisciplinary teams to build and operate public facing services – doing some important and interesting stuff.
We have also made massive inroads into infrastructure as code.
We can provision resources consistently and efficiently and manage them through life, pushing those foundational software development principles, such as versioning and peer review, to create and maintain robust, auditable, scalable and cost-efficient (autoscaled, rightsized) environments for both development and production.
What are our interpretations of DevOps?
I want to unwrap in more detail what DevOps means to the Home Office (at the moment!).
Interpretation 1. The platform
The Home Office delivers tons of technology.
It makes sense to use a common platform which allows developers to define new Continuous Integration (CI) pipelines rapidly, getting code into a product, through testing and into production in a timely manner.
Thankfully we have a couple of great platforms for this, the Application Container Platform (ACP) and our borders and immigration-focused platform, Environment Build Support Administration (EBSA).
Using these platforms our technical staff can rapidly start work and improve their productivity without having to develop bespoke environments (with pre-configured services to provide operational feedback).
The platforms are forming a key component in our DevOps future. They also provide a focal point for the domains of Dev and Ops to collaborate.
Interpretation 2. The person
Our people and their skillsets align with the Government Digital Service (GDS) DevOps role definition, building new DevOps processes, complex stories, environments and removing impediments. Home Office DevOps professionals contribute to the definition, development and support of our platforms.
The more time we can spend with users to improve service delivery and quality the better.
Our technical focus is on Kubernetes, Docker, AWS and Azure.
These specific skills help support the DevOps principles (which are explored in the wrap-up under “How we are evolving’, below).
We definitely need more of these skillsets in the Home Office to drive our approaches and tools forwards.
Interpretation 3. The contract
You can’t outsource DevOps, but we can’t do it all ourselves either. We need help, but can’t throw things over the wall (which is completely at odds with the DevOps culture).
So we need to push really hard to ensure that:
- we avoid rewarding dependence on our suppliers which may generate artificial competition with our own staff
- everyone understands our preferred way of working, so we can integrate around this and prevent any misalignments as soon as possible (including technical governance, security and IT Ops for example, doing the whole job for all products!)
- we leverage common approaches where they exist, thinking particularly about platforms
To help meet these goals we are developing central commercial approaches which provide a solid foundation here, but there is a lot to converge.
In the meantime, we need to avoid some common anti-patterns. One is interpreting DevOps = Engineering + Ops + UCD + Content + Product + …. and buying a chunk of this to meet a pressing need. This has the potential to undermine in all areas.
Can’t we ‘just do it right’?
Some people might like to be purists and reject all but their preferred image of DevOps perfection.
I would argue that any such view of ‘one thing’ is unlikely to make practical sense and makes shared technology, as well as a broad spectrum of maturity, challenging.
So no, we probably can’t ‘just do it right’. We need to iterate towards ‘better’, making something that works for us.
It’s really about applying the DevOps approach to software on the organisation, right?
How we are evolving
We need to ensure we progress in our approach, and the Home Office is doing well here.
Our technology strategy is in the right place and everyone is on board with our direction, mapping to a few of the common principles:
-
Culture and holistic thinking
We are making sure that we have playbooks for defining and running multi-disciplinary teams, which will start to push on the Dev/Ops fence where it’s up.
Alongside this, we are actively using the GDS Service Standard across the organisation.
We are also putting users first; our User Centred Design (UCD) community is strong, working with the new tech/policy groups and our Innovation Pipeline to make sure we look at things the right way from the outset.
-
Ownership and ‘no silos’
We are delivering some really big improvements here: putting shared platforms, tools and teams in place so ownership is clear but also ensuring barriers for collaboration are removed.
We are also converging our technical governance in order to provide common standards and approaches as well as aligning similar product areas.
Our DDaT professions are really leading the way in building communities to spread best practice and providing guidance and support to our staff.
-
Measurement and feedback
The ACP and EBSA platforms have tools for feedback in dev and production. Our security and IT operations centres are rapidly evolving to provide more of this.
We have a centralised service catalogue which is the entry point for users to provide feedback.
People are doing agile well, with a product-centred view developing.
So I would say we are embedding many feedback loops to provide continuous improvement.
-
Automation and flow
Viewed in a DevOps sense, automation is really getting there, not only in our platforms but also in how our Quality Assurance Testing functions are adopting automation as the norm and embedding alongside our engineers to form appropriate CI/CD pipelines (CD being Continuous Delivery or Continuous Deployment – depending on where automation ends).
We are also building this around our legacy systems where we can.
Approaches like containerisation and automated orchestration are well established.
The future
We are well on the way to becoming a better DevOps organisation.
But with hundreds of services to modernise, build and operate across a variety of domains, it’s a challenge.
The DevOps people, tools, processes and culture are all strengthening to improve.
But in the end it’s all about people. So if you want to get involved look out for Home Office tech roles on CS Jobs or our area on Stack Overflow. We may well have something for you!
Leave a comment