Thomas Brenner, 47 — Leiter IT & Digitalisierung
Thomas ist seit 12 Jahren im Unternehmen und hat die Individualsoftware mitaufgebaut. Sein Team besteht aus 8 Entwicklern, alle tief im Jakarta EE Ökosystem verwurzelt. Die Anwendung läuft — aber sie sieht aus wie 2012 und fühlt sich auch so an.
Seine Situation: Der Druck kommt von zwei Seiten. Die Geschäftsleitung war auf einer Messe, hat moderne Dashboards gesehen und fragt jetzt: „Warum sieht unsere Software nicht so aus?“ Gleichzeitig beschweren sich Fachabteilungen zunehmend über die UX — zu viele Klicks, nicht mobilfähig, unintuitiv für neue Mitarbeiter. Thomas weiß, dass etwas passieren muss, aber er hat Angst, das falsche Pferd zu reiten.
Was ihn nachts wachhält:
- „Wenn wir den Stack wechseln, können meine Leute das überhaupt? Oder stehen wir dann mit einer Technologie da, die wir nicht beherrschen?“
- „Die Geschäftsleitung will schnelle Ergebnisse sehen. Ich kann nicht zwei Jahre im Keller verschwinden und dann vielleicht etwas liefern.“
- „Was passiert mit den 10+ Jahren Businesslogik, die in der bestehenden Anwendung steckt?“
Seine Erwartungshaltung an einen Dienstleister:
- Ehrliche Einschätzung, ob ein Stackwechsel wirklich nötig ist oder ob man JSF modernisieren kann
- Klare Aussage, was realistisch machbar ist — mit seinem Team, seinem Budget, seinem Zeitrahmen
- Kein Verkaufsgespräch für eine bestimmte Technologie, sondern eine Empfehlung, die sein Risiko minimiert
- Referenzen oder Erfahrung mit genau dieser Art von Migration
Was ihn überzeugt:
- Jemand, der Jakarta EE und moderne Alternativen kennt und ehrlich abwägen kann
- Ein stufenweiser Ansatz statt Big Bang — er braucht Quick Wins für die Geschäftsleitung
- Konkretes Verständnis für sein Problem, nicht generische Modernisierungsfolien
- Wenn der Dienstleister die Risiken von sich aus anspricht, nicht erst auf Nachfrage
Was ihn abschreckt:
- „Wir machen alles neu in React/Angular“ ohne Erklärung, was mit dem Bestand passiert
- Vage Roadmaps ohne klare Deliverables pro Phase
- Berater, die nur die neue Welt kennen und JSF/Jakarta EE als „Legacy-Problem“ abtun
- Wenn er das Gefühl hat, Abhängigkeit aufzubauen statt Kompetenz im eigenen Team
Seine Entscheidungskriterien (priorisiert):
- Risikominimierung — kein Ansatz, der sein laufendes System gefährdet
- Teamfähigkeit — sein bestehendes Team muss mitgenommen werden
- Sichtbare Ergebnisse innerhalb von 3–6 Monaten
- Kosten-Transparenz — er muss das intern verkaufen können
- Langfristige Autonomie — er will nicht dauerhaft vom Dienstleister abhängig sein
