Article content
The world is changing and governments need to respond to the change. That statement is a cliché but to an extent it actually needs to be reaffirmed. All governments face internal and external challenges caused by the cycle of globalisation and technology. The question now is, what do we do about it?
Author:
Andres Kütt, Architect at Estonian Information System Authority in 2013-2017
For a problem to be solved, it must first be understood, and herein lies the crux of the matter. Even within a particular country, consensus on the nature of the changes in society brought about by technology can be difficult to achieve. It is not that we have lost the ability to agree upon things; it’s that the complexity of the problem has tended to outgrow the limits of a single approach let alone a single individual. So how can we develop policies to counter something we can’t even define?
On a smaller scale, this is a well-known problem for software architects. The requirements for software systems can only be nailed down to a certain extent; change is a constant and so we end up with something called upstream ambiguity, or uncertainty about the desired outcome. One of the most useful strategies in the field is to go modular to keep things open. If you don’t know what the customer wants to build, supply them with a box of Lego.
Openness – problem or solution?
This is where open data continues to play a role. Since the specific needs of a client are difficult to determine centrally, we can empower the customer to solve their own problems or participate in service co-creation very much in the spirit of democratised innovation. Open data continues to drive substantial value for societies. But we could do even better.
There are two key issues with open data. The first is that it is often treated either as an afterthought or a separate initiative. An agency is seeking to solve a business process issue and procures a system only to discover they have forgotten to specify they need an open data solution. A separate team is created to increase open data creation and adoption. The problem with these approaches is that openness is not built into systems or organisations. Openness is a problem to be solved and not a solution.
The second problem with traditional open data approaches is that they don’t increase the modularity of the government itself. The state produces data streams but these are mostly directed outwards and do not necessarily lead to the state itself becoming more nimble. Instead of a box of Lego, the development team produce a single large brick while promising to re-shape it as needs arise.
Box of Lego to build from
So how do we take open data further? How can we move openness from the problem to the solution domain, and how do we use it to drive modularity? In the software world, this is commonly accomplished using APIs (application programming interface). This means that systems are broken down into individual components performing a particular task and communicating with others using well-defined communication paths and vocabularies. One of the tasks might be user interaction on mobile devices, another keeping records and a third the user manifesting the process on a multi-monitor officer workstation. In addition to data, commands to manipulate that data are exchanged.
And in this way, the APIfirst idea is born. Let’s build systems that focus on openness. Let’s have all government systems produce a machine-readable API first, and then build a multitude of user experiences on top of that API. The API is a way to deliver services and not something constituting a cost sink.
Instead of a statistics portal, we open a dataset and build a visualisation layer utilising that dataset. Instead of a self-service portal, we build APIs and engage communities to develop the most suitable user experiences. Instead of rigid business processes, let’s produce a box of Lego with which users can build useful things.
Attaching Lego pieces to each other
Estonia is approaching this solution from the other side, having focused more on APIs than their openness. Our experience shows that APIs can be highly effective tools for openness, resilience and agility. The Estonian internal API exchange layer, the X-road, sees exponential growth in messages passed. This has led to highly focused business driven systems that are efficient and well-defined. Further, the systems in individual agencies are rather independent, allowing each agency to select the architecture, technology and release cadence that best meets its particular needs.
Now we need to take this further by opening our internal APIs up to external parties by establishing an open system of mandates, enabling citizens to control their data and services in a precise manner. We envision a society where the public and private sectors and citizens can work together to solve whatever problems the increasingly complex world throws at them. A bank can utilise an API to file taxes on behalf of a company while using a government-provided electronic identity subsystem. Your chiropractor can access your x-rays on your behalf. A group of citizens can build an electronic voting application they have full confidence in.
As public servants, we can no longer claim to fully understand our customers and their needs. We need to move from openness-as-a-problem to openness-as-a-solution and deliver the next wave of public services with the private sector and the citizens. Let’s create the future together!
Current blog is created according to the action plan for promoting the E-Estonia´s reputation.
The action plan for promoting the E-Estonia´s reputation has been developed and it’s partial implementation is coordinated by the European Union Structural Assistance support scheme “Raising awareness of the Information Society”, funded by the European Regional Development Fund.
