Background

In our previous design history, we described why the Funding Service needs an Operational Data Layer (ODL): to create a single, trusted source of funding data that reduces duplication, improves consistency and provides the foundation for a more scalable service.

The first stage of this work has focused on proving the technical capability.

However, technology alone does not transform a service.

The real measure of success is not whether we build an Operational Data Layer. It is whether it enables the Funding Service to change how it delivers funding.

Why change is needed

The Funding Service continues to deliver increasingly complex funding successfully. However, doing so requires increasing effort across the service. This means:

  • onboarding new funding into the existing digital systems is complex, requiring separate processes and manual activities to support delivery
  • operational data is duplicated across multiple systems, increasing cost, creating more opportunity for errors and requiring additional quality assurance
  • assurance and governance activities rely heavily on manual processes, increasing effort and slowing change
  • teams spend significant time managing complexity rather than improving the service

New capabilities create new opportunities

Technology, processes, governance and ways of working have evolved together to support the delivery of increasingly complex funding. In doing so, we've also developed workarounds and compensating processes that enable the service to operate safely and reliably within the constraints of the current landscape.

Examples include:

  • manual reconciliation
  • repeated quality assurance
  • moving data between systems
  • duplicating transformations
  • waiting for data to become available before work can continue

These activities continue to play an important role in today's service. However, if we were designing the Funding Service today, with the capabilities now available to us, we would almost certainly make different choices.

The Operational Data Layer creates an opportunity to rethink those choices.

We only realise the full value of new capabilities when the way the Funding Service operates evolves alongside them.

The opportunity is not simply to introduce another platform, but to simplify how the whole Funding Service operates.

Realising the benefits

To realise the benefits, we need to change how the Funding Service operates. Rather than asking:

How do we recreate today's ways of working in a new platform?

We should ask:

  • which activities genuinely add value?
  • which controls are essential?
  • which activities have evolved to compensate for the way today's service operates?
  • what should we keep?
  • what should we stop?
  • what should we do differently?

These are service design and operating model questions, not simply technical ones.

The aim is not to recreate today's operating model in a different platform, but to make the best use of new capabilities to deliver a simpler, more scalable Funding Service.

Designing our future together

The future operating model cannot be designed in isolation by architecture, operations, product or design.

It will emerge through collaboration across the whole Funding Service.

Alongside user research, we'll use co-design approaches such as:

  • storytelling
  • realistic service scenarios
  • co-design workshops
  • low-fidelity concepts
  • collaborative ideation

These approaches help people move beyond today's constraints and explore what becomes possible with new capabilities.

Instead of asking:

Can the technology support what we do today?

We can begin asking:

If this capability existed, how would we choose to deliver funding?

What success looks like

We'll know the Operational Data Layer has been successful when:

Data is managed once and reused many times

Teams no longer need to repeatedly transform, reconcile or duplicate operational data across multiple systems.

Change becomes easier

  • Funding changes can be prepared earlier.
  • New funding lines can be onboarded more easily.
  • Configuration becomes simpler and more consistent.

Complexity is reduced

  • People spend less time managing complexity and more time delivering value.
  • The service becomes less reliant on workarounds and compensating activities.

The service works as one

  • Technology, product, operations, policy and design make decisions together.
  • The focus shifts from individual systems towards the end-to-end Funding Service.

Decisions are made at a service level

  • Rather than optimising individual systems or processes, teams make decisions that improve the end-to-end Funding Service.
  • Service-level decision making becomes fundamental to achieving our North Star.

Providers benefit

  • Funding information becomes more consistent.
  • Errors, delays and unnecessary queries reduce.
  • The service becomes more resilient and scalable over time.

Across the Funding Service, we'll see success demonstrated through:

  • reduced duplication
  • reduced manual handling
  • reduced reconciliation
  • reduced operational risk
  • increased confidence in funding data
  • faster, safer change
  • a simpler end-to-end Funding Service

Ultimately, the real measure of success is whether the Funding Service can continue to deliver increasing complexity without increasing effort.

Outcome

The Operational Data Layer is not the destination. It is an enabling capability that gives the Funding Service new opportunities.

Technology provides the capability.

The real transformation comes from how the whole Funding Service uses it to simplify how funding is delivered, reduce complexity and create a more scalable service.

Share this page

Tags

Data Funding