The UK Houses Of Parliament & Elizabth Clock Tower (Big Ben bell inside).
We need more software. Look into any corner of the enterprise computing landscape and you’ll find a need for additional applications, wider network connections between existing resources and new-age AI entities, additional cloud observability services, supplementary data storage and analytics functions and (often above all, although organizations don’t like to admit it) better data integration.
What that often boils down to in the mind of the average CEO, CIO, CISO or CTO is the management control factor i.e. they want to be able to view their technology deployment and twiddle knobs (literally) on a vizualisation dashboard that turns the flow up, down or outwards on any given stream of the IT stack. But control isn’t always what matters most; despite Covid-19, the rise of compartmentalized containerization with Kubernetes and disaggregated multi-cloud norms becoming the de facto standard… some people still haven’t understood the need to embrace flexibility as the central ethos around which all computing structures should be built.
The truth is, change will always outpace delivery if platforms are built for control, not flexibility.
River Of Constant Change
This (above) truism was offered by Jonny Williams, chief digital adviser, UK public sector at Red Hat. Speaking from his governmentally-aligned viewpoint (a sector that, in the UK at least, is traditionally known for its proclivity for management meetings, usually with tea and biscuits, rather than any esoteric adherence to flexible autonomy and optionality), he thinks that digital transformation remains a clear ambition across government. But as the recent Gov.UK Blueprint for a Modern Digital Government appears to suggest, delivery isn’t working fast or effectively enough.
“The blueprint pulls no punches: transformation is too slow to meet the scale of public sector ambition,” said Williams. “At the same time, teams across departments are being asked to do more with less. So it’s not just about cost. It’s about fewer people, less time, less complexity… and less friction. While the goals are consistent (better security, higher resilience, improved scalability), the blockers to achieving them are also familiar: legacy infrastructure, siloed delivery, too much overhead and not enough flow.”
Williams uses the term “flow” in the context of its much-beloved understanding by hardcore software application developers; when they are really in-the-zone (headphones on… Metallica playing, diet Pepsi and cold pizza on the side of the desk, keyboard alight with fingers peppering the command line with great code), they are said to be in a state of “flow” and, clearly, that’s a good place to be.
In this context, many advocates and evangelists across the tech industry argue that platform engineering offers a compelling way forward i.e. flexibility from above and below is the core mantra. This means it’s not about building another static technology stack. It’s about creating evolving internal developer platforms that abstract complexity, support developers and accelerate service delivery… all while staying aligned with operational goals.
An Insufficiency Of Infrastructure
“The UK Government (and for that matter the ruling body in any other Western or modern nation) typically doesn’t lack ideas, it lacks infrastructure built to adapt when those ideas inevitably shift,” explained Williams. “In many government departments, ageing platforms were built years ago to meet a particular need. They were often delivered via traditional programmes or projects, with big design up front, and implemented over months or years. They were rarely built with long-term evolution in mind.”
At first, these incumbent government platforms did what they were supposed to. But the needs of the services running on top of them changed. Teams began exploring different architectural approaches… and quickly found that they needed flexible networking, updated security models and an ability to serve new types of workloads. Many want to experiment with AI or machine learning. But old platforms don’t (and generally can’t) keep up. The result is that teams get slowed down, demotivated and frustrated by tooling and processes that don’t support the way they work. This is what the IT industry likes to call platform drift, or the “lava lamp effect” i.e. teams bubbling away from the original platform until eventually, they break off entirely.
“Platform drift leads to platform sprawl. Different teams adopt alternative platforms to meet their needs. Any organization in this scenario loses consistency and the number of platforms multiplies without scaling value,” said Williams. “This pattern is common across government, where hundreds of departments have deployed hundreds if not thousands of different platforms to solve the same problems. When developers face slow processes that ask them to raise a ticket just to provision an environment, or where AI is entirely distinct from their existing platform, or they can’t get rapid feedback on a release, it’s no surprise they look for alternatives. But at the scale of government, these challenges have an enormous impact.”
How Traditional IT Platforms Work
The root problem is not just technical. It relates to an entire delivery model. Traditional platforms are focused on maintaining a stable state. They solve problems after they appear, rather than anticipating future needs. That mindset, not just the tools themselves, is what many in this space think is holding back progress. Technology evangelists say they know that this challenge will only increase with the rise of emerging AI requirements.
Platform engineering flips that model on its head. Instead of building a one-off platform and walking away, organizations build internal platforms the same way they build public-facing services… iteratively, based on user needs, with a product mindset.
“It starts with abstraction. A well-designed platform removes complexity, offering reusable components and self-service capabilities. Teams don’t need to raise a ticket to create an environment or deploy code. They consume services directly. That’s how you reduce stress, risk and overhead. That’s how you do more with less,” said Red Hat’s Williams. “It also means continuous improvement. Platform teams gather feedback and ship updates. They measure usage and performance. Some of the best platform teams we’ve seen in government use product reviews, team charters, skills matrices, backlogs and user surveys… the same practices you’d expect from any good digital service team.
Crucially, platform engineering enables what techies like to refer to as “evolutionary modernization opportunities” today, meaning that rather than rip and replace, departments can support legacy applications and new services side by side, often making use of virtual machines and containers. It’s all about giving teams the space to modernize incrementally, all while ensuring the platform can keep up. That’s where the idea of the thinnest viable platform comes in i.e. start small, deliver value early and meet real user needs… then expand responsibly as those needs evolve.
The Platform Is The (Change) Lever
For digital transformation to succeed, Williams says platforms need to stop being “passive infrastructure” and start being “active enablers” in modern cloud computing architectures. That means embedding user needs into their DNA. It means investing in empowered, iterative, data-informed teams who align with wider organisational goals.
“Platform engineering isn’t a silver bullet. But it’s one of the clearest, most actionable levers we have to make digital transformation real – not just in pilots or proof of concepts, but at scale. With the right mindset, the right structure and the right investment, we can build platforms that keep pace with ambition. We can make value delivery easier. Then we can finally move from intent to impact,” concluded Williams.
But can we really move forward with progressive government technology architectures (a sort of quadrilateral oxymoron, in the past at least) and talk about a future where public sector IT platform teams are established so that they develop and share projects?
Amanda Brock, CEO of OpenUK, a non-profit organization dedicated to promoting open computing, open data and open source at large points out what this future might look like… and highlights who is already working on it.
“We are seeing Emily Middleton [UK director for digital centre design at the British government’s Department for Science, Innovation and Technology] drive departments’ efforts centrally,” said Brock. “This is happening alongside the UK’s Government Digital Service, the Cabinet Office and others all being urged to operate as a central team, which is the right first step. Now they are looking to build cohesion and skills, to streamline processes and build understanding. I see this bedding-in towards a platform engineering approach as critical to create good practices and avoid silos.”
Going deeper, Brock suggests that a centralized approach to computing helps to build shared understanding; this (in theory if not in practice) enables teams (in government or in the private sector) to to check whether others are already working on the same idea, and contribute to existing projects rather than building another new project.
“We are seeing talk of software and data service cataloges, but however we ultimately develop… building open source infrastructure as the base of a future digital spine at this level will allow access for all parts of the public sector and create a well-curated infrastructure that becomes an interoperable de facto standard,” said Brock, speaking at a media event in the House of Commons terrace this summer.
Public Sector Progressiveness?
Could we move to a technology future where the breadth and girth of public bodies enables them to adopt platform engineering for its flexibility factors even faster than we see in the private sector? Even if the deployment surface is 20% of existing technology projects at this level, the 80:20 knock-on effect could (arguably) be positive for all sectors.
Insular information technology silos may soon be regarded as just as damaging as cultural, economic or political insularity, it may just be time to collaborate and listen.
