Stell dir vor, du hast ein Budget von 500.000 Euro für die Digitalisierung einer Fachanwendung freigegeben bekommen. Dein Team ist motiviert, die Lastenhefte sind geschrieben und du denkst, dass du jetzt einfach loslegen kannst. Du schickst deine Anforderungen an das IT Dienstleistungszentrum des Freistaats Bayern und wartest darauf, dass die Server bereitgestellt werden. Drei Monate später stellst du fest: Nichts bewegt sich. Die Sicherheitsvorgaben passen nicht zu deiner Architektur, die Schnittstellen zum Behördennetz sind blockiert und dein Zeitplan ist bereits jetzt Makulatur. Ich habe dieses Szenario in meiner aktiven Zeit in München immer wieder erlebt. Projektleiter kommen mit der Erwartungshaltung eines Cloud-Startups in eine Umgebung, die nach den Regeln der staatlichen Souveränität und maximaler Sicherheit funktioniert. Wer hier versucht, den Kopf durch die Wand zu stecken, verliert nicht nur Geld, sondern auch seine Reputation innerhalb der Verwaltung.
Der fatale Glaube an die Standard-Cloud-Logik beim IT Dienstleistungszentrum des Freistaats Bayern
Der größte Fehler, den ich bei Neulingen beobachtet habe, ist die Annahme, dass der zentrale Dienstleister wie ein kommerzieller Provider funktioniert. Bei AWS oder Azure klickst du dir eine Instanz zusammen und sie ist da. Hier im staatlichen Kontext geht es um Hochsicherheitsinfrastruktur. Wenn du glaubst, dass du "einfach mal schnell" eine API nach außen öffnen kannst, hast du die Rechnung ohne die bayerischen Sicherheitsrichtlinien gemacht.
Das Problem ist meistens nicht die Technik, sondern die mangelnde Vorbereitung auf die bürokratischen und regulatorischen Leitplanken. Ein Projektleiter, der denkt, er könne moderne DevOps-Zyklen ohne Rücksicht auf die Wartungsfenster des Freistaats fahren, wird hart auf dem Boden der Tatsachen landen. In meiner Praxis saßen Leute vor mir, die völlig fassungslos waren, weil ihre Container-Strategie nicht mit den zentralen Firewall-Regeln kompatibel war. Das hat nichts mit Schikane zu tun. Es geht um den Schutz von Millionen von Bürgerdaten.
Die Lösung ist simpel, aber schmerzhaft: Du musst deine Architektur von Anfang an um die Restriktionen herum bauen, statt sie nachträglich hineinpressen zu wollen. Das bedeutet, dass du dich Monate vor dem ersten Code-Commit mit den Netzplänen und den Identitätsmanagement-Systemen (IDM) befassen musst. Wer das ignoriert, zahlt später für teure Umstrukturierungen der Software-Architektur, wenn die Anwendung bereits halb fertig ist.
Warum das Ignorieren der V-Modell-XT-Vorgaben dein Budget auffrisst
Viele externe Dienstleister und junge Projektleiter halten das V-Modell XT für ein Relikt aus der IT-Steinzeit. Sie kommen mit agilen Methoden um die Ecke und denken, sie könnten die Dokumentationspflichten "später nachziehen". Das ist der sicherste Weg, um in einer Abnahmeprüfung des IT Dienstleistungszentrum des Freistaats Bayern hängen zu bleiben.
Ich habe Projekte gesehen, bei denen am Ende 100.000 Euro nachgeschossen werden mussten, nur um die Dokumentation so aufzubereiten, dass sie den formalen Kriterien für den Betrieb entsprach. In der staatlichen IT ist "Betriebsreife" ein definierter Zustand. Wenn die Dokumentation der Schnittstellen oder das Sicherheitskonzept nicht exakt den bayerischen Standards entsprechen, wird die Anwendung nicht in den Wirkbetrieb übernommen. Punkt. Da gibt es kein Augenzudrücken.
Statt also gegen das V-Modell zu arbeiten, musst du es als Leitplanke akzeptieren. Es bringt dir nichts, wenn dein Code elegant ist, aber niemand im Rechenzentrum weiß, wie er im Notfall zu patchen ist, weil die Betriebsdokumentation fehlt. In meiner Zeit habe ich gelernt, dass die erfolgreichsten Projekte diejenigen waren, die einen dedizierten Mitarbeiter nur für die Einhaltung dieser formalen Standards hatten. Das klingt nach unnötigem Overhead, spart dir aber am Ende Monate an Verzögerung.
Der Irrglaube an die unbegrenzte Skalierbarkeit
Ein weiterer Punkt, an dem viele scheitern, ist die Kapazitätsplanung. Nur weil es ein zentrales Dienstleistungszentrum ist, bedeutet das nicht, dass Ressourcen unendlich und sofort verfügbar sind. Hardware muss beschafft werden, Racks müssen Platz haben, Kühlleistung muss berechnet werden. Wer seine Lastspitzen nicht sechs bis zwölf Monate im Voraus präzise prognostiziert, steht bei der nächsten Landtagswahl oder einer großen Registrierungswelle vor einem zusammenbrechenden System.
Das Sicherheitskonzept als nachträgliche Aufgabe betrachten
In der freien Wirtschaft wird Sicherheit oft als Feature betrachtet, das man später optimiert. Im Behördenumfeld ist Sicherheit das Fundament. Der Fehler: Das Sicherheitskonzept wird erst geschrieben, wenn die Anwendung fast fertig ist. Dann stellt der Informationssicherheitsbeauftragte (ISB) fest, dass die Authentifizierung nicht dem bayerischen Standard entspricht.
Ein konkreter Vorher/Nachher-Vergleich macht deutlich, was das bedeutet:
Vorher (Der falsche Weg): Ein Ministerium beauftragt eine Agentur mit der Entwicklung eines Bürgerportals. Die Agentur nutzt moderne Frameworks und eine eigene Nutzerdatenbank. Nach neun Monaten Entwicklung wird das fertige Produkt dem zentralen Dienstleister präsentiert. Das Urteil: Die Nutzerdatenbank ist unzulässig, da alle Bürgerkonten über das zentrale IDM Bayern ID laufen müssen. Die Umprogrammierung der gesamten Nutzerverwaltung dauert vier Monate und kostet 120.000 Euro extra. Der geplante Launch-Termin verstreicht, die Politik ist verärgert.
Nachher (Der richtige Weg): Bevor die erste Zeile Code geschrieben wird, findet ein Abstimmungsgespräch mit den Experten für Identitätsmanagement statt. Die Anwendung wird von Tag eins an so konzipiert, dass sie die Schnittstellen der Bayern ID nutzt. Das Sicherheitskonzept wächst modular mit jeder Entwicklungsphase mit. Als die Anwendung fertig ist, dauert die Sicherheitsabnahme lediglich zwei Wochen, da alle Anforderungen bereits im Design berücksichtigt wurden. Die Kosten für die Integration waren Teil des Basisbudgets, es gab keine bösen Überraschungen.
Dieser Unterschied in der Herangehensweise entscheidet darüber, ob du als fähiger Manager wahrgenommen wirst oder als jemand, der Steuergelder verbrennt.
Die Unterschätzung der Netzinfrastruktur im Behördennetz
Das bayerische Behördennetz (BYBN) ist kein offenes Internet. Das klingt logisch, wird aber in der Praxis ständig vergessen. Entwickler testen ihre Anwendungen in einer offenen Testumgebung und wundern sich, warum im Rechenzentrum plötzlich keine Verbindung zu externen Bibliotheken oder Updateservern möglich ist.
Ich habe erlebt, dass Projekte gestoppt wurden, weil die Anwendung darauf angewiesen war, zur Laufzeit Daten von einem Server in den USA nachzuladen. Das wird im hochsicheren Bereich des Freistaats niemals passieren. Firewalls sind hier restriktiv eingestellt, und das aus gutem Grund. Jede Verbindung nach außen muss begründet, geprüft und freigeschaltet werden.
Wer also denkt, er könne moderne Microservice-Architekturen mit hunderten von externen Abhängigkeiten fahren, wird scheitern. Du musst lernen, in "geschlossenen Systemen" zu denken. Das bedeutet: Lokale Spiegelung von Repositories, statische Sicherheitsanalysen des Codes vor dem Deployment und eine klare Kommunikation der benötigten Ports und Protokolle Monate im Voraus. Wer das versäumt, wartet Wochen auf eine Firewall-Freischaltung, während die bezahlten Entwickler untätig herumsitzen.
Das Missverständnis über die Rolle der Ansprechpartner
Ein großer Fehler ist es, die Mitarbeiter im Rechenzentrum als reine "Befehlsempfänger" zu betrachten. In der Verwaltung ist Kooperation wichtiger als hierarchisches Denken. Wer dort anruft und Forderungen stellt, ohne die internen Prozesse zu verstehen, landet ganz unten auf der Prioritätenliste.
In meiner Erfahrung ist die persönliche Beziehung zu den Fachadministratoren Gold wert. Diese Leute betreuen hunderte von Systemen. Wenn du ihnen das Leben schwer machst, indem du unvollständige Tickets einreichst oder technische Spezifikationen ignorierst, wird dein Projekt zum Stillstand kommen. Die Lösung ist, die Experten frühzeitig als Partner einzubinden. Frage sie nach ihrer Meinung zu deiner Architektur. Oft wissen sie genau, welche Konfigurationen in der Vergangenheit Probleme gemacht haben und können dir Wege aufzeigen, die in keinem Handbuch stehen.
Kostenstellen und Finanzierungsmodelle falsch kalkulieren
Die Abrechnungsmodelle innerhalb der staatlichen IT sind komplex. Es ist nicht damit getan, die VM-Preise zu kennen. Es gibt Umlagen, Pauschalen für den Grundbetrieb und variable Kosten für Sonderservices. Ein häufiger Fehler ist die Annahme, dass der Betrieb nach dem Go-Live günstiger wird.
Tatsächlich steigen die Kosten oft, weil Patch-Management, Backup-Strategien und der 24/7-Support im staatlichen Umfeld teurer sind als bei einem Billig-Hoster. Wenn du dein Budget für das Folgejahr planst, musst du die Lebenszyklus-Kosten (TCO) im Blick haben. Ich habe Projekte gesehen, die technisch brillant waren, aber nach zwei Jahren abgeschaltet werden mussten, weil das Ministerium die laufenden Betriebskosten für die Hochverfügbarkeit nicht im Haushalt eingeplant hatte.
Du musst verstehen, wie der Haushaltstitel deines Projekts funktioniert. Ist es eine einmalige Investition (Investiv) oder sind es laufende Kosten (Konsumtiv)? Diese Unterscheidung entscheidet darüber, ob du in zwei Jahren noch Geld für Updates hast. Wer hier nicht mit den Haushaltsreferenten spricht, baut eine digitale Ruine.
Realitätscheck: Was es wirklich braucht
Wenn du bis hierhin gelesen hast, merkst du vermutlich: Erfolg in diesem Umfeld hat weniger mit Coding-Skills zu tun als mit Organisationsgeschick und diplomatischer Ausdauer. Wer im Bereich der staatlichen IT-Infrastruktur glänzen will, muss ein hybrider Charakter sein — halb Techniker, halb Verwaltungsjurist.
Es gibt keine Abkürzung. Du kannst die Prozesse nicht "hacken". Das System ist darauf ausgelegt, stabil und sicher zu sein, nicht agil und experimentell. Das ist kein Bug, das ist ein Feature. Wenn du versuchst, gegen diese Natur zu arbeiten, wirst du ausbrennen und dein Projekt versenken.
Erfolg bedeutet hier:
- Akzeptanz der regulatorischen Rahmenbedingungen als unumstößliche Naturgesetze.
- Frühzeitige, ehrliche Kommunikation mit den Technikern vor Ort.
- Ein Sicherheitskonzept, das den Namen verdient und nicht erst am Ende "draufgeklatscht" wird.
- Haushaltsplanung, die über das nächste Geschäftsjahr hinausgeht.
Es ist harte Arbeit, und es ist oft frustrierend langsam. Aber wenn ein System einmal läuft, dann läuft es für Millionen von Menschen auf einem Sicherheitsniveau, das du woanders kaum findest. Du musst dich entscheiden: Willst du schnell scheitern oder langsam gewinnen? In der bayerischen Verwaltung ist Letzteres die einzige Option, die Bestand hat. Wer das nicht akzeptiert, sollte sein Glück lieber in einer Berliner Agentur suchen als in der Nähe der Münchner IT-Infrastruktur. Es ist nun mal so, dass hier andere Uhren ticken – und wer die Zeitansage ignoriert, kommt zu spät zum Erfolg.
