A practical framework for digital public service delivery

There is a tension between governments’ need to be more flexible and agile, and the discipline to use standard platforms and open architecture

There is a tension between governments’ need to become more flexible and agile around the needs of the citizen, and the need to exercise the discipline required to consume interoperable building blocks of outcomes, from standard platforms, within an open architecture.

In the UK Government Digital Service there is a focus on developing bespoke in-house open source software within agile teams, in which the broader architectural emphasis on standardising and consuming technology appears to have become marginalised. A short-term pre-occupation with the large-scale bespoking of open-source point solutions appears to have supplanted a longer-term focus on progressive consumption of open standards.

Such a strategic slippage risks replacing the previously distorted market involving private sector bespoking of proprietary technology, with a new, potentially equally distorted market involving public sector bespoking of open source technology. Both outcomes decouple government from the evolving open standards of a global marketplace, consigning it to ownership of a legacy bespoke infrastructure with escalating maintenance costs and upgrades.

In response, we propose the “innovate-transition-commoditise” (ITC) curve shown in Figure 1, below. Unlike current outsourcing and procurement models, which conflate both niche and commodity requirements, an open architecture approach allows a continual distinction between innovative activities that fulfil bespoke needs on the one hand, and the use of utility, commercial specifications wherever possible for standardised, plurally delivered activities on the other. 

Commoditised services

Figure 1 shows that as more organisations adopt common standards, business logic, and resulting platforms, they can expect to see costs decrease. Services become commoditised and procured via utility commercial models – moving from bottom left to top right of the innovation curve, as governments stop paying over and over again for multiple, customised versions of the same thing. The dotted lines in Figure 1 also remind us that such platforms are not needed merely to reduce cost, they are also required to incentivise and enable innovation.

A framework for achieving open architecture

Figure 1: Innovate-Transition-Commoditise: A framework for achieving open architecture

The middle column of Figure 1 recognises that the most successful organisations to develop ecosystems around core platforms and standards – such as Google, Facebook, Salesforce.com - continually monitor new innovations and user uptake, incorporating those that are successful into their core offerings. 

In this process, new applications (innovation) are developed into the platform and made available to other users (transitioned) – which in turn can often lead to wholesale integration and development of the underlying platform (commoditised).

In this open business model, organisations need to build capability in the skills and approaches required to leverage successful innovations, and standardise these so they can be delivered cheaply and efficiently at volume. 

Finally, the right hand column of Figure 1 shows a focus on the commercial management of central, core platforms and services as commodities – a very different set of skills from those in the previous two columns. 

Wardley maps

A recent application of this ITC thinking within government is the “Wardley map” (named after its originator, Simon Wardley), in which organisations map out their existing and planned technology infrastructure and services to reveal the different ways in which they should be treating their different components. 

Illustrated in Figure 2 is a recent example by James Findlay, chief information officer for the UK Department of Transport’s High-Speed 2 (HS2) rail project.

Practical application of ITC framework

Figure 2: Practical application of ITC framework: mapping HS2’s infrastructure

In this example, some of the obvious components - power, computer processing, standard HR, website, and so on - are treated as commodity/utilities to be either consumed on demand like electricity or purchased in standard units like pencils. 

Some of the ERP-type functions, such as finance, customer relationship management, or risk management, are not yet widespread enough in the market to be consumable as utilities – but these are things that should nonetheless be consumed in a standard way wherever possible; the UK government has recently established shared service centres to support this aim. 

Next, the “custom built” column contains those elements that remain reasonably unique to the organisation or one or two others. Finally, the “genesis” column shows “known unknowns” where it will be necessary to work iteratively in an agile manner to discover and evolve what is required, and to build this capability uniquely within the organisation.

Having separated out the technology, which would previously have been treated as a vertical stack, into its discrete components and distinguished carefully between them to generate a digital profile using the ITC principle, it becomes possible to develop a procurement strategy that underpins these principles, to allow the sourcing of every component in the optimum way possible. 

Thus HS2 is using the UK government’s electronic property and information mapping service (PIMS), which it is consuming as a commodity; a single ERP platform, consumed from one of the government’s shared service organisations, to cover finance, HR, and customer relationship management – but within individual functions supported via the new standard service catalogue, G-Cloud.

Several functions – such as risk management, ERPM, WISE - are purchased through specific suppliers, either consumed via a bespoke contract or purchased on an individual basis. This is the model that most closely represents the traditional “systems integrator” way of doing things, with little or no commonality across government.

Finally, HS2 is building several functions in-house – interactions with Land Registry, 3D visualisation for customers, geographic information interfaces for customers, and the customer website. Note that, as the stakeholder at the top of the value chain, the customer is receiving the bespoke attention, while the infrastructure (ERP platform, datacentre, power, compute) is consumed as a common service wherever possible. 

In the middle, we have some specific line-of-business technology – the Land Registry interface - as well as more shareable technology - PIMS, standardised ERP applications such as finance, HR – which HS2 can do in the same way as other government organisations simply by applying this methodology, and exercising a little self-control.


This is an excerpt from Digitizing Government: Understanding and implementing new digital business models, which is published on 3 December 2014

Click here to download a longer excerpt from the book.

Alan BrownAlan W. Brown is Professor of Entrepreneurship and Innovation in the Surrey Business School at the University of Surrey. He previously worked in strategic IT leader roles in industry.

 

Jerry FishendenJerry Fishenden was recently interim deputy CTO for the UK government. He has previously been CTO for Microsoft UK, the City of London financial regulator, the UK Parliament and the National Health Service. 

Mark Thompson

 

Mark Thompson is strategy director at Methods Group; senior lecturer in information systems at Cambridge Judge Business School; visiting professor at Surrey Business School; and recent board member of TechUK.

 

Read more on IT for government and public sector

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close