Why we keep copying, uploading and re-entering information that computers already have
This post is about a modern administrative comedy that begins with a sentence like this:
“Please upload proof of your address.”
You have already changed your address in the system. In fact, the document proving your new address was issued by another branch of the same institution asking you to prove it. So you download the document from Portal A, save it to your computer, perhaps rename it because document_784938_final_FINAL.pdf is not especially reassuring, and upload it to Portal B.
Portal B thanks you.
Somewhere, digital transformation has occurred.
Just not quite where you are standing.
We meet versions of this ritual everywhere. Parents enter the same child’s details into a school platform, a meal system and an extracurricular registration form. Employees copy contact information from a registration form into a CRM, then from the CRM into a spreadsheet required for reporting. A new staff member receives separate accounts for email, cloud storage, project management, finance, training and whatever platform everyone has forgotten why they bought three years ago. A citizen is asked to provide a certificate created by another public authority because the first authority cannot retrieve it itself.
Every part of the process is digital.
And yet the person is still carrying the information between the machines.
This is one of the stranger achievements of digitalisation. We have become very good at turning individual procedures into software without always turning the collection of procedures into a coherent system. The queue may have disappeared from the corridor, but it has not necessarily disappeared from the architecture. Sometimes bureaucracy simply exchanges a beige filing cabinet for a beautifully designed login screen.
The technical word sitting underneath all of this is interoperability. It is not an especially inviting word, which is probably why people who work with digital systems have managed to hide something fundamentally important behind it.
The idea itself is simple. Systems that need to work together need some shared way of speaking, recognising things and exchanging information. Without that shared language, the missing connection has to be supplied somewhere else. Very often, that somewhere else is us.
The day you discover that you are an API
An API — an Application Programming Interface — sounds like something best left alone until a developer arrives. In reality, its underlying logic is familiar.
Imagine two offices that exchange information every day. One option is for someone in Office A to telephone Office B whenever they need a record. Another is to email a spreadsheet. Another is to employ someone who carries folders between the rooms. A better arrangement is to agree in advance on how requests and responses will work: what Office A is allowed to ask for, how it should ask, what Office B will send back, what the answer should look like, how identity is verified and what happens when something goes wrong.
Software can make similar agreements. An API provides a structured route through which one system can request information or trigger an action in another.
This matters because, when those routes do not exist, the work does not disappear. A human being downloads one file, converts another, pastes values into a form, adjusts a date, creates an account or reconciles two lists. Organisations become accustomed to this because each individual task looks trivial. Thirty seconds here, three minutes there, a spreadsheet every Friday afternoon. Yet multiplied across people, departments and years, these tiny acts become an invisible layer of infrastructure.
We could call it human integration labour: work created not because the underlying task inherently requires a person, but because the systems around the person cannot exchange information appropriately.
Once you recognise it, the pattern becomes difficult to unsee. A parent entering the same emergency contact three times is doing integration work. A nurse copying information between systems is doing integration work. An NGO officer cleaning a funder’s spreadsheet before importing it into the organisation’s database is doing integration work. A citizen downloading information held by one branch of government so another branch can see it is, for a few minutes, functioning as a very patient API.
The question is therefore not simply whether something has been digitised. It is whether the digital pieces have been designed to form a system.
Connection is the easy part. Meaning is harder.
Even that definition is not quite enough, because systems can exchange data and still misunderstand each other.
Suppose one database records a country as “Portugal”, another stores PT, and a third uses the international three-letter code PRT. A developer can translate between those representations fairly easily. Now imagine one organisation classifies a participant as “active” when they have attended an activity during the past twelve months, while another defines “active” as anyone whose account has not been formally closed. The same word now carries different meanings.
Or take something as ordinary as a person’s identity. One system treats an email address as the unique identifier. Another assigns a permanent numerical ID. A third records a person against their employer. The person changes jobs and changes email address. All three systems still contain perfectly valid records, but they no longer necessarily know that those records refer to the same human being.
This is why interoperability is much more than attaching digital pipes between software. Systems have to connect technically, but they also have to agree sufficiently on structure, meaning and process. The European Interoperability Framework reflects this by treating interoperability through several layers — legal, organisational, semantic and technical — rather than reducing the problem to software alone. The Interoperable Europe Act takes the same broader approach to public services and now requires interoperability assessments in certain cross-border public-sector contexts.
Our own research on shared data infrastructure reaches the same conclusion. Standards such as DCAT allow different data catalogues to describe datasets in compatible ways; geospatial standards allow environmental information from different territories to be combined; health-data standards allow records generated in one system to be interpreted elsewhere; and Open311 created a common model for exchanging information about civic service requests.
The difference matters because sending information is not the same as preserving its meaning. A spreadsheet can travel perfectly well while becoming almost useless when it arrives.
The invisible architecture of standards
Standards don’t receive much affection because, when they work, they disappear.
We do not normally celebrate the fact that a charger fits a socket or that a web page can be opened by browsers made by different companies. We simply expect these things to work. The inconvenience begins when someone decides that the ordinary socket is insufficiently innovative and the lamp must now have its own proprietary electrical civilization.
Digital systems face the same temptation.
An open standard is essentially an agreed set of rules that different actors can implement. A standard can describe a document format, a data field, a method for exchanging information, an identity credential or the way a service requests something from another service. When the specification is openly available and can be implemented independently, one company does not need to own both sides of the conversation.
That distinction becomes powerful in public infrastructure. Europe’s environmental data systems, for example, have been shaped for years by the INSPIRE framework and common geospatial standards. A river basin does not stop at a national border simply because government databases do, so environmental monitoring becomes far more useful when information collected in different places can be combined. Our research describes this as one of the reasons interoperability and open standards have become sovereignty tools: they allow institutions to remain locally controlled while participating in larger shared systems.
The same principle appears in public data. Europe’s data portals do not need to run as one enormous continental database. National and local catalogues can remain separate while common metadata standards allow their datasets to be discovered together. Federation — many systems cooperating without surrendering their separate existence — is one of the more interesting alternatives to the idea that digital integration must mean centralisation.
That point will matter later, because good interoperability does not mean connecting everything to everything else. Sometimes the most important design decision is knowing what should not be connected.
The citizen should not be the courier between institutions
The civic consequences become clearer when we return to public services.
Public administration is inherently fragmented for good reasons. Tax authorities, health services, municipalities, universities and social-security institutions perform different functions, operate under different laws and should not casually share everything they know. A democratic state should contain boundaries.
The problem begins when legitimate institutional boundaries become accidental technical walls and the burden of crossing those walls falls on the citizen.
If Authority A already holds a verified piece of information that Authority B is legally entitled to request, there is a fundamental difference between designing a secure mechanism through which that information can be exchanged and telling the citizen to retrieve the evidence, transport it and submit it again.
This is the idea behind the once-only principle: public administrations should not repeatedly ask people and businesses for data already held by a competent authority when the legal and technical conditions exist for that data to be reused. The EU’s Once-Only Technical System is now designed to allow public authorities in different Member States to exchange official evidence at the citizen’s request for certain cross-border procedures. The Commission describes the purpose plainly: if another authority already holds the necessary information electronically, citizens should not have to provide it again themselves.
This may sound like a modest administrative improvement. It is more significant than that, because it changes who pays for institutional fragmentation.
Without interoperability, the cost is transferred outward. Citizens spend time discovering which document is required, where it can be obtained, whether it needs translation, which version is current and how it must be submitted. Businesses do the same at larger scale. Public servants spend time verifying and re-entering information. Errors proliferate because the same fact now exists in several places and may not be updated consistently.
And those costs are not evenly distributed.
For somebody confident with digital systems, fluent in the administrative language, equipped with reliable internet and able to spend twenty minutes resolving a portal problem, the friction may be irritating but manageable. For an older person, somebody with a disability, a recent migrant, a citizen with limited literacy, a person using only a mobile phone or a worker who cannot spend an afternoon navigating public administration, the same friction can become an access barrier.
We tend to discuss the digital divide as though it were mainly about devices and connectivity. Those matter enormously, but there is another divide hidden inside system design: the amount of administrative competence a service demands from the person using it.
A public service can be online and still be inaccessible in practice.
This is why interoperability belongs in conversations about inclusion. Better systems reduce the amount of technical and bureaucratic expertise citizens need simply to exercise ordinary rights.
Estonia did not abolish bureaucracy. It changed where the work happens.
Estonia is often presented as digital-government folklore, complete with the implication that the entire country wakes each morning delighted to authenticate itself electronically. The more interesting lesson is not that Estonia put services online. Many governments have done that.
It built infrastructure allowing institutions to exchange information without turning one central database into the owner of everything.
X-Road, first launched in Estonia in 2001 and now used in several countries, provides a standardised and secure data-exchange layer through which separate information systems can communicate. Estonia’s public-sector systems remain distributed, but they can request authorised information from one another through a common architecture. The current Interoperable Europe catalogue describes X-Road as an open-source, secure data-exchange layer, while the European Commission’s material on Estonia explains that it became the main interoperability solution connecting government databases.
The civic significance is easy to miss if we focus only on the technology. When the responsible registry is treated as the authoritative source, another public service can retrieve permitted information instead of building yet another unofficial copy or asking the citizen to become the courier.
Our research points to the same lesson: Estonia’s implementation of the once-only principle allows data to be fetched from the responsible authority, improving consistency and reducing repetitive interactions.
Interoperability, in other words, is partly about where institutional memory lives. Does the system know where the authoritative information is, or does every office maintain its own version and ask the person standing at the counter to reconcile the differences?
A health record crossing a border is a civic question too
Healthcare makes the stakes even clearer.
A patient does not become medically blank when crossing a border. Yet historically, health-information systems have often behaved as though they did. A prescription, allergy or patient summary is useful in another country only if the receiving system can understand the information and trust where it came from.
Europe’s health-data infrastructure has therefore required common exchange formats and cross-border services. Our research describes the European Electronic Health Record Exchange Format as an attempt to make health information interoperable by design, while MyHealth@EU and the broader European Health Data Space provide the institutional framework through which information can move under defined rules.
Notice what changes when this works. The citizen no longer needs to understand the architecture. That is precisely the point. Infrastructure succeeds when the complexity is absorbed by the system rather than exported to the user.
This is one of the reasons we should resist treating interoperability as an obscure concern for IT departments. It shapes whether rights and services remain usable as people move between institutions, cities and countries. Academic qualifications, social-security records, company registrations, driving licences, tax information and health services increasingly depend on the ability of public systems to exchange information across administrative boundaries. The Interoperable Europe Act explicitly identifies these kinds of cross-border public services as core use cases.
Europe’s freedom of movement was designed politically long before its databases learned how to follow.
Some of today’s interoperability work is, in a very literal sense, the digital infrastructure of rights that already exist on paper.
Your data can leave and still be trapped
The same problem appears in our personal digital lives.
Most of us now understand the instinctive meaning of data portability. If we leave a service, we want to take our information with us. Yet portability is not guaranteed merely because a platform has placed an Export button somewhere in Settings.
Imagine leaving a platform that manages your projects. It provides an export containing every project title and description, which sounds promising until you discover that comments are missing, attachments are stored separately, dependencies between tasks are lost, user permissions cannot be reconstructed, dates use an unusual format and the history showing who changed what has disappeared.
Technically, your information has left.
Functionally, part of the system has remained behind.
This distinction between data extraction and usable portability is critical. Information contains relationships as well as values. A contact may belong to an organisation, participate in several projects and carry specific permissions. A learning record may connect a person, course, assessment, credential and date. A document may have versions, authorship and access rules. If those relationships disappear during export, the data may survive while its organisational meaning does not.
Open formats help because their specifications can be implemented independently. Common standards help because another system can recognise the structure. Documented APIs help because migration does not depend entirely on the cooperation of the incumbent supplier.
But there is no magic format that makes every migration effortless. Interoperability reduces dependency; it does not repeal complexity.
That distinction matters enormously for open source as well.
Open source is not a universal translator
An open-source application can be beautifully interoperable. It can also be a magnificent island.
Two open-source platforms may use completely different data structures. A proprietary service may implement an excellent public API and widely adopted standards. A self-hosted system can still make migration unnecessarily difficult if its internal architecture is undocumented.
The relationship between openness and interoperability is therefore close but not identical.
Open-source licensing addresses our rights over the software: whether we can inspect, run, modify and redistribute it under the licence terms. Open standards address whether independent systems can implement the same rules. Open formats address whether information remains intelligible outside one particular application. Open APIs address whether other services can interact programmatically with the system.
When these principles reinforce one another, something powerful happens. Different organisations can choose different tools without requiring every participant in an ecosystem to buy from the same supplier.
That is why our strategic work on open infrastructure repeatedly pairs open source with open standards, distributed systems and cross-institutional integration. The goal is not merely to replace a proprietary product with a libre one. It is to create infrastructure in which schools, NGOs, municipalities and other actors can cooperate without making cooperation synonymous with dependency.
This is an important corrective to one of technology’s favourite false choices. We do not have to choose between a single giant platform that integrates everything and complete fragmentation. Federated systems can remain locally governed while sharing common protocols and data structures.
The internet itself would be a rather persuasive example.
Interoperability can widen competition, or prevent it
There is another civic dimension that is rarely felt at the service counter but matters enormously behind it: public procurement.
Suppose a municipality has used the same proprietary platform for twelve years. The product is not necessarily bad. The difficulty appears when the municipality wants to replace one component. Its data uses proprietary structures. Several other applications depend on undocumented connectors. Staff identities are tied to the vendor’s authentication service. Historical records cannot be exported cleanly. Custom integrations would need rebuilding.
A competing supplier may offer a better product at a better price, but it is not competing only against the incumbent’s product. It is competing against twelve years of accumulated dependency.
Poor interoperability can therefore become a market barrier.
The nominal contract ends. The architectural contract continues.
Open standards and well-documented interfaces change that balance because suppliers can compete for pieces of an ecosystem rather than demanding ownership of the whole stack. They do not eliminate switching costs, but they make replacement more plausible.
This is one reason digital sovereignty and competition policy keep wandering into the same conversation. Sovereignty does not simply mean where a server sits. It includes the practical ability to choose, replace, adapt and combine technologies.
Our research on public digital infrastructure frames open standards explicitly as sovereignty tools because they allow governments and communities to avoid dependence on a single implementation while still exchanging information across systems.
At civic scale, that matters because public money should ideally build institutional capacity rather than deepen technical captivity.
Interoperability also makes democracy more usable
There is a further connection that deserves more attention.
Democracy increasingly runs on information systems. Public budgets, consultations, procurement records, environmental measurements, mobility data, council decisions and planning processes all pass through digital infrastructure. Citizens cannot participate meaningfully in what they cannot find, interpret or combine.
This is where interoperability intersects with open data and civic technology.
A city may publish public spending information, transport data and project-status information in three completely different systems. Each dataset is technically open, yet a journalist or civic group may need weeks of cleaning before they can understand how the records relate. Another city may publish the same kinds of information using common data standards, stable identifiers and accessible APIs. The difference is not simply technical quality. It determines how easily society can reuse public information.
Our research contains good examples of this relationship. The Open Contracting Data Standard allows procurement information to be published in a common structure so journalists, researchers and civic organisations can compare tenders and build monitoring tools. Platforms such as Decidim can combine participation processes with public information, while common civic APIs such as Open311 allow citizen reports to move between interfaces and municipal service systems.
The principle is almost architectural democracy: public information becomes more valuable when citizens are not forced to reconstruct the state’s internal fragmentation before they can understand it.
Interoperability therefore supports accountability in a way that is easy to underestimate. A dataset that can be compared is more useful than one that merely exists. A public record that can be linked to another public record becomes more revealing. A civic platform that can interact with existing systems is more likely to survive than one that becomes another digital island.
Transparency without interoperability can leave us with thousands of downloadable files and very little practical visibility.
The dangerous fantasy that everything should talk to everything
At this point, interoperability begins to sound so useful that the obvious conclusion is to connect everything.
That would be a mistake.
The privacy article immediately before this one matters here. Information flows create power as well as convenience. A system in which every database can automatically query every other database is not a sophisticated civic utopia. It may simply be surveillance with excellent documentation.
Interoperability must therefore be governed by purpose, permission and proportionality. Systems may share a language without being entitled to share every piece of information. Identity can be interoperable without creating a universal profile. A health provider may need access to one credential without learning unrelated details. A municipal service can verify eligibility without necessarily copying the entire underlying record.
The emerging European Digital Identity Wallet is interesting partly because it aims to make verified credentials usable across services while giving the individual more control over what is disclosed. Our research describes this movement toward open-standard identity infrastructure as an attempt to combine portability with data sovereignty rather than treating centralisation as the only path to integration.
The real goal, then, is not maximum connection.
It is intentional connection.
We want systems to cooperate where cooperation serves people, while keeping meaningful boundaries where privacy, security, autonomy or institutional independence require them.
That is a much harder design problem than installing an integration plugin.
It is also the more interesting one.
What sovereignty looks like from the kitchen table
Digital sovereignty often arrives wrapped in very large geopolitical language. It evokes cloud infrastructure, semiconductors, strategic autonomy and ministers standing in front of blue flags.
At human scale, it can be tested with simpler questions.
Can I take my information somewhere else? Can another application understand it? Can I use one identity across services without handing every service my entire digital history? Does using one platform require me to adopt five others from the same company? Can my municipality change providers without rebuilding every public service connected to the old one? Can a local company build a new service using the same public standards? Can a citizen group reuse public data without negotiating a private licence?
These are sovereignty questions too.
A society does not become digitally sovereign because it refuses all external technology. That would be neither realistic nor particularly clever. Sovereignty lies in retaining enough agency to choose, combine, inspect, replace and govern the systems upon which public and private life depend.
Interoperability is one of the quiet mechanisms that makes that agency possible.
And it brings us back to the person moving a PDF between two portals.
The absurdity of that moment was never really about the PDF. It was about architecture. Somewhere behind the screens, two institutions had not established an appropriate way to exchange information, so the missing infrastructure had been outsourced to the citizen.
The same thing happens inside organisations every day.
And this is where we need to go beneath the floorboards properly.
Go Beneath the Floorboards
The public version ends here, but the practical work begins in the full edition.
Paid subscribers can continue with the professional section, where we map what disconnected systems actually cost an organisation: hidden staff time, fragile integrations, identity gaps, middleware, procurement risk, vendor lock-in, and the difference between software that merely works and an architecture that can actually evolve.
You’ll also unlock the REDefine Systems Interoperability Map, a connected, fillable workbook designed to help organisations map their systems, data flows, manual integration work, exit risk, and improvement priorities without recreating the very duplication the article is trying to solve.
Subscribe to the REDefine newsletter to unlock the full article and subscriber resource.
