Reuse in digital public services

Written by Colin Marrs on 21 August 2015 in Opinion
Opinion

Many public sector organisations developing digital services are guilty of reinventing the wheel missing important opportunities to reduce costs and speed up delivery, says Harry Metcalfe.

Digital services are a vital part of public service delivery.

But most digital services are built with little consideration given to the parts of the technology problem that are genuinely unique. Think about one that you run.

Think about the technology that it requires in order to function: releasing and deploying code, sending email, managing event queues, running databases, starting and managing instances, monitoring, ticketing, workflow and so on.


Related content
Government renews Oracle licensing deal
Compliance in the Cloud: Be sure and secure


 

How many of those functions are genuinely unique to your service? Almost certainly, very few.

How are you meeting those needs: cloud products? Open source tools? COTS products? Bespoke solutions? I’m sure all of those categories are represented, but my guess is that bespoke solutions crop up more often than you’d like.

Reuse of existing components and capabilities is important.

Without reuse,  we all repeatedly reinvent the wheel, causing massive duplication and waste.

Almost all systems have some aspect of duplication that can be avoided.

For example, if your digital service sends email but doesn’t use a cloud product like Sendgrid or Amazon SES, you’re probably in this category.

There’s an understandable temptation to build systems from scratch, especially if build is your team’s speciality. Because rolling your own gives you control.

But this is often specious.

You’ll have all the control in the world when you have a development team, a budget and the attention of your stakeholders.

But when you’re a few years down the line, with a service that’s just ticking over and an organisation with new priorities, you might find that you have no dev team, a minimal budget and no control at all.

Most digital public services, and systems at large, have some aspect which is unique - which is why they were built.

And if the user needs for a given service call for a bespoke solution, then that’s exactly what we should build.

But throughout, we must be mindful of the true cost of bespoke code, and diligent in our consideration of products, services and tools that we could make use of instead, or which could be adapted or combined in different ways to meet a new need.

At a component level, this problem is reasonably well addressed.

Almost all modern languages have large libraries of software packages that can be used to get things working quickly.

Ruby on Rails is a great example of this, with a gem for almost every problem.

At a service level, things are also better than they once were.

Cloud services are now available - inter alia - for sending email and SMS messages, deploying and using databases of various flavours, providing computing power and knitting all these various things together.

At an organisational level, it’s a different story.

Within public sector organisations, it’s rare to find two separate services where someone has considered the functionality they provide and separated some common function out into a supporting system in its own right.

Often, systems don’t talk to each other at all. When they do, it’s usually a tangled web of interdependent systems rather than a well-thought-out architecture.

See HMRC’s Aspire contract for an example of this - and the trouble it can cause - writ large.

At a sector level, things are even worse. Duplication is profligate.

Without even considering public-facing digital services, we know that almost every public sector organisation has its own payroll, intranet, HR, finance and procurement systems - despite these functioning in broadly similar ways across the sector.

And communication between public sector organisations is so bad that when they buy products and services that should have economies of scale, they often end up paying bespoke prices anyway - because the market is specialised, the communication absent and the pricing opaque.

I recently spoke to the chief executive of a housing association who’d paid just over £1 million for a new housing management product, and was disappointed that it really wasn’t very good.

They could have built their own for a good deal less than that.

How can that be right? A product, with multiple customers, where the cost to an individual customer is more than the cost of a bespoke build?

Understanding the systems we have, communicating them clearly and talking about them openly is something we must all get better at.

Users have many and varied needs, and in our quest for efficient, cost-effective services we certainly must not lose sight of them.

So I’m not saying that bespoke development is wrong. The company I founded, dxw, does quite a bit of it. Often it’s just what’s needed.

But, in almost all cases, significant reuse of existing tools and products is blended into the bespoke services that develop.

We should factor out the common parts of the services we build, and share them.

We should make use of commercially available services and open source products when we can.

 

We should watch the market for cloud services develop, and make use of new and innovative technologies.

Most importantly, we should do this at all levels of abstraction.

At the component, service, organisation and sector levels.

Services need good portfolio management, with technical expertise available to advise on how architectures could be refactored for better reuse, and hence, better efficiency - and teams who are incentivised to do the hard work to makes things simpler.

Organisations need to use techniques like Wardley mapping to help them understand the systems landscape that they’re in, communicate it clearly, and make strategic decisions about how to change it.

And they need leaders and suppliers who understand technology, and the impact it’s having on the world.

And the sector needs to get much better at selecting, building and operating a common set of supporting systems that provide the functionality almost all digital public services use - and tackling the cultural and institutional change that will be required to get it done.

That’s what Government as a Platform is really about, and that’s why it’s so exciting.

Harry Metcalfe is managing director of digital services provider dxw.

Share this page

Tags

CONTRIBUTIONS FROM READERS

Please login to post a comment or register for a free account.

Related Articles