JBoss EAP 7: Wenn das Know-how fehlt, das niemand mehr lernt

JBoss EAP 7 wird nicht mehr aktiv gelehrt. Universitäten und Bootcamps haben ihre Java-Lehrpläne seit 2018 systematisch auf Spring Boot, Quarkus und Kubernetes ausgerichtet. Was übrig bleibt: eine schrumpfende Gruppe von Engineers, die das Ökosystem aus der täglichen Arbeit kennen - und die zunehmend schwer zu finden oder zu halten sind.

Was “JBoss-Know-how” tatsächlich bedeutet

Oberflächlich klingt JBoss EAP nach einem Standard-Java-EE-Server. In der Praxis verbirgt sich dahinter ein tiefes, spezifisches Wissenssystem, das sich von generischem Java-Wissen klar unterscheidet.

Tiefes JBoss-Know-how umfasst mindestens diese Bereiche:

Classloading und Modul-System (JBoss Modules): EAP 7 verwendet kein Standard-OSGi, sondern ein eigenes Modul-System mit komplexen Abhängigkeitsregeln. Falsch konfigurierte Classloader-Hierarchien führen zu schwer diagnostizierbaren ClassCastException-Fehlern und Deployment-Problemen.
Security Realms und Subsystem-Konfiguration: Die Sicherheitskonfiguration in EAP 7 läuft über security-realm-Definitionen in der standalone.xml oder domain.xml, nicht über moderne OIDC-Flows. Wer diese Struktur nicht kennt, misconfigured stillschweigend.
Domain Mode vs. Standalone: JBoss EAP 7 bietet Domain Mode für zentralisiertes Multi-Server-Management. Viele Organisationen nutzen ihn, aber nur wenige Engineers verstehen seine Fallstricke bei Rolling Deployments und Host Controller-Konfigurationen.
CLI-Scripting (jboss-cli): Automatisierte Konfigurationsänderungen laufen über die JBoss CLI. Wer nur mit GUI-Tools oder manueller XML-Bearbeitung gearbeitet hat, kann weder reproduzierbare Deployments bauen noch Konfigurationsänderungen automatisiert prüfen.
Clustering und Infinispan: Session-Replikation, Singleton-Deployments und Infinispan-Caches haben in EAP 7 spezifische Konfigurationsmuster, die von allgemeinem Clustering-Wissen abweichen.

Warum generische Java-Entwickler das nicht “einfach lernen”

Eine häufige Annahme in IT-Leitungsebenen: JBoss EAP sei “nur ein Application Server”, jeder Senior Java Developer könne sich einarbeiten. Das ist in regulierten, komplexen Produktionsumgebungen falsch.

Das Problem ist nicht Intelligenz oder Lernbereitschaft. Das Problem ist Ökosystem-Fremdheit. Ein Spring-Boot-Entwickler denkt in AutoConfiguration, Starter-Abhängigkeiten und eingebetteten Tomcat-Instanzen. JBoss EAP denkt in Deployment Units, Subsystem-Definitionen, Classloader-Scopes und Management-API-Aufrufen.

Realistisch gerechnet: Ein erfahrener Java-Developer ohne JBoss-Hintergrund benötigt drei bis sechs Monate intensiver Einarbeitung, um JBoss EAP 7 in einer Produktionsumgebung sicher zu betreiben - nicht nur deploy-fähig zu sein, sondern Fehler zu diagnostizieren, Security-Konfigurationen zu bewerten und Performance-Probleme zu isolieren.

Diese Zeit steht in einem laufenden Migrationsprojekt oft nicht zur Verfügung.

Marktdaten: Wo JBoss-Spezialisten noch zu finden sind

Laut Auswertungen von Stellenmarkt-Plattformen (XING, LinkedIn, Stack Overflow Developer Survey 2024) ist das Angebot an JBoss-EAP-Spezialisten seit 2020 um schätzungsweise 30 bis 40 Prozent zurückgegangen - gemessen an selbst gemeldeten Skills auf Profilen.

Gleichzeitig steigt der Bedarf: Organisationen, die seit Jahren auf JBoss EAP 7 setzen und jetzt migrieren müssen, suchen alle gleichzeitig nach denselben knappen Profilen. Erfahrene JBoss-Engineers mit drei oder mehr Jahren Produktionserfahrung verlangen auf dem Markt Stundensätze zwischen 110 und 180 Euro - oft 20 bis 30 Prozent über vergleichbaren Spring-Entwicklerprofilen.

Für Organisationen, die Migration und laufenden Betrieb gleichzeitig stemmen müssen, entsteht ein Engpass: Die Person, die das System kennt, wird für den Betrieb gebraucht - und steht damit nicht vollständig für die Migration zur Verfügung.

Wie dieser Kapazitätsengpass die Migrationsplanung konkret beeinflusst: JBoss EAP 7: Wenn Teams schon an der Kapazitätsgrenze sind

Das Schlüsselperson-Risiko

In vielen Organisationen gibt es genau eine Person mit tiefem JBoss-Know-how. Diese Person war beim initialen Aufbau dabei, hat im Laufe der Jahre Dutzende undokumentierter Anpassungen vorgenommen und kennt die “stillen Regeln” des Systems: Welche Deployments sich gegenseitig beeinflussen, welcher Classloader-Trick ein Problem vor Jahren gelöst hat, welche Security-Realm-Konfiguration niemals angefasst werden darf.

Wenn diese Person das Unternehmen verlässt - durch Kündigung, Elternzeit, Krankheit oder Renteneintritt - entsteht ein Wissensdefizit, das sich nicht durch Einlesen in die Dokumentation schließen lässt. Undokumentierte Konfigurationen, die “irgendwie funktionieren”, werden erst beim nächsten Incident sichtbar.

Laut einer internen Analyse eines großen deutschen Industrieunternehmens (2024) hatte deren JBoss-Umgebung 37 Konfigurationsabweichungen vom dokumentierten Sollzustand - alle von einer einzigen Person eingeführt, keine davon in einem Change-Management-System erfasst.

Wie Configuration Drift dieser Art Compliance-Risiken produziert: JBoss EAP 7: Configuration Drift und Compliance-Risiken

Knowledge Transfer: Was sinnvoll ist und was nicht

Wenn der einzige JBoss-Experte geht oder die Kapazität für eine Migration beschafft werden muss, stehen Organisationen vor einer Entscheidung:

Option 1: Interner Knowledge Transfer Dokumentation aller Konfigurationen, Pairing-Sessions, strukturierte Übergabe. Realistische Zeitschätzung: acht bis zwölf Wochen für eine vollständige, belastbare Wissensbasis. Voraussetzung: die Person ist noch verfügbar und kooperiert aktiv.

Option 2: Externer Spezialist Kurzfristig teurer, aber unabhängig vom internen Personalrisiko. Qualifizierte JBoss-Berater kennen typische Konfigurationsmuster und können in zwei bis vier Wochen eine Bestandsaufnahme liefern, die intern mit sechs Monaten zu Papier gebracht werden müsste.

Option 3: Automatisiertes Konfigurationsaudit Werkzeuge, die die bestehende standalone.xml oder domain.xml analysieren und Abweichungen von bekannten Best Practices identifizieren. Kein Ersatz für tatsächliches Wissen, aber ein guter Startpunkt für eine strukturierte Übergabe.

Option 1 ist ideal, aber abhängig von Faktoren, die die Organisation nicht kontrolliert. Option 3 liefert oft wertvolle Impulse für Option 2.

Welche Ausstiegswege bei unterschiedlicher Ausgangslage sinnvoll sind: JBoss EAP 7: Drei Wege aus dem Extended Support

Was fehlendes Know-how bei der Migration konkret kostet

Migrations-Projekte ohne ausreichendes JBoss-Know-how auf Projektseite folgen einem typischen Muster: Die ersten vier Wochen verlaufen planmäßig. Dann kommen die ersten Deployment-Fehler in der neuen Umgebung - ausgelöst durch Classloading-Unterschiede, fehlende EAR-zu-WAR-Konvertierungen oder Security-Konfigurationen, die in EAP 8 anders modelliert werden müssen.

Was folgt: Verzögerungen, Sprint-Scope-Anpassungen, Nachfragen beim Hersteller-Support und - teuerster Fall - ein Rollback auf die alte Umgebung, während ein neues Projektteam aufgebaut wird.

Gartner schätzt, dass 40 bis 60 Prozent aller Middleware-Migrationen ihren initialen Zeitplan um mehr als 50 Prozent überschreiten. Fehlendes spezifisches Know-how ist einer der drei am häufigsten genannten Gründe.

Die Kostenwirkung: Wenn eine geplante sechsmonatige Migration acht bis neun Monate dauert, entstehen zusätzliche Personalkosten von 30.000 bis 60.000 Euro - zuzüglich der verlängerten ELS-Lizenzkosten.

Mehr zu den finanziellen Risiken des Weiterbetriebs: JBoss EAP 7 Extended Support: Was Lizenzkosten und Audits wirklich kosten

FAQ

Kann ein Quarkus- oder WildFly-Entwickler JBoss EAP 7 migrieren?

Bedingt. WildFly-Wissen überträgt sich am besten, da EAP auf WildFly basiert. Quarkus-Entwickler kennen den Wildfly-Unterbau oft nicht. Kritisch ist vor allem das EAP-7-spezifische Security- und Classloading-Modell.

Wie erkenne ich, ob mein Team ausreichend Know-how für die Migration hat?

Konkrete Testfragen: Kann das Team die Classloader-Hierarchie für ein gegebenes Deployment erklären? Kann es Security Realms in der CLI konfigurieren? Kann es einen Domain-Mode-Rollout scripted durchführen? Wenn mehr als eine dieser Fragen unklar bleibt, ist externer Support sinnvoll.

Wie lange dauert eine strukturierte JBoss-Wissensübergabe?

Für eine vollständige Übergabe - Konfiguration, Betriebsregeln, undokumentierte Ausnahmen - sind realistisch acht bis zwölf Wochen anzusetzen, wenn die übergebende Person kooperiert. Eine Minimalübergabe für kritische Systeme ist in zwei bis vier Wochen möglich.

Was tun, wenn der einzige JBoss-Experte gerade weg ist?

Sofortmaßnahme: Konfigurationsdateien sichern, Change-Freeze einführen, externen Spezialisten für ein schnelles Audit beauftragen. Dann schrittweise Dokumentation aufbauen. Einen Plattform-Check kann dabei helfen, den Ist-Zustand schnell zu erfassen.

Lohnt sich Ausbildung interner Mitarbeiter auf JBoss EAP 7?

Kaum. Der Zeithorizont für eine belastbare Einarbeitung überlappt mit dem Support-Ende Oktober 2027. Besser ist es, Wissen auf die Zielplattform (EAP 8, Quarkus oder alternatives Target) zu konzentrieren.

Wenn Sie JBoss-Migration oder Härtung planen und intern die Spezialisten fehlen: SPAS Overview von Lennlay zeigt, wie externe Kapazität in regulierten Umgebungen strukturiert eingebunden wird.