The observation
I keep noticing that the word digitalisation is used to describe two very different things. One is changing the interface through which citizens submit information. The other is changing the way institutions receive, verify, share and act on that information. The first is relatively visible. The second is the work that determines whether the citizen actually experiences a better service. An online application can look modern while its supporting offices still rely on printed submissions, manual calls, spreadsheets and unrecorded approvals.
This is not exclusively an African problem. Government departments everywhere inherit systems built around different mandates, procurement eras and data definitions. A portal can hide those divisions from the applicant for the first five minutes and then expose them again through delays, requests for duplicate documents and contradictory status messages. The World Bank's GovTech Maturity Index deliberately examines core government systems alongside service delivery, participation and enabling institutions; a website alone cannot represent the whole system. 1
This is an independent engineering analysis, not a claim that every example happened in one particular deployment. Scenarios are illustrative; technical examples are sanitized and omit clients, products, credentials, and private integrations. Factual claims are linked to public sources. Photography is credited to the original Unsplash photographer.
The screen is only the front door
A citizen should be able to distinguish three states: the service accepted a request, an authorized office is processing it, and the competent authority made a decision. Too many portals collapse those events into one reassuring green message. The application number exists, but there may be no reliable workflow tying that number to the next institution. A beautiful upload button does not solve identity verification, eligibility rules, interdepartmental communication, archival obligations or the right to challenge an incorrect outcome.
Imagine a business registration that requires a tax identifier, an address confirmation and an approved corporate name. If each agency independently asks for the same facts and none can verify the others' results, the applicant becomes the integration middleware. They collect proofs, move files and reconcile disagreements. Digitising their travel between desks does not remove that architecture; it gives the journey a browser tab. 2
Institutions must agree on what a record means
Interoperability is not achieved by creating an API gateway and announcing that all agencies are connected. One system may represent a person by a registration number, another by a name and birth date, and a third by a local office file. Their schemas can technically communicate while their semantics disagree. Dates, address histories, entity ownership, eligibility, expiration and revocation must have explicit meanings. Otherwise integration simply moves unreliable data faster.
The useful starting point is a limited set of authoritative claims with traceable provenance. An agency that establishes a legal fact should be identifiable as the authority for that fact. Another agency should be able to verify the current claim with a lawful purpose rather than maintain an uncontrolled copy forever. That requires documented schemas, versioning, error handling, appeal processes and mechanisms for correcting records. It is less glamorous than a national portal, but it is what makes a transaction finish.
Data sharing is not permission to collect everything
Centralisation is often presented as the natural destination of digital government. It can simplify integration, but it also concentrates power and failure. A shared infrastructure should not quietly become a universal data lake accessible to every department. A tax officer, licensing official and hospital administrator do not need identical views of the same citizen. Their lawful purposes and access boundaries are different, and a service must enforce those boundaries at the data source rather than only hide fields in the interface.
The World Bank describes digital public infrastructure through components such as identity, payments and secure data exchange, not through a requirement that every record live in one enormous database. 2 What matters is that useful claims can be established, verified and revoked with consent or another lawful basis where appropriate. Audit records should explain the requesting institution, the purpose, the specific information disclosed and the authority for doing so. Independence between institutions should not mean permanent isolation; interoperability should not mean indiscriminate visibility.
A completed service is a better metric than a launched website
Public-sector technology programmes often measure new portals, registered accounts and online submissions. Those numbers can be useful, but they are easy to celebrate without measuring the work that follows. I would rather know the median time from accepted application to lawful decision, the proportion completed without an office visit, how often a document is requested twice and how frequently an applicant must restart because an upstream system failed.
Good measurement also needs to be fair. A complex appeal or difficult eligibility case may reasonably take longer than a routine renewal. The right objective is not to automate every exception into a quick rejection. It is to make ordinary work predictable, preserve the ability to request human review and expose delays that would otherwise disappear into departmental boundaries. The United Nations E-Government Survey and the World Bank's service-delivery indicators offer context for comparing progress, but local transaction-level evidence still matters. 13
The less visible requirement is institutional change
Software cannot reconcile conflicting mandates by itself. If two agencies disagree over which one owns a record, a technical team cannot solve the dispute by inventing a new database table. Institutions need governance over shared identifiers, retention periods, correction authority, procurement, security operations and service-level responsibilities. Without those decisions, developers end up encoding political or administrative ambiguity into brittle logic that nobody wants to maintain.
This is where open standards can help, but standards are not substitutes for decisions. The UCL work on digital public infrastructure treats its institutional dimensions as part of the problem, and that is important. 4 A shared definition of a claim, a secure transport protocol and a verification service create possibilities. They do not tell an official when a disputed identity should be corrected, which court order applies, or who compensates an applicant for a wrongful rejection.
Build around the journey, not the department
A sensible implementation begins with one high-volume service and traces every step: applicant intent, identity, evidence, approvals, payments, notifications, exceptions and archival state. The team should map where facts are duplicated and where nobody can say which record is authoritative. A first release can then automate a complete narrow journey, including failure and appeal paths, before expanding to additional services. That is a more demanding success criterion than demonstrating a login screen.
For engineering teams, it also means designing for partial failure. A payment may settle while the receiving agency is unavailable. A verified credential may expire after submission but before review. One ministry may deploy a breaking schema version while another still processes older messages. Durable operation identities, consistent status models, audit logs and recovery queues become part of public service delivery. The OECD's digital-government principles emphasize coherence across government rather than isolated technical experiments. 5
What should remain human
Not every government decision should become a rules engine. Context, discretion, legal interpretation and the ability to challenge an administrative act matter. Better infrastructure can present evidence to trained officials and make their decisions accountable, but it should not erase the distinction between a system recommending an outcome and an authorized person making a binding decision.
The useful end state is not a government in which nobody speaks to a human. It is a government in which people do not have to become couriers between databases, routine services do not require unnecessary journeys, and difficult decisions come with reasons and review. That is much harder than digitising paperwork. It is also a far better use of software engineering.
What follows
I would judge the next wave of digital-government projects by the number of journeys they complete reliably, not the number of portals they launch. The technology can support this, but it requires serious attention to data authority, interagency contracts, security, rights and operational ownership.
When we call a website digital government, we risk accepting the interface as evidence that the institution underneath has changed. The more interesting question is whether the citizen can now finish the same legitimate task with less friction, less repetition and more accountability. Until that changes, some of our most impressive portals are simply better-looking entrances to the same offices.
Sources and further reading
