Nicolai Paul Hoffmann ist zertifizierter Software-Architekt für IT-Migration und unterstützt Unternehmen dabei, ihre gewachsenen Systeme zukunftsfähig zu machen. Im Gespräch mit dem „Legacy IT Center“ erklärt er, warum Respekt für Wissensträger entscheidend ist, wann Monolithen die bessere Wahl bleiben – und weshalb er sich ausgerechnet für das „unsexy“ Thema Legacy IT begeistert.
Was hat Dich ursprünglich zum Thema Legacy IT und „alten“ Programmiersprachen gezogen? Gab es einen Aha-Moment oder ein Projekt, das Dich gepackt hat?
Der entscheidende Moment war, als mir klar wurde: Alle stürzen sich auf die schicken neuen Projekte, doch in den alten Systemen steckt der meiste Wert – und kaum jemand will Verantwortung übernehmen. In neuen Vorhaben werden Fehler oft wiederholt, weil niemand versteht, warum eine Legacy-Anwendung so geworden ist. Mich packt genau diese Mischung: anstrengend, unübersichtlich, aber bewährt und respektwürdig. Ich gehe bewusst dorthin, wo andere weglaufen, und helfe, etwas Zukunftsfähiges daraus zu machen. Vielleicht reizt mich das wie bei meinen Lieblingsspielen, den Soulslikes – schwer, aber umso lohnender, wenn man es schafft.
Du hast am Buch „IT für Anfänger“ mitgewirkt: Wie kam es dazu, welche Teile verantwortest Du und an wen richtet sich das Buch?
Der Herausgeber sprach mich an, und ich war sofort begeistert. Mein ursprüngliches Thema „Legacy“ passte nicht so recht in ein Einstiegsbuch, also haben wir uns für zwei Grundlagen entschieden: Cloud und Programmiersprachen. Gerade bei der Cloud gibt es viele Missverständnisse, und Programmiersprachen gehören einfach in jedes IT-Einsteigerbuch. Das Buch richtet sich an alle, die mehr über IT wissen wollen – Quereinsteiger, Interessierte oder Menschen, die verstehen möchten, was ihre Kollegen oder Partner in der IT eigentlich tun. Für Entscheider bedeutet es: eine gemeinsame Sprache finden und die Arbeit der IT-Teams besser einordnen.
Wenn Du in ein gewachsenes Altsystem kommst: Woran erkennst Du, ob wirklich modernisiert werden muss? Und wie sieht Dein 90 Tage-Plan aus – erst aufräumen und die Fachlogik heben, bevor Architekturentscheidungen fallen?
Für mich ist entscheidend, wie schnell Anforderungen umgesetzt werden können und ob das System die Kundenbedürfnisse erfüllt. Performance ist nur wichtig, wenn Kunden sie wirklich verlangen. Häufig heißt es: „Wir haben zu viele Individualitäten.“ Tatsächlich liegt es meist daran, dass die Software gar nicht auf Variabilität ausgelegt ist. Individualisierung kann teuer sein, lässt sich aber so gestalten, dass sie wartbar bleibt. Mein 90 Tage-Plan: Erst den Ist-Stand erfassen, dann ein Soll-Bild mit allen Stakeholdern abgleichen, anschließend Architekturprinzipien festlegen – Wartbarkeit vor „fancy features“. Und vor allem: Fachlogik verstehen und Ordnung schaffen, bevor neue Technologien eingeführt werden.
Aus dieser Diagnose heraus: Wann bleibt ein Monolith die bessere Wahl und wann lohnen sich Microservices – und wie vermeidest Du den im Vorgespräch erwähnten Schritt vom „Big Ball of Mud“ zum verteilten „Big Ball of Mud“?
Ein Monolith ist völlig in Ordnung, wenn unabhängiges Deployment nicht gebraucht wird. Oft funktioniert ein modularer Monolith sehr gut. Geht man zu Microservices über, muss die Fachlogik vorher sauber geschnitten werden: hohe Kohäsion innerhalb der Module, geringe Kopplung zwischen ihnen. Überspringt man diesen Schritt, reden zu viele Services miteinander, und am Ende entsteht ein verteilter „Big Ball of Mud“, nur noch komplexer durch das Netzwerk. Besser ist es, klare Schnittstellen zu schaffen und dann gezielt Services auszugliedern, wo Skalierung oder Isolation gebraucht werden. So bleibt die Architektur beherrschbar.
Ohne die Wissensträger geht es nicht: Welche Erfahrungen hast Du mit ihnen gemacht – und warum spielt Wertschätzung dabei so eine große Rolle?
Ich habe erlebt, wie ein Entwickler unter großem Druck ein Feature lieferte, von dem die Existenz eines Unternehmens abhing. Der Code war nicht schön, aber er funktionierte – und genau das rettete den Kunden. Das verdient Respekt. Wissensträger teilen ihr Know-how gerne, wenn man sie ernst nimmt und ihre Arbeit würdigt. Wer dagegen ständig hört, dass sein 20 Jahre altes Produkt schlecht sei, zieht sich zurück. Ihr Wissen über Kunden, Abläufe und Fachlogik ist einzigartig. Wer diesen Schatz nicht respektiert, verliert die wichtigste Ressource für eine erfolgreiche Modernisierung.
Wie stellst Du Wissenstransfer und Zusammenarbeit mit diesen Wissensträgern konkret sicher – ohne neue Single Points of Failure zu schaffen?
Der Schlüssel ist, sie früh einzubinden und Verantwortung zu verteilen. Wissensträger müssen keine neue Technologie beherrschen, um wertvolle Hinweise zu geben. Erfolgreich wird es, wenn Fachlogik gemeinsam dokumentiert wird, klare Ansprechpartner definiert sind und das Team offen über frühere Fehler spricht. So wird Wissen breiter verteilt, Abhängigkeiten werden reduziert, und die Modernisierung gewinnt Tempo, ohne Substanz zu verlieren.
Vielen Dank für das Gespräch. (td)
Kurzvita
Nicolai Paul Hoffmann ist zertifizierter Software-Architekt mit Schwerpunkt Legacy IT und IT-Migration. Nach seiner Ausbildung zum Fachinformatiker für Anwendungsentwicklung arbeitete er mehrere Jahre als Softwareentwickler, zuletzt als Senior Softwareentwickler. Heute ist er selbstständig tätig und unterstützt Unternehmen bei der Modernisierung gewachsener Systeme.
Über „IT für Anfänger“
Das Buch „IT für Anfänger: Die Grundlagen der Informatik einfach erklärt“ (Hrsg. David Kaselow) macht komplexe Informatik-Themen leicht verständlich und führt Schritt für Schritt in spannende Bereiche wie Künstliche Intelligenz, Cybersecurity und Programmieren ein. Dank praxisnaher Beispiele und klarer Sprache wird IT-Wissen so erklärt, dass wirklich jeder den Einstieg schafft.
