Was unsere Kunden brauchen - nicht nur, was sie beauftragen
Die Lücke zwischen Auftrag und Bedarf ist in regulierten IT-Umgebungen besonders groß. Wie wir damit umgehen.
Wenn ein Kunde zu uns kommt und sagt: “Wir müssen von JBoss EAP 7 auf EAP 8 migrieren”, dann ist das ein Auftrag. Es beschreibt, was gemacht werden soll. Es beschreibt aber meistens nicht, warum das Problem entstanden ist - und auch nicht, was danach gelöst sein soll.
Diese Lücke zwischen dem, was beauftragt wird, und dem, was tatsächlich gebraucht wird, ist in regulierten IT-Umgebungen besonders groß. Und sie zu ignorieren ist einer der häufigsten Gründe, warum IT-Projekte im Enterprise-Kontext scheitern: nicht technisch, sondern strategisch.
Der Auftrag ist selten das eigentliche Problem
In einer typischen Situation sieht es so aus: Eine regulierte Organisation - Bank, Versicherung, Energieversorger - hat JBoss EAP 7 im Einsatz. Das End-of-Life-Datum rückt näher. Eine interne IT-Projektleitung formuliert den Auftrag: Migration auf EAP 8 bis Q3. Der Auftrag landet beim externen Dienstleister.
Was in diesem Moment verschwindet, sind die eigentlichen Rahmenbedingungen: Wie werden die Systeme heute betrieben? Manuell? Mit welchen Skripten? Wer kennt die Konfiguration überhaupt? Wurden die letzten drei Security-Patches eingespielt - und wenn ja, wie? Gibt es eine Dokumentation, die über “funktioniert irgendwie” hinausgeht?
In mehreren Projekten haben wir erlebt, dass die Migration selbst technisch in wenigen Wochen machbar gewesen wäre. Das Problem war, dass nach der Migration dieselben operativen Bedingungen geherrscht hätten wie davor: keine Automatisierung, keine reproduzierbare Deployment-Logik, keine strukturierten Compliance-Nachweise. EAP 8 statt EAP 7 - aber dasselbe neue Legacy, nur neueren Datums.
Zwei Fragen, die wir immer stellen
Bevor wir in einem Projekt ein Angebot formulieren, stellen wir zwei Fragen, die selten im Lastenheft stehen:
Was passiert nach der Lieferung? Wer betreibt das System danach? Mit welchen Ressourcen? Wie werden Konfigurationsänderungen dokumentiert? Wenn ein Playbook deployed wird und sechs Monate später kein Mensch mehr weiß, was es tut, dann haben wir zwar einen Auftrag erfüllt - aber keinen nachhaltigen Mehrwert geliefert.
Was hat das eigentliche Problem ausgelöst? End-of-Life-Daten sind selten die Ursache. Sie sind ein Druckmittel, das ein latentes Problem sichtbar macht. Das latente Problem ist meistens: fehlende Automatisierungsstrategie, technische Schulden in der Konfigurationsverwaltung, oder fehlendes Wissen im Team, das die Systeme betreiben soll.
Diese Fragen werden nicht immer willkommen geheißen. Manchmal ist der interne Projektsponsor froh, wenn ein externer Dienstleister einfach liefert, was bestellt wurde, ohne die Prozessfragen aufzumachen. Wir machen sie trotzdem auf - weil es in regulierten Umgebungen, wo ein Audit-Befund echte Konsequenzen hat, keine gute Option ist, so zu tun, als wären sie irrelevant.
Was das konkret verändert
Ein anonymisiertes Beispiel: Ein Finanzdienstleister beauftragte uns mit der JBoss-EAP-Migration für eine Gruppe von Applikationsservern. Im ersten Gespräch stellte sich heraus, dass Deployments bisher manuell über die Admin-Console stattfanden - durch eine Person, die die Umgebung seit Jahren kannte und deren Wissen nirgendwo dokumentiert war.
Der eigentliche Bedarf war nicht nur die Migration, sondern ein Deployment-Prozess, der ohne diese eine Person funktionierte und der nachweisbar reproduzierbar war. Wir haben die Migration zusammen mit einer Ansible-basierten Deployment-Automatisierung geliefert. Der Mehraufwand war gering. Der Unterschied für den Kunden war erheblich - nicht nur operativ, sondern auch in Hinblick auf die nächste interne Prüfung.
Das ist nicht immer so eindeutig. Es gibt Projekte, bei denen der Auftrag und der Bedarf wirklich übereinstimmen. Aber die Wahrscheinlichkeit dafür steigt, wenn man früh fragt.
Grenzen dieser Herangehensweise
Wir sind kein Strategieberatungsunternehmen. Wir sind kein IT-Management-Consultant, der Organisationsanalysen liefert. Unsere Stärke liegt in der technischen Umsetzung: Ansible, Red Hat AAP, JBoss EAP, Hardening, Compliance-Automatisierung.
Was wir nicht machen: Kunden in unbegrenzte Scope-Erweiterungen hineindrängen, die sie nicht wollen oder für die keine Ressourcen vorhanden sind. Wenn ein Kunde sagt, “die Migration, und nichts anderes”, dann respektieren wir das. Wir machen die Risiken transparent - einmal, klar, ohne Drama. Was danach mit dieser Information geschieht, liegt beim Kunden.
Aber diesen einen Schritt - die Frage nach dem eigentlichen Bedarf stellen - überspringen wir nicht. In regulierten Umgebungen ist das kein Luxus. Es ist das Minimum, was eine seriöse technische Beratung leisten sollte.