Behördensoftware 1995 Review: Rückblick mit Expertenblick

Wer glaubt, dass Digitalisierung in deutschen Behörden erst 2024 ein Problem ist, hat die “glorreichen” Neunziger nie erlebt: Willkommen im Jahr 1995, wo Software für Behörden noch so sexy war wie ein Faxgerät im Dauerbetrieb – und genauso langsam. Zeit für eine schonungslose, technische Retrospektive auf Behördensoftware 1995: veraltete Schnittstellen, Datenbank-Desaster und IT-Sicherheit auf dem Niveau eines offenen Aktenschranks – wir zerlegen die Dinosaurier der Verwaltungssoftware und zeigen, warum diese Altlasten das digitale Deutschland bis heute plagen.

• Was Behördensoftware 1995 ausmachte: Monolithen, Legacy-Systeme, Datenbank-Kuddelmuddel
• Technische Schwächen: Proprietäre Schnittstellen, fehlende Interoperabilität, Null-Skalierbarkeit
• Warum diese Systeme so langlebig (und toxisch) für die Digitalisierung waren
• Security? Ein Fremdwort – und ein Dauerproblem, das bis heute nachhallt
• Wie man 1995 Behörden digitalisierte: Schritt für Schritt ins IT-Abseits
• Die wichtigsten Softwareprodukte, ihre Architektur und ihre technischen Sackgassen
• Wie sich Behörden mit ihren Software-Risiken selbst sabotierten
• Lehren für 2024: Warum Legacy-IT heute immer noch das größte Digitalisierungsrisiko ist
• Praktische Checkliste: So erkennt man heute noch Altlasten aus 1995 im System
• Fazit: Ohne radikalen Schnitt bleibt die Verwaltung digital auf DOS-Niveau

Behördensoftware 1995 – das klingt nach einer Zeit, in der Informatikstudierende noch Disketten sortierten und “Cloud” maximal ein Wetterphänomen war. Aber für die Verwaltung war es der Stand der Technik, auf den man heute – mit viel Kopfschütteln – zurückblickt. Denn die Software, die damals in den Amtsstuben installiert wurde, war alles andere als disruptiv. Sie war: schwerfällig, schlecht dokumentiert, nie wirklich fertig und so modular wie ein Betonklotz. Wer glaubt, Digitalisierung sei eine Frage der Strategie, hat nie versucht, ein 1995er Fachverfahren mit einer modernen REST-API zu verbinden. In diesem Artikel machen wir einen Deep Dive in die technische DNA der Behördensoftware der Neunziger, zeigen, warum diese Systeme so langlebig – und so katastrophal für jede digitale Innovation – waren, und erklären, wieso der digitale Rückstand deutscher Behörden bis heute auf exakt diesen Grundsteinen ruht.

Monolithen und Legacy-Systeme: Die Architektur der Behördensoftware 1995

Wer den Begriff “Legacy-System” verstehen will, muss nur einen Blick auf Behördensoftware 1995 werfen. Hier regierten Monolithen: Anwendungen, deren Codebasis so undurchsichtig war wie das deutsche Steuerrecht. Alles begann mit proprietären Entwicklungstools, selbstgestrickten Datenbanksystemen und Frontends, die aussahen wie Excel auf Valium. Modularität? Fehlanzeige. Die Applikationen wurden als geschlossene Pakete entwickelt, oft von kleinen IT-Firmen, die ihre Spezifikationen eng an die Wünsche einzelner Behörden anpassten – mit der Folge, dass jedes Landratsamt sein eigenes, inkompatibles System hatte.

Technisch basierten viele dieser Lösungen auf Mainframes oder frühen Windows-NT-Servern. Als Datenbank kamen proprietäre Systeme wie Informix, dBASE oder – im schlimmsten Fall – selbst entwickelte Flatfile-Lösungen zum Einsatz. Die Programmiersprachen der Wahl? Cobol, Clipper, Visual Basic 3.0 oder, für die ganz Abenteuerlustigen, Delphi. Schnittstellen gab es zwar, allerdings meistens als undokumentierte Import/Export-Funktionen auf Dateiebene, die für Interoperabilität so hilfreich waren wie ein Faxgerät im WLAN.

Die Folge: Ein Flickenteppich aus Inkompatibilitäten, der jede spätere Digitalisierung zur Mammutaufgabe machte. Die Systeme waren nicht nur untereinander inkompatibel, sondern auch nicht für eine Skalierung oder Modernisierung ausgelegt. Wer 1995 eine Behörde digitalisierte, schuf damit vor allem eines: technische Schulden, die sich bis heute verzinsen.

Ein weiteres Kernproblem: Die Architektur war rein transaktionsorientiert. Prozesslogik, Datenhaltung und User-Interface waren eng verdrahtet. Das machte jede Erweiterung – etwa für neue Gesetzeslagen – zum Code-Albtraum. Refactoring? Das Wort war unbekannt. Die Systeme waren so robust wie ein Kartenhaus im Wind – und genauso wartungsfreundlich.

Proprietäre Schnittstellen, fehlende Standards: Warum Interoperabilität 1995 ein Fremdwort war

Das größte Problem der Behördensoftware 1995 war ihre proprietäre Natur. Schnittstellen wurden nicht nach offenen Standards wie heute (REST, SOAP, OData) implementiert, sondern als individuelle, kryptische Exportfunktionen. Häufig bestanden Schnittstellen aus CSV-Dateien, die auf Netzlaufwerke geschrieben wurden, oder – schlimmer noch – aus Binärformaten ohne öffentliche Dokumentation. Wer eine Kompatibilität zwischen zwei Fachverfahren herstellen wollte, brauchte Reverse Engineering-Skills und viel Geduld.

Von Interoperabilität, wie sie heute etwa mithilfe von OpenAPI oder Microservices-Architekturen selbstverständlich ist, konnte keine Rede sein. Vielmehr entstanden Insellösungen, bei denen jede Software ihr eigenes Datenformat pflegte. Die Folge: Datenmigrationen dauerten Monate, wenn nicht Jahre. Schnittstellenprojekte waren berüchtigt für explodierende Budgets und Projektabbrüche. Und jeder Versuch, mehrere Systeme zu integrieren, führte zu einer exponentiellen Zunahme von Fehlerquellen.

Die Nicht-Standardisierung hatte noch eine weitere, toxische Konsequenz: Die Anbieter banden ihre Kunden an sich, indem sie proprietäre Formate und Schnittstellen etablierten – das klassische Vendor-Lock-in. Ein Wechsel der Software war praktisch unmöglich, ohne sämtliche Altdaten zu verlieren oder ein halbes Vermögen für Konverter auszugeben. Für Behörden bedeutete das: jahrzehntelange Abhängigkeit von einem einzigen, oft überforderten Anbieter.

Und für Entwickler? Die Arbeit an Behördenprojekten war eine Mischung aus Archäologie und Detektivarbeit. Dokumentation war spärlich, Quellcode oft nicht verfügbar. Wer neue Schnittstellen schreiben wollte, musste sich durch kryptische Binärdaten kämpfen – und hoffen, dass der einzige Entwickler im Ruhestand nicht das letzte Wissen mitgenommen hatte.

Security und Datenschutz: Behördensoftware 1995 als digitaler Selbstbedienungsladen

IT-Sicherheit in der Behördensoftware 1995 war ungefähr so präsent wie HTTPSHTTPS: Das Rückgrat der sicheren Datenübertragung im Web HTTPS steht für „Hypertext Transfer Protocol Secure“ und ist der Standard für die verschlüsselte Übertragung von Daten zwischen Browser und Webserver. Anders als das unsichere HTTP bietet HTTPS einen kryptografisch abgesicherten Kommunikationskanal. Ohne HTTPS bist du im Internet nackt – und das nicht mal im positiven Sinne. In Zeiten von Cybercrime, Datenschutz-Grundverordnung... im Browser von Windows 3.11: praktisch nicht existent. Authentifizierung wurde meist über lokale User-Accounts gelöst, Passwörter als Klartext gespeichert, User-Management war ein nachträglich aufgesetztes Feature. Von Verschlüsselung oder rollenbasierten Zugriffskonzepten konnte man nur träumen. Firewalls? Wenn überhaupt, stand ein Novell NetWare-Server irgendwo im Keller, und das war’s dann auch mit “Perimeter Security”.

Die Systeme waren in der Regel nicht für den Zugang aus dem Internet vorgesehen, aber das bedeutete nicht, dass sie sicher waren. Infektionen mit Makroviren, Datendiebstahl durch einfache Kopien auf Diskette oder versehentlich freigegebene Netzlaufwerke: All das gehörte zum Alltag. Protokollierung? Wenn überhaupt, wurden Logfiles lokal abgelegt – und nach jedem Neustart überschrieben. Auditing-Möglichkeiten? Fehlanzeige.

DatenschutzDatenschutz: Die unterschätzte Macht über digitale Identitäten und Datenflüsse Datenschutz ist der Begriff, der im digitalen Zeitalter ständig beschworen, aber selten wirklich verstanden wird. Gemeint ist der Schutz personenbezogener Daten vor Missbrauch, Überwachung, Diebstahl und Manipulation – egal ob sie in der Cloud, auf Servern oder auf deinem Smartphone herumlungern. Datenschutz ist nicht bloß ein juristisches Feigenblatt für Unternehmen, sondern... war eine Randnotiz. Personendaten, Steuerdaten, Gesundheitsdaten – alles lag häufig unverschlüsselt auf Servern oder sogar lokal auf den Arbeitsstationen. Zugriffskontrollen basierten auf dem Prinzip “Wer den Raum betritt, darf alles”. Die Folgen: Datenpannen, die selten öffentlich wurden, aber intern regelmäßig für Kopfzerbrechen sorgten. Und das alles in einer Zeit, in der das Bundesdatenschutzgesetz noch als lästige Pflichtübung galt.

Das Schlimme: Viele dieser Sicherheitsprobleme wurden nie wirklich gelöst, sondern einfach mitgeschleppt. Noch heute finden sich 1995er Systeme in Behördennetzwerken – mit denselben Schwachstellen wie damals. Und jede neue Schnittstelle, jede Migration macht die Angriffsfläche größer. Von “Security by Design” war man 1995 so weit entfernt wie vom papierlosen Büro.

Digitalisierung 1995: Wie Behörden sich mit Software selbst blockierten

Wie digitalisierte man 1995 eine Behörde? Mit viel Papier, einer Extraportion Bürokratie und Software, die Prozesse eher verlangsamte als beschleunigte. Der Ablauf war immer derselbe:

• Bedarfsanalyse: Ein Gremium aus Verwaltungsleitern wünscht sich “digitale Akten”.
• Lastenheft: Ein Pflichtenheft mit mehr Ausnahmen als Regeln wird erstellt.
• Vergabe: Der billigste Anbieter bekommt den Zuschlag – unabhängig von technischer Kompetenz.
• Implementierung: Entwickler bauen eine Anwendung nach dem Prinzip “Minimalanforderung”.
• Rollout: Nach fünf Jahren wird die Software ausgerollt, aber niemand hat die Nutzer geschult.
• Wartung: Fehler werden sporadisch gefixt, neue Features kosten ein Vermögen.

Das Ergebnis: Prozesse, die vorher auf Papier funktionierten, wurden digital abgebildet – aber ohne Optimierung. Die Software war so starr wie die Papierformulare. Änderungen am Prozess bedeuteten immer auch Änderungen am Quellcode – was in der Praxis nie passierte. Die Folge: Workarounds, Schatten-IT und am Ende wieder Papierausdrucke.

Die technische Sackgasse wurde durch die fehlende Weiterentwicklung der Systeme zementiert. Jedes Update war ein Risiko, jedes Feature ein potenzieller Totalschaden. Die Verantwortlichen hatten längst resigniert und begnügten sich mit dem, was “irgendwie läuft”. Innovation? Fehlanzeige. Digitalisierung 1995 bedeutete vor allem: Prozesse einfrieren und auf bessere Zeiten hoffen.

Für die IT-Branche war das ein gefundenes Fressen: Wartungsverträge, teure Individualentwicklungen, Support-Hotlines – das alles spülte Geld in die Kassen der Anbieter, aber brachte der Verwaltung keine echte digitale Transformation.

Die wichtigsten Produkte, ihre technische DNA – und der ewige Vendor-Lock-in

Einige der berüchtigtsten Behördensoftware-Produkte von 1995 verdienen einen eigenen Platz im digitalen Museum. Da wäre etwa das legendäre KONSENS-Verfahren für Steuerdaten, entwickelt als Gemeinschaftswerk von Ländern und Bund – ein Paradebeispiel für föderalen Software-Wildwuchs. Oder das Fachverfahren “Meldewesen” auf Basis von FoxPro, das bis heute in manchen Kommunen als Zombie-System läuft.

Technisch zeichneten sich all diese Produkte durch dieselben Schwächen aus:

• Monolithische Architektur: Kaum trennbare Module, alles in einer EXE oder DLL gebündelt.
• Proprietäre Datenhaltung: Datenbanken ohne Migrationspfad, selbstgestrickte Indizes, häufige Datenbankfehler.
• Unklare API-Strukturen: Schnittstellen als Export/Import-Funktionen, nie dokumentiert, nie standardisiert.
• Plattform-Abhängigkeit: Läuft nur auf Windows NT 3.51 oder OS/2, Upgrades unmöglich ohne Totalausfall.
• Vendor-Lock-in: Daten und Schnittstellen als Geschäftsmodell, Wechsel praktisch ausgeschlossen.

Die Hersteller wussten um ihre Macht. Wer ein Verfahren einmal eingeführt hatte, blieb jahrzehntelang Kunde. Support wurde teuer, Weiterentwicklung träge. Behörden, die auf Open Source oder Standardsoftware setzen wollten, scheiterten meist an der Inkompatibilität zu den Altverfahren. So entstand eine digitale Parallelwelt, abgeschottet vom technologischen Fortschritt.

Viele dieser Produkte sind heute noch – als “Altsysteme” – im Einsatz. Jede Modernisierung droht am Datenformat oder der fehlenden APIAPI – Schnittstellen, Macht und Missverständnisse im Web API steht für „Application Programming Interface“, zu Deutsch: Programmierschnittstelle. Eine API ist das unsichtbare Rückgrat moderner Softwareentwicklung und Online-Marketing-Technologien. Sie ermöglicht es verschiedenen Programmen, Systemen oder Diensten, miteinander zu kommunizieren – und zwar kontrolliert, standardisiert und (im Idealfall) sicher. APIs sind das, was das Web zusammenhält, auch wenn kein Nutzer je eine... zu scheitern. Die Folge: Migrationen werden aufgeschoben, bis die Systeme kollabieren.

Legacy-IT als Innovationsbremse: Warum 1995 noch immer die Verwaltung lähmt

Die Altlasten aus 1995 sind kein Museumsstück, sondern ein reales Problem. Noch heute laufen in deutschen Behörden tausende Anwendungen, die auf den Architekturen, Datenbanken und Schnittstellen der Neunziger basieren. Ihre technische DNA ist toxisch für jede Digitalstrategie: Sie verhindern die Einführung moderner Cloud-Lösungen, blockieren Datenaustausch und machen jede Schnittstellenprogrammierung zum Himmelfahrtskommando.

Die Gründe sind simpel: Niemand traut sich, die Systeme abzuschalten. Die Risiken von Datenverlust, der Aufwand für Migrationen und die Angst vor Ausfallzeiten sind zu groß. Gleichzeitig fehlt das Know-how, um die Legacy-Systeme überhaupt noch zu pflegen – die Entwickler sind längst in Rente oder haben das Handwerk nie dokumentiert. Das Ergebnis: Behörden bleiben auf digitalen Inseln sitzen, während der Rest der Welt längst auf Microservices, Container und REST-APIs setzt.

Security bleibt so ein Dauerproblem. Die alten Systeme werden notdürftig hinter Firewalls versteckt, aber jede neue Schnittstelle, jeder offene Port ist ein potenzielles Einfallstor für Angreifer. Compliance-Anforderungen wie DSGVO sind mit solchen Systemen praktisch nicht erfüllbar.

Und das Schlimmste: Jeder Euro, der in die Wartung der Altlasten fließt, fehlt für echte Innovation. So wird die Verwaltung zum digitalen Fossil – und die Modernisierung zu einer Operation am offenen Herzen.

Legacy-Detox: So entlarvt man Altlasten aus 1995 im heutigen Behörden-IT-System

Wer wissen will, ob die eigene Behörde noch digitale Altlasten aus 1995 schleppt, braucht mehr als ein gutes Bauchgefühl. Hier die wichtigsten technischen Indikatoren, die auf ein Legacy-System hindeuten:

• Die Anwendung läuft nur auf Windows NT, OS/2 oder mit DOS-Emulatoren.
• Die Datenbank ist dBASE, FoxPro, Access 2.0 oder ein proprietäres Binärformat.
• Schnittstellen sind reine Export/Import-Funktionen auf Dateiebene – kein REST, kein SOAP.
• Updates dauern Monate und kosten fünfstellige Beträge.
• Dokumentation ist veraltet oder existiert nur als gedrucktes Handbuch.
• Niemand im Haus weiß, wie das System wirklich funktioniert.
• Der Hersteller bietet keinen Support mehr – oder existiert nicht mehr.
• Zugriffsrechte werden über lokale User-Accounts oder Gruppen gesteuert, keine zentrale Authentifizierung.
• Die Anwendung ist im Internet nicht erreichbar – aber im Intranet offen wie ein Scheunentor.

Wer hier mehr als zwei Häkchen setzt, weiß: Willkommen in der IT-Zeitkapsel. Und höchste Zeit für einen radikalen Schnitt. Denn jedes Jahr, das ein solches System weiterläuft, erhöht nicht nur die technischen Schulden, sondern auch das Risiko eines Totalausfalls.

Fazit: Behördensoftware 1995 – Die digitale Hypothek der Verwaltung

Behördensoftware 1995 war nie für die Zukunft gebaut. Sie war ein technischer Kompromiss aus den Möglichkeiten der Zeit, politischen Zwängen und dem Wunsch nach Kontrolle. Was damals als Fortschritt galt, ist heute das größte Risiko für jede Digitalstrategie. Die Monolithen, proprietären Schnittstellen und sicherheitstechnischen Sünden der Neunziger prägen die Verwaltung bis heute – als digitale Hypothek, die Innovation systematisch verhindert.

Wer wirklich digitalisieren will, muss die Altlasten aus 1995 radikal entsorgen. Das heißt: Legacy-Systeme identifizieren, Daten migrieren, Schnittstellen auf Standards heben und Security von Anfang an mitdenken. Solange die Verwaltung an den Dinosauriern der IT festhält, bleibt sie digital auf DOS-Niveau. Die Lehre aus 1995? Technikschulden sind wie Steuern: Wer sie nicht tilgt, zahlt doppelt – und bleibt für immer im digitalen Niemandsland.