How do you do more with less?
This is the billion-pound question and one that is even more urgent in the UK public sector today. Years of austerity and government pressures to break up monolithic contracts have left the public sector scrambling to squeeze as much as they can from what they have. Against this backdrop, I was not surprised to see the Head of the National Audit Office (NAO) recently highlight the “digital capability gap” that’s still apparent across government. This refers to the government-wide ‘digital by default’ projects aiming to bring government services into the 21st century and make them more accessible/mobile, or make them more efficient, saving taxpayer money.
Calls from the NAO to lighten the load and re-prioritize these projects will frustrate but not surprise those in the sector who are well-accustomed to yo-yo budgeting and project prioritization. The most startling headline from the NAO is the actual number, however. An estimated 2,800 extra IT staff are needed to bridge the digital gap, which is a tall order, and this estimation is only trending upwards more than ever. The best way to address this imperative is for departments to accelerate the sharing and reuse of assets across government. Part of MuleSoft’s daily work with connectivity and integration is promoting reuse as a standard behaviour, helping customers do more with less.
Reuse in architecture is not a new concept, but through more sophisticated connectivity and integration, it is a more attainable behavior than ever before. After all, one of the widely accepted hurdles to jump in adopting digital services is the massive time consumption, skill and cost for departments to build and then connect to legacy infrastructure. So it makes sense that once one department has accessed the underlying system, you standardise that access through so others can simply reuse it. Once a lot of these assets are made reusable, then multiple teams across an organization can access the data and use them in a controlled, governed way. We call this an application network.
The setback with previous reuse methodologies, like SOA, has been that while these concepts are adopted in central IT teams, they are not ushered in a productivity step change because the functionality, access, and coding are too cumbersome or unsecure for non-central teams to embrace.
Perhaps the British government should take some advice from across the pond. On a recent webinar, the Federal Communications Commission (FCC) outlined their considered approach for digital and addressing legacy modernisation. Admitting that they have lots of complex legacy applications across disparate lines of business, there was a tendency to recommend moving everything to a single location in one ‘giant leap.’ Recognizing how difficult this would be, the FCC is considering the more intelligent approach of embracing an API strategy and building an API layer to enable gradual migration of each application to an appropriate modern platform. By using API-led connectivity and building out ‘System APIs,’ these applications can then be reused across other departments appropriately. Appreciating that Government has complex, interwoven connectivity needs, it will require multiple API building blocks; by putting in a framework for ordering and structuring these building blocks it makes them more accessible to a wider audience and starts to bridge the capability gap.
The API-led connectivity strategies help define methods for connecting and exposing assets and promotes decentralised access to data and capabilities while not compromising on governance. This is a journey that enables the realization of a ‘composable government’, one whose assets and services can be leveraged independent of geographic or technical boundaries.
With the current political and economic backdrop, this approach is one that seems to resonate more than ever with the UK public sector. An API-led approach means rather than taking a running jump and leap; departments can take manageable steps to crossing the digital chasm and doing more with less.