Achieving technical interoperability in government systems: From Protocol to Whole-of-Government

Interoperability is about the ability to collaborate, cooperate and co-exist. Often assured by shared language and cultural practices in real life, similar principles are true in digital government ecosystems.

The goal of achieving interoperability is widely stated in many eGovernment strategies and projects as well as in the initiatives supporting Digital Public Goods (DPG) and Digital Public Infrastructure (DPI), see definitions here. Interoperability is perceived as an inclusive and impactful goal – and it can be, as long as we understand the specifics of interoperability ideally in the same way and recognize the nuances we see in the technical reality that impacts interoperability. For such a common understanding, traditionally, four layers of interoperability are considered:

• Organizational: How different teams and structures collaborate and depend upon one another

• Legal: How rules and laws are combined

• Semantic: How we understand and classify data so that we understand the business terms in the same way

• Technical: How systems interact and exchange data and functional dependencies.

As GovStack, we break down the technical interoperability into more granular sub-layers (see following graphic) to define more actionable and incremental states:

1. Protocol Interoperability

2. Cross-functional interoperability

3. Whole of Government interoperability

For protocol and cross-functional interoperability, GovStack provides references in form of architecture requirements (esp. ch. 5 cross-cutting requirements) which are the prerequisites to reach the first state: Protocol Interoperability (such as a common data exchange standard across all services); while Building Block Service API requirements aim to reach the second state: cross-functional interoperability (software following Service API requirements relating to a specific domain, such as payments).

For Whole of Government interoperability, GovStack provides guidance in form of our enterprise architecture guide PAERA, which primarily focuses on the organizational and legal interoperability.

Interoperability can be seen as a continuum of three states covering multiple layers of standardization:

In GovStack, we specify reusable Building Blocks and their cross-cutting requirements to build e-services for Government to Citizen interactions. A Building Block describes a reusable software component within a government system. One Building Block can have multiple Building Block specification compliant Softwares (see a list on GovMarket).

The following example is a very simplified scenario that illustrates the need for protocol interoperability: One software application (which is designed for a specific public service, e.g. social benefits system) requests data from another data source (e.g. population registry data) to provide a service to the citizen. In a simple reference picture this looks like the following:

Any digital government ecosystem is full of thousands of little data exchanges like this, regardless regardless of the country’s level of digital maturity. This applies to highly digitalised countries such as Denmark and Estonia, but also to countries that are more advanced in their digital progress, as digital systems and databases are already available in every government today. This is why it is important to follow key principles and interoperability requirements to assure that each of those data exchanges are designed following similar standards and principles – so that the language is the same. Just like it is easier to communicate with a colleague who speaks your language, it is easier for a system to use data from another system if it understands the same language – this is fundamental for interoperability.

From GovStack’s perspective, there are three maturity states that gradually increase overall interoperability:

• Protocol Interoperability – assuring that technical systems are able to be integrated with one another;
• Cross-Functional Interoperability – assuring that digital services are able to understand each other’s API requests in the same way, adding aspects of Building Block-specific service APIs to protocol interoperability;
• Whole of Government Interoperability – adding organizational, legal and semantic interoperability to protocol and cross-functional interoperability levels.

Each are discussed further below.

Protocol interoperability is primarily achieved once both parties agree on how data is being exchanged. This can be reached by following purely technical requirements assuring that two systems can exchange data. For example, both parties agree to communicate via the design principles and protocol of REST API. The design of the API endpoints and what kind of functions and data they expose remain software-specific.

In addition to both parties following the same technical requirements, the parties need to agree how data is being used (as required by the business rules) in order to fulfill a defined business use case. This agreement is solely between the two parties and therefore creates a party-specific dependency. The dependency could be loosened, meaning that it would be possible to replace technical components without changing the agreement of how data is being used, if both parties comply with the overarching standards (as defined in the GovStack Building Block specifications). If this is not the case, then systems are only technically operable (cross-functional interoperability will be covered in the next section).

In GovStack, for example, this stage looks like this:

✔ GovStack architecture requirements (esp. ch. 5 cross-cutting requirements) are fulfilled by all participants
✘ GovStack Building Block service API specifications are not fulfilled by all participants
✘ Government-wide organisational, legal and semantic standards are in place

The second state, cross-functional interoperability, is achieved once both parties agree on how data is being exchanged and used. This can be achieved by following both GovStack’s architecture and Building Block-specific requirements.

In this case, the cross-functional requirements are a description of the Building Block API endpoints. To assure cross-functional interoperability, the API endpoints are expected to be fundamentally the same across all software applications of the same Building Block. This fulfills the expectation that one software application can be replaced by another without changing the other.

Despite the cross-functional interoperability in place, a developer in a Government system cannot be sure if the result of the API call will be the same as systems may change or may be replaced in the back end. For example, two software applications representing the Identity Building Block might be able to offer an authentication API, but the developer cannot be sure if both Identity software applications answer with the same response for the same request – registered citizens are possibly different among the software applications. But cross-functional interoperability is still achieved as it is possible to exchange one software application with another as long as both comply with the Building Block specification.

In GovStack, this state is achieved by:

✔ GovStack architecture requirements (esp. ch. 5 cross-cutting requirements) are fulfilled by all participants
✔ GovStack Building Block service API specifications are fulfilled by all participants
✘ Government-wide organisational, legal and semantic standards are in place

The third state, whole of government interoperability, is achieved once all parties agree on how data is being exchanged and used. This can be reached by following GovStack’s architecture and Building Block requirements and set context-specific standards on organisational, legal and semantic aspects. The context-specific aspects are usually to be set within a governmental body (a nation state or a regional organisation). Once that is set and all parties are bound by law to follow these standards, all party’s developers can be sure to call any software representing a specific Building Block and receive the same or the expected answer.

It is important to have data exchange agreements in place between organizations that exchange the data. In the case of Estonia, there are two contractual agreements: one that allows you to be a participant of data exchange ecosystem either as provider or requester of data and another contract that is agreed between responsible parties of the data sources which includes what kind of data is being exchanged and how it is being used.

This level of interoperability should be the ultimate goal of an administrative architecture. It enables not only the replacement of one software by another, but also the operation of several software applications from different providers that offer the same standardised functions – and are possibly operated by different bodies within an authority.

In GovStack, this state is achieved by:

✔ GovStack architecture requirements (esp. ch. 5 cross-cutting requirements) are fulfilled by all participants
✔ GovStack Building Block service API specifications are fulfilled by all participants
✔ Government-wide organisational, legal and semantic standards are in place (GovStack’s PAERA document offers support)