Architecting coherent government

Government can operate many applications and still deliver fragmented services. A request crosses institutions, mandates, registers and contracts that citizens should not have to coordinate themselves. The problem is not simply a shortage of technology: it is the difficulty of making coherent decisions across a distributed institutional system.

Enterprise architecture (EA) connects public objectives to capabilities, services, processes, information, applications and infrastructure. It describes the current state, a target state and the transition between them. Here, “enterprise” means an institution or the institutions jointly delivering a public outcome, not a private company or an IT product.

Public Framework proposes a shared vocabulary and metamodel, PFML, to make these relationships explicit and verifiable. OECD’s diagnosis for Romania and international practices support the need for institutional architecture capability. They do not demonstrate that Public Framework is superior to alternatives; that requires separate evaluation. ^{[1] [6]}

This paper recommends gradual adoption: a clear pilot mandate, a bounded cross-institutional service, a minimum useful architecture, decision rules and outcome evaluation. It does not propose mapping the entire state before improving a service, or promise savings without measurement.

Evidence from Romania

The OECD’s 2023 review recommends stronger digital-government leadership and coordination, investment management across the lifecycle, skills development, clear data accountability and a coherent approach to services. These recommendations concern the capability to transform government, not merely the procurement of systems. ^[1]

The country note in Digital Government Outlook 2026 provides a more recently published reference: Romania scores 0.24 in the 2025 Digital Government Index, against an OECD average of 0.70, and 0.59 in the OURdata Index, above the average of 0.53. A credible diagnosis recognises both gaps and progress. ^[2]

Interpretation limit: the 2025 indices cover 2023–2024. DGI assesses enabling foundations for digital government; OURdata assesses open-data policies. Neither directly measures the quality of every service, EA maturity or Public Framework’s impact. A national score cannot establish that a particular tool will improve outcomes.

Where architecture contributes

A local project may optimise one step while shifting cost to another institution or the applicant. A register may offer a working API but incompatible definitions. A service may move to the cloud without simplifying its procedure. These are risk mechanisms, not audit findings about every Romanian institution.

EA exposes dependencies before investment decisions: who holds the mandate, who owns the service, which data are required, what capabilities already exist and who bears transition costs. Its value must be assessed through better decisions and service outcomes.

The proposed causal chain is shared understanding → coordinated decisions → coherent implementation → measurable public outcomes. Every link has conditions: current models, skilled people, decision authority and implementation resources. Diagrams alone do not deliver outcomes.

• Government: visibility across portfolios, reform dependencies and reusable capabilities; a shared basis for prioritising investment.
• Ministries: coordination of subordinate institutions without forcing every process into the same design; distinction between common components and legitimate differences.
• Institutions: clearer requirements, impact analysis, institutional memory and a more balanced relationship with suppliers.
• Citizens and businesses: potentially fewer documents and journeys, more predictable deadlines and accessible services. These are evaluation objectives, not benefits already achieved.

Canada applies shared architecture criteria through government-wide and departmental review boards. The UK Service Standard requires teams to address the whole user problem, work across disciplines, define success and publish performance. These examples connect architecture to delivery; they do not justify importing another country’s administrative model unchanged. ^{[6] [8]}

This paper distinguishes diagnostic studies, normative and practice frameworks, and independent assessments of outcome measurement. A recommendation is not an impact evaluation, and the existence of a framework does not prove successful implementation.

The 2012 GAO audit of 27 agencies provides an important warning: all had fully or partly defined architecture goals; 11 had fully or partly established methods or metrics; only 5 had fully or partly measured and reported outcomes and benefits. This is historical evidence, not a current assessment of US government. ^[7]

The defensible conclusion is that architecture requires mechanisms for realising and verifying value. It is not defensible to attribute all savings from an IT consolidation programme to EA or transfer savings percentages between countries.

For Public Framework, empirical questions remain: is PFML expressive enough, affordable to learn and maintain, useful for discovering dependencies and more effective than existing tools? Negative results and administrative costs should be reported alongside successes.

The European Interoperability Framework distinguishes four layers, supported by governance. Sustainable integration requires addressing them together. ^[3]

EIRA supplies a reference architecture and building blocks for interoperable public services. Public Framework needs explicit, testable mappings, rather than claims of compatibility based on similar terminology. ^[4]

Regulation (EU) 2024/903 establishes a framework for cross-border interoperability of trans-European digital public services. Interoperability assessments concern setting binding requirements affecting that interoperability, under the regulation’s conditions. Not every IT project automatically falls under the same obligation, and the regulation does not mandate Public Framework. ^[5]

Architecture models can organise assessment evidence but cannot replace legal analysis, security evaluation or data-protection duties. Reuse does not mean unlimited access to data.

Public Framework proposes a shared representation of relationships between mandate, institution, service, process, information and technology. Its intended differentiator is administrative traceability: why a service exists, who is accountable and what must change when a rule or dependency changes.

PFML is the initiative’s modelling language. Useful models should support stable references, versions, provenance and ownership of updates. These are evaluation criteria for the framework and its tools, not a claim that every feature is already implemented or verified.

The hypothesis is that an administration-oriented metamodel reduces ambiguity and coordination effort. If a profile of an existing standard solves the same problem at lower cost, the pilot should consider it. Creating a new language is not an objective in itself.

An organisational proposal, not a description of an existing mandate. Government sets common rules; ministries coordinate domains; institutions own service models and outcomes. Coordination does not require centralising all operational data or centrally approving every local change.

A pilot multidisciplinary architecture group should include the accountable decision-maker, service team, architect, legal specialist, data owner, security and procurement. Suppliers contribute technical expertise without replacing institutional accountability.

Review should be proportional to risk. Local changes that follow common rules can use a simplified path; cross-institutional changes, sensitive data and critical dependencies require joint assessment. Exceptions need reasons, competent approval and a review date. Conflicts of interest must be declared, and rejected alternatives recorded.

Governance of the Public Framework initiative is separate from governance of a public service. Framework maintainers may propose versions and rules; they cannot confer statutory powers on institutions. Official recognition or adoption would require a separate process.

Architecture should inform decisions before they are made, not become a justification written after contracting. We propose four decision gates, reusing existing mechanisms where possible:

1. Before funding: compare the user problem, desired outcome, current state, reuse options and total cost. Decide whether investment is justified.
2. Before procurement: make service requirements, data, interfaces, security, accessibility, usage rights and exit conditions explicit. Decide what to buy and what remains an internal responsibility.
3. Before acceptance: verify delivery against requirements, including integration, migration, documentation and operational readiness. Accepting a diagram is not testing a service.
4. During operation: review outcomes and costs, update models and retire obsolete components safely.

Each decision should retain options, reasons, an accountable owner, model version, risks, exceptions and review date. Contracts should provide for reusable documentation formats and knowledge transfer, subject to contractual rights and applicable law.

Total cost includes modelling, training, integration, migration, licensing, security, operation and legacy retirement. Costs transferred to another institution or to citizens are not savings.

We propose a pilot for one cross-institutional service, selected for user relevance, evidence availability, leadership support and observable outcomes. This is not an announcement of an already contracted pilot.

Stage 1 — Mandate and baseline

Agree on the service owner, participating institutions, bounded problem, responsibilities, resources and stopping criteria. Measure the current journey, including assisted channels, delays, rework and costs. Record what cannot yet be measured.

Stage 2 — Minimum model and verification

Model the relevant legal basis, actors, steps, data, registers, applications and dependencies. Frontline staff and users validate the representation. Test whether PFML expresses the cases without ambiguity and record information it cannot capture.

Stage 3 — An implementable change

Select a concrete improvement: removing a redundant check, clarifying accountability or legally reusing a data item. Compare alternatives with and without modelling and implement only after necessary reviews. An authorisation procedure is an illustrative example; the actual process and its legal basis must be established in the pilot.

Stage 4 — Evaluation and decision

Compare outcomes at similar volumes, complexity and quality levels. Where feasible, use a comparable service or phased introduction to distinguish effects from seasonality, legal changes or additional staffing. A simple before/after comparison does not establish causality on its own.

Scale only if improvement is relevant, maintenance costs are acceptable, institutional ownership exists and no critical risk remains unresolved. Agree on quantitative thresholds before implementation, after establishing the baseline. Otherwise revise or stop the approach rather than expand it to justify sunk costs.

The proposed scorecard measures outcomes, not document production. Before intervention, define each indicator, source, period, owner and interpretation limit. GAO’s recommendation for repeatable, meaningful measures aligned to objectives is central. ^[7]

Report budget savings, avoided future costs and released capacity separately. Staff time saved can increase service capacity without reducing expenditure. Avoided future investment is a counterfactual scenario, not cash recovered.

Assess net benefit over a declared horizon, including all incrementally attributable costs and sensitivity to volume, duration and adoption. Do not count the same benefit twice across institutions. Any monetary valuation of citizens’ time must state assumptions and remain separate from public-budget effects. This paper establishes neither guaranteed returns nor a GDP impact.

Avoiding additional bureaucracy

An excessive metamodel can cost more than the decisions it supports. Use a minimum set of artefacts proportional to risk and review it against actual use. Simplify or retire unused models rather than maintain them ritualistically.

Avoiding a new form of lock-in

Test portability through export, import and preservation of meaning, not just file availability. Clarify licences, specification governance and compatibility policy before adoption. Open source alone does not remove dependence on a supplier or team.

Security, data and proportionate transparency

Models may reveal critical infrastructure, vulnerabilities or personal information. Separate public and restricted views, minimise data and apply access controls. An architecture catalogue should not become a repository of personal case files. Publication requires content review and compliance with applicable duties.

Genuine alternatives

Institutions can improve governance using existing frameworks and tools, adopt only a shared vocabulary or use an interoperability profile without a new language. The pilot must compare these options. Public Framework is justified by demonstrated additional value and reasonable cost, not merely by local origin.

The main research limitation is that the sources support coordination and measurement but do not constitute an independent evaluation of Public Framework. This paper includes no interviews, national audit or original implementation results.

Romania needs a durable capability to understand and coordinate public-service transformation. EA provides a discipline for this capability when integrated with leadership, investment and delivery. The research supports this direction, not a methodological monopoly or an automatic promise of efficiency.

Public Framework proposes making the relationship between public mandate and implementation verifiable. The recommended first step is an open assessment and a bounded pilot with responsibilities, acceptance criteria and publishable results. National expansion would require validation, resources, institutional legitimacy and governance beyond this paper’s scope.

Consultation should answer four questions: which decision cannot be made well today, which architecture information is missing, what additional value does Public Framework provide, and how will we know whether the intervention was worthwhile?

Version 0.1 is a discussion basis. A subsequent revision should incorporate public-administration feedback, legal and methodological review, tested mappings and pilot findings when available. References to OECD, the European Commission or other bodies do not imply affiliation, certification or endorsement.