Online Form Without Backend Is Analog Administration With URL
OZG frontends without registers, FIM, and XÖV will leave administration analog. What cloud providers need to know.
For years, many providers have been supplying municipalities with online forms and portal solutions. Yet countless processes still end up back in manual processing because registers, interfaces and specialist procedures can’t keep pace. If you want to take the municipal digitalisation market seriously, you need to stop delivering frontends. Instead, process logic belongs in the contract.
Key Takeaways
- OZG frontends without register integration are not digitalisation-they’re just accelerated paper acceptance with a URL.
- FIM and XÖV carry the administration, not the browser. Providers who offload this layer onto the customer lose the tenders that matter.
- If you want to tackle municipal digitalisation as a market, you need backend expertise and integration willingness, not just a modern component library.
Related:Kubernetes governance in multi-cloud environments / Platform engineering is no longer just a DevEx project
Where the OZG promise falls short
The Online Access Act of 2017 set a clear goal: 575 administrative services were to be digitally usable by 2022. Reality looks different. Even under the follow-up law OZG 2.0, many services remain anything but end-to-end digital. Citizens fill out forms on screen, the PDF attachment lands in the agency’s printer, and a person then types the data into the specialist procedure.
From the provider’s perspective, the contract looks clean: frontend deployed, authentication connected, OZG compliance confirmed. What happens in the backend is the client’s problem. That’s exactly where the real issue starts. The interface to the specialist procedure is missing, identification runs via a user account, registers and specialist procedures are not consistently connected, and the notice is sent by post.
Current professional publications on administrative digitalisation reach the same conclusion from different angles: as long as online interfaces are built without rethought processes, the administration stays analogue. The browser merely conceals where the handoff to reality breaks down.
For cloud architects and platform engineers this is more than a bureaucratic debate. Anyone who has handled public tenders in the last three years knows the pattern: a general contractor wins the frontend bid while integration into the municipal specialist-procedure base is split across four more lots. Each lot has its own provider, its own timeline and its own take on data security. The result is not a seamless solution but a series of handoff points where responsibility evaporates.
What FIM and XÖV Really Deliver
To grasp municipal digitalization, two acronyms demand attention. The Federal Information Management (FIM) defines services, forms, and processes in machine-readable formats. XÖV provides the XML standards enabling authorities to exchange information. Both layers are prerequisites for an application to flow seamlessly from a website into a specialized procedure without media discontinuity.
In practice, FIM modules exist but are rarely integrated. Providers implement their own form logic because tenders evaluate frontends, not XÖV compliance. The outcome is an online service treating each new Online Access Act (OZG) service as a special case. Scaling across municipalities remains out of reach.
For cloud platforms, this translates into a clear requirement. XÖV messages aren’t an afterthought to be bolted on during integration. They belong in the data layer alongside other schemas. Architects who build tenant logic sourcing FIM master data and processing XÖV messages natively gain an architectural edge no UI library can replicate.
Three Scenarios, One Lesson
Cloud architects and integration providers who have guided OZG projects over the past two years recognize three recurring patterns. In the first, the provider delivers the frontend while the municipality is expected to procure the interface to the specialized procedure itself. The interface is rarely commissioned, leaving the online service symbolic.
In the second, the municipality builds a frontend linked to a specialized procedure whose manufacturer hasn’t documented it openly. Connectivity is purchased via costly bespoke integrations. Multiple municipalities solve the same problem in parallel instead of once, together.
In the third, FIM modules are available but the specialized procedure doesn’t understand them. Data is converted back to PDF in the backend and handed to caseworkers. The frontend looks modern, yet processing times remain unchanged. Here’s where providers either create value or fall short.
A single answer fits all three scenarios: connectivity as a standard product. Cloud providers offering connectors to dominant specialized procedure vendors as a product free municipalities from one-off procurement. Margins aren’t made in the frontend but in integration performance. Providers who take municipal specifics seriously capture this margin.
What Providers Must Present Today
A tender that providers can’t sidestep no longer describes just the online form but the entire process. Which FIM master data is loaded, which XÖV messages reach which register, which endpoint in the specialized procedure takes over, and how the decision is delivered digitally. Providers who factor this logic into their bids before the tender phase win contracts that actually go live.
In practice, this means checking API contracts to specialized procedures before component design begins. Mapping XÖV messages and FIM master data in the architecture-not just during integration. Building access layers municipalities can reuse without new procurement. Those who don’t will be outpaced in upcoming tenders by providers who do.
How manufacturers can take the market seriously
Municipal digitalization isn’t a consumer market for pretty components. It’s a federally distributed process and interface market. Manufacturers who want their cloud platforms to remain compatible need connectors to leading specialist procedures, documented XÖV mapping layers, and a clear answer to who bears responsibility for data migration all the way to citizens’ accounts.
Marketplaces with prequalification could reduce this effort on the provider side. If prequalification of FIM, XÖV, and data-protection requirements is handled once on a municipal procurement platform, providers no longer have to re-certify their components for every tender. That shifts the economics of the GovTech sector and makes sustainable growth finally predictable.
For cloud architects and platform teams, this means treating municipal requirements as anything but a niche. Data residency, auditability, FIM compliance, and secure citizen-account integration are architectural demands that long since extend beyond public administration. Those who build them properly today will tomorrow serve private-sector segments that operate under similar standards as well.
Frequently Asked Questions
What is the difference between OZG and OZG 2.0?
The original Online Access Act (OZG) of 2017 aimed to make 575 administrative services digitally available by 2022. The goal was missed. The OZG Amendment Act, commonly referred to as OZG 2.0, redefines the obligation with a stronger focus on end-to-end digital processes rather than mere frontend availability.
What exactly do FIM and XÖV stand for?
FIM stands for Föderales Informationsmanagement (Federal Information Management) and standardizes administrative services, data fields, and processes uniformly and in a machine-readable format. XÖV provides the XML standards for data exchange between authorities, for example between municipalities and registers. Both standards are prerequisites for seamless administrative services.
Why do OZG frontends often fail at the backend?
Because tenders often only evaluate the frontend. The integration with registers, specialized procedures, and notification delivery is then awarded in subsequent tenders or omitted entirely. Without these integrations, the online application remains a digitized paper process: input online, processing manually.
What role do marketplaces with prequalification play?
Marketplaces bundle pre-checked solutions that have demonstrated compliance with data protection, security, FIM, and XÖV standards. Municipalities can select from these without having to go through a full tender process each time. For providers, sales costs decrease; for municipalities, procurement time shortens. The leverage only works if the prequalification is truly thorough.
What should cloud providers do specifically?
Three steps. First: offer connectors to dominant specialized procedure vendors as standard products. Second: natively support XÖV messages and FIM master data in your own data architecture. Third: in your proposals, describe the end-to-end process, not just the frontend. Providers who do this will also win over smaller municipalities by removing integration risk.
Editorial Team’s Reading Tips
- Platform Engineering for Compliance: IDPs Enforce NIS2 and DORA
- Kubernetes Governance in Multi-Cloud Environments
- Platform Engineering Is No Longer Just a DevEx Project
DiGA and ePA Become IT Test Cases
German Municipalities: Strategy Without Infrastructure
Image source: AI-generated (May 2026)
