Both the public and private sectors stand to benefit from free sharing and reuse as a key approach to doing digital better. In a 3-part blog we cover: 1/ this beneficial way of working is still challenging, 2/ making decisions to share and reuse, and 3/ (this post) the means of sharing that will realise the benefits of reuse.

The means of sharing that will realise the benefits of reuse 

In Part 2, we looked at how to decide if we should share. Now, we must look at how. As the means of sharing a foundational element matures, we see the following characteristics all increasing:

1. Ease of reuse for a service owner/team

2. Benefits for a service owner/team from reusing

3. Scale and complexity to share and provide

4. Degree of provider assurance needed

5. Total cost of ownership for the provider

There is no single "right" way to share. Instead, there are 5 means that we use to share things, forming a continuum from a simple reusable pattern to a sophisticated mediated service.

From left to right, this represents a path to test and share reusable digital assets progressively. Taking a progressive approach reduces the risks of poor adoption and wasted efforts due to a lack of evidence.

Reusable Patterns

Sharing doesn't always mean shipping code. It starts with documenting a tested model for approaching problems. Patterns establish agreement across communities on common needs, ranging from informal best practices to formal standards—such as transactional service patterns or API standards. This is often the most tactical and low-risk entry point for sharing.

As-is Products (Static Code)

This involves sharing code versioned in a repository that is available to use "as-seen". It is a "static" product. If a service owner wants to avoid the costs of ongoing maintenance but still share value, they may open source the as-is code, provided it is well-written and cleansed of security secrets.

Maintained Code (Curated Products)

A step up in maturity is the "Curated Product." This is code managed and maintained under an open source project, often supported by a community of contributors. Unlike static code, this is a dynamic resource that services use as part of their active software build process.

Software as a Service (Direct Service)

Here, the asset is hosted and available as an integrable service. The provider takes responsibility (often under law or policy) for the functionality and information provided. This model, familiar to many, shifts the burden of operation away from the reusing team entirely.

Mediated Service

Finally, we have the most strategic and complex form of sharing: the hosted integrable service that acts as an abstraction layer for multiple commodity service providers. This "Mediated Service" adds value by aggregating usage for lower fees or making it easier to swap marketplace services in and out.

Selecting the Right Mode

Selecting the right means of sharing from this continuum is critical to mitigating the barriers to sharing we discussed in Part 1.

As we move from Patterns to Mediated Services, the scale and complexity increase, as does the degree of central assurance required. However, this increase in provider effort corresponds directly to an increase in the ease of reuse for the consumer.

For example, if a team has high technical capability but low budget, they might prefer As-is Code they can host themselves. Conversely, a service team needing to move at extreme speed might rely on a Direct Service to bypass the build phase entirely.

Digital Magic

The title of this blog series asks if this is "digital magic." In a way, it is. The benefits of reuse include lower build and operational costs, shortened delivery times, better cybersecurity, and higher quality user experiences.

When freely shared, our software libraries, tools, frameworks, and platforms enable societal economies of scale that more than reward the complexity and communal effort involved in bringing them to market.

Some magic is definitely needed to nudge behaviours towards sharing reusable digital assets. But it can be done, and it’s worth working together to achieve it. Today, sharing and reuse represents an enormous untapped opportunity for improving government services.

A Final Summary

If we are to truly "make sure public money and other resources are used properly and efficiently," as the Civil Service code demands, we cannot view sharing as an optional extra. It must be the default. By understanding the barriers (Part 1), mastering the decisions (Part 2), and selecting the appropriate means of sharing (Part 3), we transform isolated successes into a collective digital legacy.

CODA: By example, CYB has maintained the open source solution xGovFormBuilder since 2019 as part of a mission that began in 2013 to have more sharing and reuse of technology in the delivery of UK government services. Leveraged by 8 departments and 10 suppliers it has to date saved £millions in public spending. It has enabled urgent public services to go live in weeks not months, and informed further investment in reusable digital assets such as in GOV.UK Forms, itself a more mature means of sharing as defined above. This aptly demonstrates the value of understanding and nurturing the sharing lifecycle that evolves reusable digital assets progressively. And as maintained code, xGovFormBuilder is still not redundant as this means of sharing better fits some service teams compared to a hosted SaaS solution.