A Use Case For Blockchain: Joining Government Services [VIDEO]

Alan Bradbury

The World Economic Forum has identified blockchain technology, which underpins the virtual currency bitcoin, as one of six computing “mega-trends” to shape society in the coming decade. It estimated 10% of global GDP could be stored in blockchains by 2027. One of the key attributes of digital government, as defined by the SAP Institute for Digital Government, is the creation of public value. Looking beyond the technology-inspired hype, could blockchain technology contribute to public value? What follows is a proposition for blockchain that should be examined in more detail.

Proposition

For many reasons, corporations and citizens are both required to and choose to engage with governments. In many of these interactions, the citizen is required to provide the same basic data, such as personal identification, address, income, and employment details. It is not uncommon for some of this basic data to depend on and change according to the context of the interaction – for example, income for the tax office is assessed on an annual basis, whereas the social insurance office is interested in monthly amounts.

The machinery of governments is structured by portfolios comprised of agencies, which in themselves are a solution to addressing complex issues facing society. At the highest level there is some fluidity in response to political, policy, and other drivers, but in general the fundamental functions of government remain the same – i.e., raise revenue, protect citizens, provide education and health services, and maintain the social safety net.

At the agency level, programs are designed, facilitated, and regulated. There is a high degree of similarity in how this is done throughout the world, usually within one or more levels of competency (national/state/local) and legislative frameworks.

For efficiency and political reasons, programs may move between agencies or even portfolios. Agencies often manage and deliver very large numbers of programs, and we can assume that in these cases there is a consistency in the design of the programs, which is then reflected in the data that is relevant to these programs. In some cases, program design and delivery involves several agencies, which adds to complexity.

Increasingly, we are seeing public value creation from joined-up government, which is accelerating due to digital government initiatives. Since the 1960s, agencies have worked to improve their delivery through the adoption of technology. The approach taken has been (and still largely is) to have all of the data that relates to a program sit within a single computer system. Sharing this data between agencies, aside from privacy and security principles, is technically difficult.

Data and information

But data is just data; it is not information. What agencies need is information, which is data in context. At the atomic level, data has properties – such as whether it is a date or when it was created – but other than that it lacks context – such as which business partner the data belongs to and for what purpose was the data provided.

However, architectures that promote information sharing are few and far between. Systems and processes that allow this to happen are even fewer. Architectures that promote data sharing, noting that an atomic piece of data can happily coexist in a number of information “packets,” I would argue are even fewer. For example, a person’s salary is relevant to both social protection programs and for taxation purposes. There are even uses for this data beyond the public sector, for example mortgage applications which require salary and assets information.

In practice, solutions adopted by governments have been siloed according to the needs of the program. In this way, moving programs among agencies is naturally less disruptive. Another reason for siloed systems, and a more obvious one, is primarily a technology capacity issue. Capacity refers to the availability of suitably architected software, disk storage, and computing capacity, and of course the inherent agility for adaptation in step with the high frequency of change demanded by governments.

However, some areas within governments have done better at this than others – the most notable being those systems that support social protection. The basic characteristics for data or information include:

  • Storing “groups of data” once (usually data entered, received electronically) in addition to the source;
  • Packaging assessment and decision-making rules that depend on these groups;
  • Being able to reassess and make new decisions for all programs within a system when an item of data is received; and
  • Keeping a full copy of these groups’ history to facilitate auditing, risk profiling, and, importantly, reassessments.

A major, inherent inefficiency and inhibitor to flexibility in this is that data is already grouped, hence there will be a natural duplication of data within the systems themselves.

In my view, attempts to join up processes and data have been unsuccessful. For example:

  • A “government portal” often requires an additional authentication mechanism and then a routing to the systems of a specific agency.
  • The appointment of a lead agency for certain elements of data, for example those relating to identity and address.
  • The establishment of a center or hub for common processes; this a great step forward, but the data within these services organization still must be integrated, shared, and analyzed.

Challenge

What if we could move the management of data outside of agency boundaries, without performance penalty, and at the same time improve the ability to trigger other processes, fraud detection, program performance measurement, updates of plans, and so forth in real-time when a simple atomic data item changes?

Opportunity

What if we could design a data-sharing architecture that was robust, accessible, and inherently included all of the necessary record-keeping standards and controls where the consumer/citizen retained control over who had access to their information? And what if we could do this so that we did not have to “design” the total data picture upfront, but rather it could grow organically and flex as needed? Perhaps the solution requires a new approach, at least partially, based on new disruptive technologies such as blockchain.

To find out more about the SAP Institute for Digital Government visit www.sap.com/sidg, follow us on Twitter @sapsidg and email us at digitalgovernment@sap.com


About Alan Bradbury

Alan Bradbury is a SAP Industry Principal for the public sector, with over 30 years of experience in IT and government industries. Alan is also an Associate of the SAP Institute for Digital Government.