Softwareentwicklung und Plattformen im öffentlichen Sektor

Warum das für den öffentlichen Wert zählt

Fast jeder öffentliche Dienst, den eine Bürgerin heute berührt – eine Geburt registrieren, eine Leistung beantragen, eine Steuerrechnung zahlen, einen Gerichtstermin buchen – läuft irgendwo hinter dem Schalter oder Bildschirm auf Software. Diese Software ist selten ein einmaliger Kauf; sie wird Teil der permanenten Infrastruktur des Staates, oft die Verwaltung überlebend, die sie beauftragte, die Anbieterin, die sie baute, und die Programmiersprache, in der ihre Ingenieurinnen ausgebildet wurden. Eine öffentliche Stelle erlebt Software nicht so, wie sie ein Gebäude oder eine Straße erlebt, wo der Zustand des Vermögenswerts sichtbar ist; Software verfällt unsichtbar, und die Rechnung für diesen Verfall trifft Jahre später als Notfall ein.

Die diesem Thema zugrunde liegende Spannung ist strukturell. Software ist inhärent iterativ – Anforderungen werden klarer, während Nutzende mit einem funktionierenden System interagieren, und die beste Engineering-Praxis ist, etwas Kleines zu bauen, zu lernen, und anzupassen. Öffentliche Beschaffungs- und Rechenschaftszyklen (siehe Thema 3.7 — Öffentliche Beschaffung und Leistungsvergabe) wurden dagegen für Kapitalprojekte und Verteidigungsverträge gebaut: eine feste Spezifikation, eine einzelne große Vergabe, Meilensteinzahlungen, und ein Jahre vor Erbringungsbeginn abgezeichneter Business Case. Wenn eine Legislative oder eine Prüferin einen Festpreis-, Festumfangsvertrag erwartet und ein Engineering-Team nach der ersten Veröffentlichung den Kurs ändern muss, zeigt sich die Fehlpassung als Umfangsausweitung, Budgetüberschreitung, oder ein 2019 korrekt spezifiziertes und zum Zeitpunkt der Auslieferung veraltetes System.

Die Plattformen, für deren Bau die Engineering-Praxis dieses Themas existiert – geteilte Identitätssysteme, Zahlungsschienen, ressortübergreifend wiederverwendete Fallmanagementwerkzeuge – sind das Thema von Thema 5.1 (siehe Thema 5.1 — Digitale Verwaltung und digitale Transformation); dieses Thema handelt von der Disziplin, die Software zu bauen und zu kaufen, die eine solche Plattform, oder jeden einzelnen Dienst, zuverlässig, ersetzbar, und im Besitz der öffentlichen Stelle macht, die von ihr abhängt, statt im Besitz wer auch immer sie zuerst schrieb.

Kernkonzepte

Die Bauen-versus-Kaufen-Entscheidung ist die Wahl zwischen der Beauftragung maßgeschneiderter Software, geschrieben für den Bedarf einer Organisation, und der Übernahme konfigurierbarer Handelssoftware, bereits für einen Markt ähnlicher Käuferinnen gebaut. Kaufen ist üblicherweise billiger und risikoärmer für einen Bedarf, der nicht genuin unverwechselbar ist – Gehaltsabrechnung, E-Mail, Standard-Fallmanagement –, während Bauen nur gerechtfertigt ist, wo die Anforderung anders genug ist, dass kein konfigurierbares Produkt passt, oder wo die Fähigkeit selbst ein strategischer Vermögenswert ist, den die Organisation besitzen und weiterentwickeln muss.

Technische Schulden sind eine 1992 vom Softwareingenieur Ward Cunningham geprägte Metapher für die angehäuften Kosten der Wahl eines schnelleren Wegs, Software jetzt auszuliefern, gegenüber einem gründlicheren Weg, der länger gedauert hätte. Technische Schulden sind, wie finanzielle Schulden, nicht inhärent falsch einzugehen – Cunninghams eigener Punkt war, dass funktionierenden Code schnell auszuliefern und danach zu refaktorieren die richtige Entscheidung sein kann –, aber nie zurückgezahlte Schulden häufen Zinsen als langsamere Erbringung, mehr Fehler, und steigendes Risiko an, und eine öffentliche Stelle, die ihre Schulden nicht sehen kann, kann nicht entscheiden, ob sie bedient oder sich verstärken lässt.

Ein Altsystem ist eine alte Technologie, Anwendung, oder Plattform, die trotz Veraltung in aktiver Nutzung bleibt, oft weil ein Ersatz teuer ist oder weil niemand mehr in der Organisation vollständig versteht, was es tut. Legacy systems sind besonders hartnäckig in der Regierung: Kern-Steuer-, Leistungs-, und Sozialversicherungssysteme, Jahrzehnte zuvor in Sprachen wie COBOL geschrieben – die Common Business-Oriented Language, 1960 für administrative Datenverarbeitung entworfen – verarbeiten noch immer Transaktionen für Millionen Bürgerinnen und Bürger, weil die Systeme funktionieren und das institutionelle Wissen, das nötig ist, sie sicher zu pensionieren, sich oft selbst zuerst pensioniert hat.

Softwaremodernisierung ist der allgemeine Begriff für die Umwandlung, Neuschreibung, oder Migration eines Altsystems zu einer aktuellen Architektur, Sprache, oder Plattform. Software modernization umspannt ein Spektrum von einer vollständigen Neuschreibung bis zu konservativeren Optionen wie dem Neuhosten desselben Codes auf moderner Infrastruktur, und die Wahl zwischen ihnen ist ebenso sehr eine Risikomanagementsentscheidung wie eine technische.

Das Strangler-Fig-Muster ist ein inkrementeller Modernisierungsansatz, benannt nach einer Ranke, die um einen Wirtsbaum wächst und ihn allmählich ersetzt, in dem neue Funktionalität neben einem Altsystem gebaut wird und Verkehr Stück für Stück auf sie umgeleitet wird, statt das gesamte System in einer Umschaltung zu ersetzen. Das Strangler-Fig-Muster zählt, weil es erlaubt, dass jedes Inkrement getestet, zurückgerollt, oder pausiert wird, ohne den gesamten Dienst herunterzufahren – das Gegenteil einer Big-Bang-Ersetzung, bei der das alte System abgeschaltet und das neue in einem einzelnen Moment eingeschaltet wird, ohne Weg zurück, falls etwas falsch ist.

Anbieterabhängigkeit tritt auf, wenn eine Kundin so von der proprietären Technologie, den Datenformaten, oder Vertragsbedingungen einer Anbieterin abhängig wird, dass ein Wechsel zu einer anderen Anbieterin unerschwingliche Kosten oder Risiko trägt. Vendor lock-in ist eine besondere Gefahr in öffentlicher-Sektor-Software, weil die Käuferin eine wiederkehrende Kundin mit begrenzter praktischer Fähigkeit ist, von einem einen kritischen Dienst betreibenden System wegzugehen, was ihre Verhandlungsposition bei jeder folgenden Erneuerung schwächt.

Freie und Open-Source-Software ist Software, verteilt unter einer Lizenz, die Nutzenden die Freiheit gewährt, den Quellcode zu nutzen, zu studieren, zu modifizieren, und weiterzuverteilen. Free and open-source software untermauert eine Open-Source-als-Standard-Politik, unter der eine öffentliche Stelle standardmäßig den von ihr beauftragten Quellcode veröffentlicht, sofern nicht ein spezifischer Grund – Sicherheitssensibilität, Rechte Dritter – die Zurückhaltung rechtfertigt; die Begründung wird üblicherweise als „öffentliches Geld, öffentlicher Code" zusammengefasst: Software, einmal mit öffentlichen Mitteln bezahlt, sollte nicht erneut bezahlt werden müssen, in einem anderen Rechtsraum, von einer anderen öffentlichen Stelle, die dasselbe Problem löst.

Ein digitales öffentliches Gut ist offene Software, Daten, oder Inhalt, unter einer offenen Lizenz veröffentlicht, gestaltet, um einem öffentlichen Entwicklungs- oder Governance-Ziel zu dienen, statt eine kommerzielle Rendite zu erzeugen. Digital public goods rahmen die Open-Source-Veröffentlichung einer Regierung als Teil breiterer, geteilter Infrastruktur um, auf die andere Regierungen und Zivilgesellschaftsorganisationen direkt zurückgreifen können, nicht nur eine interne Transparenzgeste.

Agile Softwareentwicklung ist ein Oberbegriff für iterative Ansätze des Softwarebaus, die funktionierende Software, häufige Erbringung, und Reaktion auf Änderung gegenüber dem Befolgen eines fest im Voraus vereinbarten Plans bevorzugen. Agile software development steht im Gegensatz zum Wasserfallmodell, einem sequenziellen Ansatz, in dem Anforderungen, Design, Bau, und Testen jeweils vollständig abgeschlossen werden, bevor der nächste beginnt; der Reiz des Wasserfalls für öffentliche Stellen war immer, dass sich seine Meilensteine sauber auf einen Festpreisvertrag und einen jährlichen Haushaltszyklus abbilden, weshalb so viel Beschaffungsrecht ihn noch immer annimmt, selbst wo Erbringung genuin agil ist.

Ein minimal tragfähiges Produkt ist die kleinste Version eines Dienstes, die an echte Nutzende veröffentlicht werden kann, um zu testen, ob es funktioniert, und zu lernen, was als Nächstes zu bauen ist. Das Konzept des minimum viable product, in Spielbücher für digitale Dienste des öffentlichen Sektors adaptiert, gibt einem iterativen Team eine vertretbare Weise, einer Fördergeberin oder Prüferin etwas Echtes und Funktionierendes zu zeigen, lange bevor der vollständige Umfang abgeschlossen ist – vorausgesetzt, der Rechenschaftsprozess akzeptiert eine genuin minimale Veröffentlichung, statt sie als fertiges Produkt unter anderem Namen zu behandeln.

Bewährte Praktiken

1. Kaufen Sie standardmäßig für undifferenzierte Bedürfnisse, und reservieren Sie Bauen für genuin Unverwechselbares. Gehaltsabrechnungs-, E-Mail-, und allgemeine Fallmanagementbedürfnisse unterscheiden sich selten genug von denen jeder anderen Organisation, um maßgeschneiderte Software zu rechtfertigen; bauen Sie nur, wo die Anforderung, der Maßstab, oder der Bedarf, die Fähigkeit über Jahrzehnte zu besitzen und weiterzuentwickeln, sich genuin von dem unterscheiden, was der Markt bietet.
2. Machen Sie technische Schulden sichtbar, bevor Sie entscheiden, wie viel davon zu tragen ist. Pflegen Sie ein Register bekannter Abkürzungen, aufgeschobener Korrekturen, und nicht unterstützter Abhängigkeiten für jedes im Dienst befindliche System, auf festem Zyklus überprüft, sodass das Tragen von Schulden für ein weiteres Jahr ein bewusster Kompromiss ist, statt dass niemand hinsieht.
3. Planen Sie nie eine einzelne, irreversible Umschaltung als einzigen Weg von einem kritischen Altsystem weg. Bevorzugen Sie inkrementelle Ansätze wie das Strangler-Fig-Muster, die erlauben, dass jedes Stück getestet, umgekehrt, und schrittweise ausgerollt wird; eine Big-Bang-Ersetzung eines Systems, von dem Millionen abhängen, konzentriert Jahre an Risiko in ein einzelnes Wochenende, ohne Weg zurück, falls etwas versagt.
4. Behandeln Sie den von Ihrer Organisation zu schreiben bezahlten Quellcode als Vermögenswert, den sie besitzt, nicht als Dienst, den sie mietet. Verhandeln Sie Quellcode-Hinterlegung oder vollständigen Besitz zum Zeitpunkt der Vertragsschließung, nicht nachdem ein Streit begonnen hat, da eine Anbieterin, die die einzige Kopie des Codes Ihres kritischen Dienstes hält, Anbieterabhängigkeit per Design ist.
5. Veröffentlichen Sie Quellcode standardmäßig offen, und verlangen Sie eine spezifische Rechtfertigung, ihn zurückzuhalten. Eine konsistent angewandte Open-Source-als-Standard-Politik verwandelt die maßgeschneiderte Software jedes Ressorts in einen geteilten regierungsübergreifenden Vermögenswert statt einmaliger Kosten, und erlaubt externen Expertinnen, Sicherheitslücken zu finden, die ein internes Team allein verpassen würde.
6. Schreiben Sie Softwareverträge, die iterative Erbringung rechtlich, nicht nur technisch möglich machen. Ein Vertrag, der nur gegen eine bei Unterzeichnung vereinbarte feste Spezifikation zahlt, zwingt ein Team, zwischen ehrlicher agiler Praxis und Vertragskonformität zu wählen; nutzen Sie stattdessen gestaffelte Finanzierungstore, gebunden an demonstrierte funktionierende Software, statt eines Meilensteins am Ende.
7. Finanzieren Sie Modernisierung als laufendes Programm, nicht als einmaliges Kapitalprojekt. Ein einmal modernisiertes und dann für weitere zwanzig Jahre belassenes Altsystem häuft dasselbe Risiko an, mit dem es begann; budgetieren Sie für kontinuierliche, inkrementelle Erneuerung, wie eine Straßenbehörde für Neubelag budgetiert, nicht eine grandiose Ersetzung einmal pro Generation.
8. Wählen Sie offene Standards und portable Datenformate, selbst beim Kauf kommerzieller Software. Von einem System einer Anbieterin zu verlangen, Daten in offenen, dokumentierten Formaten zu speichern und zu exportieren, hält Wechselkosten niedrig, selbst wo die Software selbst proprietär ist, und ist oft eine erreichbarere kurzfristige Schutzmaßnahme gegen Abhängigkeit als darauf zu bestehen, dass jedes System Open Source ist.
9. Bauen Sie ein minimal tragfähiges Produkt und zeigen Sie es echten Nutzenden, bevor Sie sich zum vollen Umfang verpflichten. Eine genuin minimale Version zu veröffentlichen, dann zu iterieren, was gelernt wird, fängt falsche Annahmen, während sie noch billig zu beheben sind, statt nachdem ein Vollsystem gegen sie gebaut wurde.
10. Halten Sie interne Engineering-Fähigkeit ausreichend, um eine intelligente Käuferin zu sein, selbst wo Erbringung ausgelagert wird. Eine öffentliche Stelle, die ihre technische Expertise ausgehöhlt hat, kann den Vorschlag einer Anbieterin nicht bewerten, frühe Warnzeichen eines problembehafteten Projekts nicht erkennen, oder sich nicht aus Abhängigkeit herausverhandeln, was auch immer ihre Beschaffungsregeln auf dem Papier sagen.
11. Pensionieren Sie das Risikoprofil eines Altsystems vor seiner Nutzeroberfläche. Priorisieren Sie den Ersatz nicht unterstützter Sprachen, ungepatchter Infrastruktur, und undokumentierter Integrationen – die Versagen, die Ausfälle und Verletzungen verursachen – vor visueller Modernisierung, die weit weniger operatives Risiko trägt.
12. Messen Sie Erbringungsgesundheit mit Engineering-Indikatoren, nicht nur Budget- und Zeitplanabweichung. Bereitstellungsfrequenz, Fehlerraten, und das Alter des ältesten unadressierten technische-Schulden-Postens sagen einem Governance-Gremium mehr darüber, ob ein Programm gelingen wird, als ob es derzeit im Budget liegt, oft der letzte Indikator, der sich bewegt.

Fragen zur Diskussion mit Ihrem Team

Wissen wir tatsächlich, wie viele technische Schulden wir tragen, System für System? Die meisten öffentlichen Stellen können ihr Kapitalbudget für das Jahr angeben, können aber nicht mit Zuversicht angeben, wie viel ihres Softwarebestands auf nicht unterstützten Komponenten, undokumentierter Logik, oder Code läuft, den niemand im verbleibenden Personal vollständig versteht. Nutzen Sie diese Frage, um jede Systemverantwortliche im Raum zu bitten, ehrlich zu schätzen, wie zuversichtlich sie ist, dass ihr Team ihr kritischstes System sicher ändern könnte, ohne etwas zu brechen, das niemand antizipierte. Diskutieren Sie, was es bräuchte, diese Schätzungen in ein tatsächliches Register zu verwandeln, auf festem Zyklus überprüft, statt Stammeswissen, das mit einer Schlüsselingenieurin geht. Erwägen Sie auch, wer derzeit entscheidet, wie viel Schuld akzeptabel zu tragen ist, und ob diese Entscheidung bewusst oder standardmäßig getroffen wird.

Wenn unser kritischstes Altsystem heute ersetzt werden müsste, würden wir eine Big-Bang-Umschaltung oder eine inkrementelle Migration planen – und warum? Der Instinkt, ein altes System auf einmal zu ersetzen, wird oft eher von Haushaltszyklen und Programmmanagementbequemlichkeit getrieben als von technischer Notwendigkeit, und er konzentriert enormes Risiko in einen einzelnen Moment. Nutzen Sie diese Frage, um konkret durchzugehen, wie eine Strangler-Fig-artige inkrementelle Migration Ihres kritischsten Altsystems Stück für Stück tatsächlich aussehen würde. Diskutieren Sie, was Sie heute davon abhält, diesen Weg zu wählen – Finanzierung, um ein einzelnes Go-Live-Datum strukturiert, ein Governance-Prozess, der einen sauberen Meilenstein will, oder eine echte technische Beschränkung, die inkrementelle Migration für dieses System unmöglich macht.

Wer besitzt tatsächlich den Quellcode für die Software, die Ihre Organisation bezahlt hat bauen zu lassen, und könnten wir es beweisen? Viele öffentliche Stellen entdecken erst, wenn eine Beziehung mit einer Anbieterin sauer wird, dass der Vertrag nie klaren Besitz oder Hinterlegung des Codes sicherte, von dem ihre kritischen Dienste abhängen. Nutzen Sie diese Frage, um die Verträge für Ihre drei wichtigsten maßgeschneiderten Systeme heranzuziehen und spezifisch zu prüfen, was jeder über Code-Besitz, Hinterlegung, und das Recht sagt, den Code zu einer anderen Anbieterin mitzunehmen. Diskutieren Sie, was morgen geschähe, wenn Ihre primäre Anbieterin für eines dieser drei Systeme aus dem Geschäft ginge oder sich weigerte, die Beziehung fortzusetzen.

Wo greifen wir aus Gewohnheit standardmäßig auf geschlossene, proprietäre Software zurück, wenn ein Open-Source-als-Standard-Ansatz uns ebenso gut oder besser dienen würde? Open-Source-als-Standard-Politiken existieren genau, weil die meisten öffentlichen Stellen überlappende Probleme unabhängig lösen, jede die vollen Kosten einer Software zahlend, die eine andere öffentliche Stelle bereits gebaut hat und hätte teilen können. Nutzen Sie diese Frage, um ein derzeit gebautes oder spezifiziertes System zu identifizieren und zu fragen, ob ein Äquivalent bereits als Open-Source-Software andernorts in der Regierung existiert, oder ob das, was Sie bauen, nützlich für andere zur Wiederverwendung veröffentlicht werden könnte. Diskutieren Sie, welche spezifische Barriere – Sicherheitsbedenken, Beschaffungsgewohnheit, Fehlen einer klaren Politik – diese Wiederverwendung tatsächlich verhindert, statt anzunehmen, sie sei hier nicht relevant.

Erlaubt unser Beschaffungs- und Rechenschaftsprozess tatsächlich ehrliche agile Erbringung, oder benennt er nur Wasserfall-Meilensteine als Sprints um? Es ist üblich, dass ein Team nominell agile Zeremonien durchführt, während es immer noch gegen eine bei Vertragsunterzeichnung vereinbarte feste Spezifikation finanziert, regiert, und berichtet wird, was jedes Wasserfall-Versagensmuster unter einem agilen Etikett neu erschafft. Nutzen Sie diese Frage, um ein laufendes digitales Programm von seinem Business Case bis zu seiner aktuellen Governance-Berichterstattung zu verfolgen und zu fragen, ob die Finanzierungsstruktur tolerieren würde, dass das Programm basierend darauf, was eine echte frühe Veröffentlichung lehrte, die Richtung ändert. Diskutieren Sie, was sich daran ändern müsste, wie das Programm finanziert und berichtet wird, damit iterative Erbringung echt statt kosmetisch ist (siehe Thema 3.7 — Öffentliche Beschaffung und Leistungsvergabe).

Haben wir genug interne Engineering-Fähigkeit, um eine intelligente Käuferin der Systeme zu sein, von denen wir am meisten abhängen? Eine Organisation, die ihr gesamtes technisches Urteil ausgelagert hat, nicht nur ihre Erbringungskapazität, kann nicht sagen, ob der Vorschlag einer Anbieterin solide ist, ob ein Projekt still in Schwierigkeiten steuert, oder was ein fairer Preis für die Arbeit tatsächlich ist. Nutzen Sie diese Frage, um zu fragen, wie viele Menschen in Ihrer Organisation glaubwürdig einen technischen Architekturvorschlag für Ihr wichtigstes System überprüfen könnten, und wie sich diese Zahl über die letzten fünf Jahre verändert hat. Diskutieren Sie, was es bräuchte, diese Fähigkeit wiederaufzubauen, wo sie erodiert ist, und was Ihre Organisation, ebenso sehr in Verhandlungsposition wie in Erbringungsrisiko, für jedes Jahr ohne sie verliert.

In der Praxis: ein Beispiel für öffentlichen Wert

Eine fiktive Regionalregierung – nur illustrativ, keine Beschreibung eines realen Rechtsraums – betrieb ihre Arbeitslosengeldanträge durch ein System, erstmals vor mehr als dreißig Jahren geschrieben, gewartet von einer schrumpfenden Zahl von Ingenieurinnen, die seine ursprüngliche Programmiersprache verstanden. Antragsvolumen war weit über das hinausgewachsen, was die Gestalterinnen des Systems antizipiert hatten, nächtliche Verarbeitungsläufe scheiterten zunehmend, vor Beginn der morgendlichen Transaktionen abzuschließen, und die Technologieführung der Behörde warnte, dass ein ungeplanter Ausfall mit Auswirkung auf Leistungszahlungen nun eine Frage des Wann, nicht des Ob war.

Der erste Instinkt der Behörde war eine konventionelle Reaktion auf ein dringend wirkendes Problem: einen einzelnen großen Vertrag beauftragen, das gesamte System durch eine moderne Plattform zu ersetzen, vollständig im Voraus spezifiziert, geliefert gegen einen festen Zweijahreszeitplan mit einem Umschaltwochenende am Ende. Eine vom Prüfausschuss der Behörde beauftragte Vor-Implementierungs-Überprüfung warf vor Vertragsunterzeichnung eine harte Frage auf: was mit Leistungszahlungen für mehrere hunderttausend Antragstellende geschähe, wenn das neue System in seiner ersten Woche vollmaßstäblichen, laufenden Betriebs einen unentdeckten Fehler hätte, mit dem bereits außer Betrieb genommenen alten System und keinem Weg zurück.

Die Behörde änderte Kurs. Sie hielt das Altsystem als Systemaufzeichnung laufend und begann, neue Antragsannahme- und Zulassungsbewertungsfunktionalität daneben zu bauen, unter Nutzung eines Strangler-Fig-Ansatzes: jedes neue Modul wurde zuerst an einen kleinen Prozentsatz neuer Anträge veröffentlicht, gegen die parallele Ausgabe des alten Systems verifiziert, und erst erweitert, sobald seine Ergebnisse übereinstimmten. Innerhalb von achtzehn Monaten liefen die meisten neuen Anträge durch moderne Komponenten, während das ursprüngliche System eine schrumpfende Restfallzahl handhabte, mit der Fähigkeit, jeden einzelnen Fall zurück auf den alten Pfad zu leiten, falls etwas falsch aussah. Die Behörde verlangte auch, in jedem für diese Arbeit ausgegebenen neuen Vertrag, dass der Quellcode im Besitz der Behörde sei und als Open Source veröffentlicht werde, sobald die Sicherheitsüberprüfung abgeschlossen sei, sodass andere regionale Regierungen, die demselben alternden-Großrechner-Problem gegenüberstanden, die Komponenten anpassen konnten, statt denselben Bau von Grund auf zu wiederholen.

Die vollständige Ersetzung der letzten Restfunktionen des Altsystems dauerte fast vier Jahre – länger, auf dem Papier, als der ursprüngliche Zweijahres-Big-Bang-Plan versprach. Aber keine Antragstellerin erlebte je einen ungeplanten Ausfall während des Übergangs, jedes Inkrement war klein genug, um innerhalb von Stunden zurückgerollt zu werden, wenn ein Fehler gefunden wurde, und zwei benachbarte Regionalregierungen begannen innerhalb des ersten Jahres seiner Veröffentlichung, den veröffentlichten Zulassungsbewertungscode der Behörde für ihre eigenen Systeme anzupassen.

Vier Sektorperspektiven

Kommunalverwaltung

Kommunalverwaltungen betreiben typischerweise eine große Zahl kleinerer, unverbundener Systeme statt einer Handvoll national-maßstäblicher Plattformen, was bedeutet, dass sich technische Schulden über viele getrennt beschaffte, getrennt gewartete Anwendungen ansammeln statt in einem sichtbaren Vorzeigesystem. Kommunalverwaltungen haben üblicherweise die geringste interne Engineering-Fähigkeit jeder Regierungsebene, was den Fall für den Kauf konfigurierbarer Handelssoftware gegenüber maßgeschneiderten Bauten besonders stark macht, und geteilte regionale oder nationale Plattformen – das Thema von Thema 5.1 (siehe Thema 5.1 — Digitale Verwaltung und digitale Transformation) – zu einem besonders wertvollen Weg macht, um zu vermeiden, dass jede Behörde dieselbe Fähigkeit getrennt neu baut.

Nationale Regierung

Die nationale Regierung ist, wo die ältesten und folgenreichsten Altsysteme tendenziell sitzen – Kern-Steuer-, Sozialversicherungs-, und Leistungsverwaltung –, weil dies oft zu den ersten großmaßstäblichen Computerisierungsanstrengungen der Regierung gehörten und jetzt die höchsten Einsätze für jedes Modernisierungsversagen tragen. Die nationale Regierung hat üblicherweise die spezialisierte kommerzielle und Engineering-Fähigkeit, ein genuin inkrementelles Modernisierungsprogramm durchzuführen und echten Code-Besitz in ihre Verträge zu verhandeln, und sie ist üblicherweise die Regierungsebene, am besten positioniert, eine Open-Source-als-Standard-Politik mit genug Maßstab dahinter zu setzen, um regierungsübergreifende Wiederverwendung tatsächlich geschehen zu lassen.

Sozialer Sektor und gemeinnützige Organisationen

Gemeinnützige Organisationen und Wohltätigkeitsorganisationen bauen selten selbst große maßgeschneiderte Plattformen, aber sie sind häufig am empfangenden Ende von Software, die von einer Regierungsfördergeberin beauftragt oder verlangt wird – ein Berichtsportal, ein Fallmanagementsystem, das ein Zuschuss oder Vertrag sie zu nutzen zwingt – mit wenig Einfluss auf ihre Gestaltung, ihre technischen Schulden, oder ihre Anbieterin. Eine von einem regierungsvorgeschriebenen System abhängige Sozialsektor-Organisation erbt dessen Versagensmuster, ohne irgendeinen der Hebel zu erben, sie zu beheben, was ein weiterer Grund ist, warum ergebnisbasierte Finanzierungsbeziehungen die operative Last vorgeschriebener Technologie berücksichtigen müssen (siehe Thema 3.7 — Öffentliche Beschaffung und Leistungsvergabe), nicht nur die Ergebniskennzahl selbst.

Multilaterale und internationale Organisationen

Multilaterale Stellen und Entwicklungsbehörden fördern zunehmend für die öffentliche Verwaltung eines Landes gebaute Software als wiederverwendbares digitales öffentliches Gut, das andere Länder anpassen können, statt dass jede Regierung ein äquivalentes System von einer privaten Anbieterin zu vollen Kosten beauftragt. Das eigentümliche Risiko hier ist, dass ein für den rechtlichen und administrativen Kontext eines Landes gebautes digitales öffentliches Gut andernorts mit zu wenig Anpassung übernommen werden kann, Annahmen importierend – über Identität, Zulassung, oder Prozess –, die sich tatsächlich nicht übertragen; das Versprechen geteilter, offener Infrastruktur ist real, aber nur, wo echte lokale Anpassungskapazität den Code begleitet.

Häufige Fehlermuster

Die Big-Bang-Umschaltung, die beim Go-Live versagt. Ein kritisches Altsystem wird in einer einzelnen, irreversiblen Umschaltung nach Jahren der Entwicklung ohne laufende Produktionsexponierung ersetzt, und ein Fehler, der erst im echten Maßstab oder in einem Randfall auftaucht, den niemand testete, tritt am ersten Tag vollen Betriebs zutage, ohne Weg zurück zum alten System, weil es bereits außer Betrieb genommen wurde. Die Kosten werden in verpassten Zahlungen, verweigerten Diensten, oder Ausfällen gemessen, die genau die Bürgerinnen betreffen, denen das System dienen soll, im schlimmstmöglichen Moment – dem Moment, in dem sich alle darauf verließen, dass der Ersatz funktionierte.

Stille Anhäufung technischer Schulden. Fristdruck gewinnt wiederholt das Argument gegen die zur Behebung bekannter Abkürzungen nötige Zeit, und jeder Aufschub ist einzeln vertretbar, bis die angehäuften Schulden selbst eine kleine Änderung unverhältnismäßig teuer und riskant machen. Die Kosten treten Jahre später zutage, als ein System, das niemand sicher modifizieren kann, eine Belegschaft, die still aufgehört hat, irgendetwas außer den dringendsten Patches zu versuchen, und ein letztendliches Modernisierungsprogramm, weit größer und teurer, als kontinuierliche, kleinere Erneuerung gewesen wäre.

Anbieterabhängigkeit mit Stabilität verwechselt. Eine öffentliche Stelle erneuert wiederholt den Vertrag derselben Anbieterin, weil ein Wechsel zu störend erscheint, um versucht zu werden, ohne je zu testen, was echte Wechselkosten wären, oder für den Code-Besitz und offene Datenformate zu verhandeln, die diese Kosten handhabbar hielten. Die Kosten sind eine permanent geschwächte Verhandlungsposition bei Preis und Bedingungen, erst entdeckt, wenn die Dienstqualität der Anbieterin sinkt oder ihre Preisgestaltung steigt und die öffentliche Stelle findet, dass sie keine glaubwürdige Alternative hat.

Kosmetisch Agiles. Ein Erbringungsteam übernimmt agile Zeremonien – Stand-ups, Sprints, ein Backlog –, während der zugrunde liegende Vertrag, die Finanzierung, und die Governance-Struktur immer noch eine feste Spezifikation und einen einzelnen Go/No-Go-Meilenstein annehmen, sodass das Team Sprint-Geschwindigkeit berichtet, während es tatsächlich gegen einen darunterliegenden Wasserfallplan liefert. Die Kosten sind, dass keiner von Agiles echten Nutzen – frühes Nutzerfeedback, das Richtung ändert, früh zutage tretendes Risiko – sich materialisiert, während der Anschein moderner Praxis die zugrunde liegende Starrheit für Aufsichtsstellen schwerer zu sehen und anzufechten macht.

Open-Source-Politik ohne Erhaltungsplan. Eine öffentliche Stelle veröffentlicht Quellcode, um eine Open-Source-als-Standard-Politik zu erfüllen, behandelt die Veröffentlichung aber als einmaligen Compliance-Schritt, ohne Ressourcierung für die Überprüfung externer Beiträge, das Patchen von Schwachstellen, oder die Pflege von Dokumentation. Die Kosten sind ein veröffentlichtes Repository, das offen aussieht, aber als ungewartete Sackgasse funktioniert, was Vertrauen in das breitere Open-Source-als-Standard-Programm mehr beschädigt, als es nie zu veröffentlichen getan hätte.

Reifegradmodell

Liste zur Überprüfung

• Inventarisieren Sie die technischen Schulden jedes kritischen Systems und überprüfen Sie das Register auf festem Zyklus.
• Wenden Sie einen dokumentierten Bauen-versus-Kaufen-Rahmen an, bevor Sie sich zu bedeutender neuer Software verpflichten.
• Greifen Sie für jede Altsystem-Ersetzung standardmäßig auf eine inkrementelle Migrationsmethode zurück und verlangen Sie eine explizite Rechtfertigung für eine Big-Bang-Umschaltung.
• Bestätigen Sie Quellcode-Besitz oder Hinterlegungsbedingungen in jedem Softwarevertrag vor Unterzeichnung.
• Veröffentlichen Sie Quellcode unter einer Open-Source-als-Standard-Politik, mit dokumentiertem Ausnahmeprozess.
• Versehen Sie laufende Wartung für jedes unter dieser Politik veröffentlichte Repository mit Ressourcen, nicht nur seine erste Veröffentlichung.
• Verlangen Sie offene, dokumentierte Datenformate, selbst wo die zugrunde liegende Software proprietär ist.
• Strukturieren Sie Finanzierungstore um demonstrierte funktionierende Software, statt um einen einzelnen Festspezifikationsmeilenstein.
• Bauen und testen Sie ein minimal tragfähiges Produkt mit echten Nutzenden, bevor Sie sich zum vollen Umfang verpflichten.
• Verfolgen Sie Bereitstellungsfrequenz, Fehlerraten, und ausstehende technische Schulden als stehende Governance-Indikatoren.
• Bewerten Sie interne Engineering-Fähigkeit gegen das, was gebraucht wird, um eine intelligente Käuferin zu sein, und schließen Sie identifizierte Lücken.
• Priorisieren Sie nicht unterstützte Infrastruktur und undokumentierte Integrationen vor kosmetischer Modernisierung.

Hauptquellen

• GOV.UK Service Standard, Government Digital Service, Vereinigtes Königreich — ein nationaler digitaler-Dienst-Standard, der iterative, nutzerzentrierte Erbringung und offene Standards für öffentliche Dienste verlangt.
• Office of Management and Budget, Federal Source Code Policy (M-16-21), Vereinigte Staaten — die föderale Politik, die von Behörden verlangt, Wiederverwendung und Open-Source-Veröffentlichung für maßgeschneidert entwickelte Regierungssoftware zu erwägen.
• Free Software Foundation Europe, Public Money, Public Code-Kampagne — die für ein europäisches Publikum entwickelte Begründung, öffentlich finanzierten Softwarequellcode unter freien und Open-Source-Lizenzen zu veröffentlichen.
• Ward Cunningham, „The WyCash Portfolio Management System" (OOPSLA-1992-Erfahrungsbericht) — die ursprüngliche Darlegung der technische-Schulden-Metapher.
• Digital Public Goods Alliance — eine Multi-Stakeholder-Initiative, die Standards und ein Register für offene Software, Daten, und Inhalt pflegt, gestaltet, um öffentlichen Entwicklungszielen zu dienen.

Referenzen

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. 'The WyCash Portfolio Management System' (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/