| CIVIC-SCOPE Analysis | |
|---|---|
| Context | Interests |
| Fragmented digital landscape with 220+ disconnected portals. Agencies operate as "software companies," leading to vendor lock-in, poor data security, and citizen frustration. | Ministries: Want autonomy and control over their own budgets/vendors. Vendors: Profit from complexity, fragmentation, and maintenance contracts. Citizens: Want a "tell us once" experience. Tech Talent: Avoids low-paying civil service roles. |
| Vision | Incentives |
| A unified national digital stack built by a central "Digital Service" elite unit. Proactive governance where data flows securely between agencies, eliminating the need for citizens to be couriers of their own documents. | Agencies: Incentivized to build bespoke tools to fit their specific quirks rather than adapt to standards. Vendors: Incentivized to create proprietary dependencies. Govt: Incentivized to centralize to cut costs and improve speed/security. |
| Challenges (SCOPE) | |
Structural: Breaking the "ministry silo" model where every agency controls its own IT stack. Capacity: Attracting top-tier developers to government pay scales (requires special structures). Operational: Migrating legacy data and systems without service interruption; securing the government's own leaky data practices. Political: Resistance from ministers losing control over procurement; fears of a "surveillance state." Economic: High initial cost of building the core stack before savings from retired legacy systems are realized. |
|
Challenge Score (1 – 5) Budget: 4 | Logistics: 4 | Legislative: 4 | Political Capital: 3 | Execution: 5 | Time: 4 | Stakeholders: 4 | Risk: 3 |
|
Historical Context and Policy Evolution Digital government in the Maldives began in earnest with the establishment of the National Centre for Information Technology (NCIT) in 2003. For much of the following two decades, digitalization was fragmented. Individual agencies developed their own silos; the tax authority launched "MIRAconnect" in 2011, and Immigration developed the "Imuga" portal, but these systems did not talk to each other. Citizens were often forced to act as couriers, carrying physical documents between government offices that theoretically had access to the same data. The rollout of the digital identity system "eFaas" in 2015 provided the crucial foundational layer for a unified system. High internet penetration – among the highest in South Asia – and widespread smartphone usage created a fertile environment for digital adoption. The COVID-19 pandemic acted as a powerful accelerant, forcing the government to move services online rapidly to maintain continuity during lockdowns. This period demonstrated the necessity of digital resilience and exposed the vulnerabilities of paper-based systems. In 2023, the government launched "OneGov," a unified platform designed to consolidate disparate services into a single portal. This represented a major shift from agency-centric to citizen-centric service design. While efficiency gains have been reported, challenges persist regarding cybersecurity, as evidenced by past attacks on government infrastructure, and the digital divide affecting elderly populations. The current policy trajectory is focused on integrating the remaining offline services and leveraging data exchange to create a proactive, rather than reactive, state bureaucracy. |
|---|
The ambition for a digital Maldives has been a recurring theme in national planning documents for over a decade, yet the lived reality of the digital state remains a source of persistent, structural friction for the citizen. A mid-2024 survey of government software infrastructure reveals a sprawling, chaotic ecosystem of over 220 separate, purpose-built software portals and websites across various agencies. While the intent behind each individual procurement was likely modernization, the aggregate result is a fragmented landscape where data does not flow, logins do not transfer, and the burden of integration falls entirely on the user. This fragmentation represents a failure of state capability that erodes public trust. When a citizen is required to physically carry a stamped document from one department to another because the two digital systems cannot speak to one another, the state effectively admits that its internal coherence is lower than the service expectations of the public. This inefficiency creates a government that makes citizens work for their entitlements rather than a government that works to serve them.
To resolve this, we need to look beyond the surface-level digitization of forms, which often merely replicates paper bureaucracy on a screen, and address the deeper architectural and organizational flaws that incentivize this fragmentation. This is also enormously economically costly in ways that do not show up clearly in any single line item but accumulate across the system. We have heard from citizens and from government staff themselves that current systems are frustrating to use, time-consuming, and creates opportunities for errors and delays that would not exist in a properly integrated system.
Ministries cannot simultaneously be top-end software companies
A root of the current dysfunction lies in what a fundamental category error regarding the role of a government agency in the digital age. Ideally, the mandate of a ministry, whether in housing, education, or transport, is policy formulation and service delivery. Their expertise lies in defining who needs a home, how a national curriculum operates, or where a bus route runs. It does not lie in the high-level architecture of secure database systems, the management of cloud infrastructure, or the user-experience design of mobile applications. This is not to dismiss the knowhow of experts within government, but to consider the reality that the most talented experts in one field, who have spent their lives and careers developing that expertise, cannot realistically have an equal amount of expertise in a whole other field. Expecting any one person to have complete mastery over two totally different domains would be unreasonable.
In a truly digital state, all government software should be the best possible software, and they should be the best possible tools to best implement the best possible policies. Different people can be specialized in 40 different policy areas to best contribute effectively to 40 different government agencies, but it is impossible to expect someone to have true expertise in two wholly different fields – those with the ideal level of policy expertise would not have strong enough programming expertise to make software at the top-of-the-line standard that a digital government should have across the board, and those who have good enough programming expertise would not have had the time over their careers to develop the policy expertise needed to know the design choices that best suit policy outcomes. The management structures and leadership that truly understand how best to implement policy may not be the best management structure to most efficiently maintain and build out complex technological systems.
Even beyond that, a truly digital state should have complete integration and compatibility across systems. From a specialization perspective, those most capable of building out and managing a massive and enormously complex operating system of government would have their talents be most effectively used in roles that can best use their expertise without demanding too much. Expecting every government agency to also function as a small software company cannot feasibly result in the best possible technology, even beyond coordination issues. We can compare headcounts of tech corporations managing equally massive and complex tasks under one umbrella and hierarchy, vs how around the same headcount managing government software in the Maldives may be spread out across fifty different teams that don’t really have much communication or coordination across each other. That same headcount and talent, with more empowerment and coordination to work together as a whole team, could build elite technology stacks for government.
In any system, individuals respond to incentives and constraints. The constraints of coordination or knowhow will sometimes mean reliance on external vendors. Vendors respond to incentives as individuals or firms who themselves also have their livelihoods or revenue streams to consider, and these incentives are to build bespoke systems optimized for vendor lock-in rather than interoperability. Each ministry ends up with its own database schema, its own internal logic, its own user interface conventions. These systems might work adequately within their narrow domain, but they create enormous inefficiency at the system level because they cannot talk to each other as best needed. This is the predictable outcome of an organizational structure that treats IT as a ministry-level function rather than a government-wide infrastructure layer. We have created a system where each agency optimizes for its own convenience rather than the user's experience, and where there is no one with the authority or technical capacity to enforce coherence across the whole system.
Civil service pay scales for technical roles within ministries are very low, making it difficult to attract or retain elite tech talent within individual ministries. The developers who do remain in the public sector are often underpaid relative to their market value. As in any case where government employees are underpaid relative to their workload, this creates a need to supplement their income with freelance work or side contracts – just like teachers offering tuition, or doctors moonlighting at private clinics. The existence of proprietary systems also create a secondary market for maintenance. When the salaries at available jobs are low, this fragmentation is profitable; there is steady money in the perpetual repair of a flawed ecosystem. We therefore face a situation where the structural incentives align against quality. The low pay for in-house staff drives talent away or into conflicts of interest, while the procurement model rewards vendors for complexity rather than simplicity. This is not primarily about individuals working toward their goals, but about a system that produces bad outcomes even when people are trying their best due to the underlying incentive structures within the design of the status quo. Fixing this requires changing the structure, not just exhorting people to do better within the current broken system. Designing a system where the incentives of individuals within it align with the broader goals of government is required.
We can use building construction as an analogy. We would not expect each ministry to individually construct their own office buildings or install their own electrical system, plumbing, and elevators. If we did, we couldn’t expect those buildings to be at the level of those built by professional construction firms. Organizations specialized in construction, with sufficient resources and expertise to build across government or even private sector roles, can build offices for various government agencies at elite standards. In the end, the same number of buildings being developed by the same teams of construction workers would still be at a much higher quality and meeting consistent standards across the board compared to if ministries hired individual construction employees and procured their own cement mixers. The same principle applies to digital infrastructure.
Well-paid technical jobs in a unified government stack
An alignment of incentives can come about from centralizing the state’s digital capacity into a single, elite authority. This would not be merely a regulator, but a builder – a "Digital Service" modelled on the successes of Singapore’s GovTech or the UK’s Government Digital Service (GDS). This body would be empowered to take the existing OneGov platform – currently functioning primarily as a portal – and evolve it into the core of a unified national digital architecture. Under this model, individual ministries would no longer have to commission independent software builds. Instead, they can define their policy requirements and user needs, which the central authority would then translate into digital products using a shared stack of common components. We would move from 220 portals to a single platform all running on the same underlying rails sharing the same data standards and security protocols.
By pooling the fragmented IT budgets of dozens of ministries while having an increased scope for talent, the central authority can justify paying top-tier competitive salaries for developers. Paying high salaries for efficient outputs that can result in massive cost savings and improved government efficiency results in a net gain for government, while developers win out by getting stable income streams commensurate to their talents in a workplace that best utilizes their skills. With this pay and prestige, there is less need to supplement civil service paychecks with side hustles. This team would have the jurisdiction to implement big-picture integrations that siloed ministry teams simply cannot touch.
Securing the government's own house
While building new systems is essential, we also need to address the glaring vulnerabilities in how the government currently handles information. To lead by example, the state needs to secure its own house first. The government holds the most sensitive data in the country (medical records, tax filings, criminal histories, social protection details). Yet a mid-2024 survey suggests that much of this data is stored in fragmented, insecure ways that rely on security through obscurity, a strategy that works right up until the moment it fails catastrophically.
It is common practice in many agencies to find sensitive private data kept in shared Excel spreadsheets hosted on OneDrive or Google Drive, where broad groups of staff have view and edit access they do not need for their specific roles (often because it is easier to share a link with everyone than to manage permissions individually). This is a disaster waiting to happen. We have seen the consequences of this globally; in the UK, similar lax controls led to the accidental publication of the entire Northern Ireland police force's personnel data in a spreadsheet error, a mistake that endangered thousands of lives. In a small community like the Maldives, where anonymity is nearly impossible and social connections are tight, a leak of sensitive health or financial data would be socially catastrophic. The damage would not just be to the individuals whose data was leaked but to trust in government institutions more broadly. Once people believe that their private information is not safe with government, they become reluctant to engage with services, to report problems, to seek help when they need it. This undermines the entire social contract.
There is a need to conduct a whole-of-government audit of privacy and data security standards for all datasets across all ministries. The goal would be to identify every instance of sensitive private data and list exactly who has view and edit access. We would enforce a strict need-to-know principle: access permissions minimized to only those staff who actually require access for their specific job functions, implemented and monitored by the national digital body (building on the NCIT/OneGov mandate).
Rules are not enough though; we need technical controls. Strict punishments would be set for any sharing of private government data to outsiders, but the system itself must be designed to prevent and detect it. Every access to a sensitive record (whether by a clerk, a director, or a minister) must be logged with a name and a timestamp in an immutable audit trail. If a record is leaked, the system should be able to tell exactly who accessed it and when. This audit log should be an effective deterrent against internal corruption and curiosity. If an official knows that their search history is permanent and auditable, they are far less likely to browse the records of a political rival, a neighbour, or a celebrity. We have heard from current and former civil servants that this kind of casual snooping happens – looking up friends, family members, celebrities, political figures out of curiosity rather than legitimate work reasons – and it is enabled by the current lack of accountability. Building in strong audit trails changes the incentive structure fundamentally.
From reactive to proactive governance
Effective digital governance can cause a transformation in the relationship between the citizen and the state. Currently, our digital government is reactive: it waits for a citizen to have a need, find the right form, gather supporting documents which the government often already possesses in another silo, and submit an application. The citizen bears the burden of navigating the system, figuring out what they are entitled to, and assembling proof of things the government already knows. With a unified data architecture, the state could become proactive. Because the data layer is shared, the system would know that a citizen has turned 65 and is eligible for a pension, or that a family has fallen below a certain income threshold and qualifies for subsidies. Instead of waiting for an application, the system could proactively notify the citizen of their entitlement, or even auto-enrol them (with appropriate safeguards and opt-out mechanisms for those who prefer not to participate). This shifts the burden of bureaucracy from the individual to the system. It creates a tell us once standard where a birth, a death, or a change of address is recorded in a single registry and propagates across the entire government, eliminating the need for the citizen to act as a courier for their own data between ministries183UK Government Digital Service (GDS) principles and "Tell Us Once" service effectiveness [www.gov.uk/government/organisations/government-digital-service](https://www.gov.uk/government/organisations/government-digital-service). This is the difference between a digitized bureaucracy (paper forms turned into PDFs) and a digital state (processes re-engineered for data). It moves the government from a posture of gatekeeper to one of enabler.
Implementation and guardrails
Transitioning to this model would require a phased approach to transition from legacy systems to a standard one. We could begin by establishing the central Digital Service with a clear mandate, gradually integrating in developer teams at individual government agencies to be within the umbrella of the overall Digital Service. The first phase would review the existing landscape to identify the most critical high-volume services to migrate to the new stack. Throughout, this central body would act as the architect while the ministries act as the client. The Ministry of Housing defines the policy for social housing eligibility, but the Digital Service builds the algorithm and the interface in line with their standardized rules. This separation of concerns allows policy experts to focus on outcomes and technical experts to focus on execution. It also creates clear accountability: if the system does not work, we know whether the problem is in the policy design (the ministry's responsibility) or the technical implementation (the digital service's responsibility).
This will not be a quick process. Building a unified digital stack properly will take years, not months. We need to be realistic about timelines and not promise transformation that will arrive next year. Based on other countries' experiences (Estonia spent a decade building their system, though they were starting from a less developed baseline), we might be looking at a 5-7 year timeline to full implementation, with incremental improvements visible along the way. The key is to start making progress and to resist the temptation to declare victory prematurely or to abandon the effort when early challenges emerge. Digitization is not just an IT or technology aspect of overall policy, it is a core aspect of overall state capacity and is a primary interface for the relationship that citizens have with their government.
A unified state digital stack concentrates power and risk as well as efficiency. It therefore needs strong governance. The legal framework should spell out who owns each dataset, which officials and contractors can access which systems for which purposes and how every access is logged and audited. An independent body, with technical capacity and public reporting duties, should oversee the integrity and security of the stack. People must have clear ways to challenge errors, correct their data and complain when something goes wrong. Regular public reports on system uptime, error rates, privacy breaches, and citizen satisfaction should be mandatory. If the digital stack is going to be the foundation of government service delivery, citizens have a right to know whether it is working well or poorly. This transparency also creates pressure for continuous improvement and makes it harder for problems to be hidden or ignored. The governance structure needs to be robust enough to prevent both technical failures and political abuse. This means clear separation between the operational team (who build and maintain systems) and oversight bodies (who audit and investigate), with genuine independence for the latter.