Transkript
Johannes Seitz: Hallo und herzlich willkommen zu einer neuen Episode des Podcasts CTO Need to Know. Heute wieder mit einer Folge zum Thema Legacy Modernisierung. Mein Name ist Johannes Seitz, ich bin Senior Consultant bei der INNOQ und inzwischen seit über 15 Jahren in der IT unterwegs.
Johannes: Dabei in den letzten Jahren mit dem Schwerpunkt Modernisierung von Legacy-Systemen und Domain Driven Design. Und heute bei mir ist der Steffen Bergmann von der Firma Meierhofer. Steffen, magst du dich mal ganz kurz vorstellen und erzählen, was du bei Meierhofer machst?
Steffen Bergmann: Hallo Johannes. Erstmal danke für die Einladung. Freut mich, dass wir heute sprechen. Mein Name ist Steffen Bergmann. Ich habe Informatik in München studiert, habe dann einige Jahre aktiv und sehr gerne im Healthcare-Umfeld entwickelt und in dem Rahmen auch viel Mikro- und Makroarchitektur gemacht. Vor allen Dingen habe ich dann komplett in die Führung gewechselt mit Schwerpunkt Softwarearchitektur und Agile Transformation und auch schon seit ungefähr acht Jahren unterwegs. Bei der Meierhofer bin ich verantwortlich für die Softwareentwicklung, Softwarearchitektur und Release Management und seit sehr guten zwei Jahren dabei.
Steffen: Würden wir die Bezeichnung nutzen, wäre ich CTO.
Johannes: Sehr schön. Und kannst du noch ein bisschen was über die Firma Meierhofer erzählen? Also was ist so euer Hauptprodukt, das sie herstellt?
Steffen: Wir sind in Herstellung von einem KIS, einem Klinik-Informationssystem. Das ist das zentrale IT-System in Krankenhäusern. Unser KIS bietet Lösungen für fast alle ärztliche, pflegerische und administrative Prozesse in Krankenhäusern. Außerdem werden noch Abrechnungsprozesse unterstützt.
Steffen: Die wesentlichen Anwendergruppen sind ärztliches und pflegerisches Personal und medizinische Fachangestellte, zum Beispiel bei der Aufnahme oder bei der Unterstützung des medizinischen Personals, bei der Dokumentation, also natürlich noch Medizinkontroller und Abrechnungsfachkräfte.
Johannes: Mhm. Das ist ja eine ganze Menge. Das heißt im Prinzip so eine Art Komplettlösung. Wenn ich ein Krankenhaus aufmachen möchte, kaufe ich so ein KIS-System und dann habe ich alles, was ich da an IT brauche, mehr oder minder in einem Softwareding. Mhm.
Steffen: Genau, wir sind auf jeden Fall so der Kern des Ganzen. Wir integrieren auch sehr viele Umsysteme, also Spezialsysteme für Radiologie oder Labor. Aber unser Anspruch ist, dass wir für alle Prozesse Lösungen bieten.
Johannes: Und inwiefern habt ihr es da mit Legacy Software zu tun? Also wie kommt da eure Berührung zu dem Thema Legacy zustande?
Steffen: Ja, wir sind schon seit vielen, vielen Jahren mit unseren Produkten erfolgreich am Markt. Wir haben die Produkte zum einen kontinuierlich gepflegt und weiterentwickelt, zum anderen haben wir bei technologischen und methodischen Weiterentwicklungen aber auch immer wieder um neue Ansätze ergänzt. Also insgesamt haben wir also viel Technologie und Code aus ganz unterschiedlichen Epochen im System. Wichtig ist mir an der Stelle eine differenzierte Betrachtung von Legacy.
Steffen: Also es gibt irgendwie viele Module, die zwar vor vielen Jahren noch anderen Methoden und Qualitätsstandards entwickelt wurden, deren Businesslogik aber immer noch aktuell ist und die sich im täglichen Betrieb noch sehr gut schlagen. Solche Module sind super wertvoll, weil sie ausgereift stabil sind, die uns sorgen für Umsatz und sie schaffen auch einfach viel Anwendernutzen. Aber dann gibt es natürlich auch Module, deren Businesslogik veraltet ist oder die Security-Probleme haben oder die auch wegen Seiteneffektrisiko dann einfach irgendwann zu unstabil sind.
Johannes: Mhm. Mhm. Mhm. Ja.
Steffen: kommt natürlich auch vor, dass die Struktur marode ist oder die Weiterentwicklung zu teuer ist. Das sind Legacy-Module, bei denen besteht Handlungsbedarf und mit denen beschäftigen wir uns dann hauptsächlich im Rahmen der Modernisierungsstrategie. Aber wichtig ist, Legacy Software ist nicht grundsätzlich schlecht, sondern vor allem erstmal auch ein wertvolles Asset.
Johannes: Mhm. Mhm. Mhm. Ja.
Johannes: Das finde ich total super. Also es gibt so eine Lieblingsdefinition von Legacy von Dylan Beattie, der mal gesagt hat, Legacy, das ist irgendwie Code, der ist zu profitabel, um ihn zu löschen, aber zu scary, um ihn zu ändern.
Johannes: Und manchmal braucht er ja auch gar keine Änderung. Dementsprechend ist es vielleicht auch gar keine gute Idee, hinzugehen und ihn einfach nur aus irgendwelchen ideologischen Gründen zu ändern, wenn er fachlich noch einwandfrei ist.
Steffen: Genau.
Johannes: Super. Das heißt, ihr habt jetzt schon ein bisschen Erfahrung gemacht mit der Modernisierung von Software-Systemen. Was wären denn so deine Ratschläge für andere Entscheider oder Entscheiderinnen, die jetzt gerade mit dieser Software-Modernisierung starten möchten?
Steffen: Ein wichtiger Ratschlag ist einfach früh anfangen und sich auch kontinuierlich damit auseinandersetzen. Also man kann sich dem Problem eh nicht entziehen. Irgendwann wird jede Software legacy und irgendwann muss man sich damit auseinandersetzen. Und je früher und je intensiver man das macht, desto besser harmonisieren dann auch neue Entwicklungen mit einer Modernisierungsstrategie. Das heißt nicht, dass man ständig alles modernisieren muss, aber man muss es beobachten, sich damit auseinandersetzen und eine Strategie haben.
Johannes: Mhm. Mhm. Mhm. Mhm.
Steffen: Bei der Bewertung und bei der Planung von Modellisierung habe ich den strategischen Aspekt vom Domain Driven Design immer als sehr hilfreich empfunden. Das hilft uns zum einen, so ein Modell der Domäne und erstmal schon mal ein grobes Idealbild der ganzen Modullandschaft zu erstellen. Da weiß man dann schon vergleichsweise wenig Aufwand, wo man insgesamt so hinkommen sollte und hat auch ein Bild, was man kommunizieren kann. Und ganz konkret helfen uns Methoden wie Event Storming, die Modularisierung dann im Detail zu planen.
Johannes: Mhm. Mhm.
Steffen: Ein weiterer Rat ist, einfach viel Zeit in die Erläuterung der Gründe und des Vorgehens zu investieren und Legacy-Software nie zu werten. Also das ist auch ein ziemlicher Spagat. Zum einen muss ehrlich und deutlich benannt werden, wenn Module den Anforderungen nicht mehr gerecht werden, damit die Mitarbeiter auch einfach verstehen, warum sie da jetzt plötzlich so viel anders machen sollen.
Johannes: Ja. Ja. Ja. Mhm.
Steffen: Man muss aber auch immer die Kollegen mitnehmen, die viel Zeit und Energie in solche Module investiert haben. Es hilft, wenn man immer wieder betont, dass das keine schlechte Arbeit war, sondern nach dem Stand der Technik einfach ein gutes Ergebnis. Sonst kann bei den Teams schnell der Eindruck entstehen, dass ihre Arbeit und ihr Ergebnis nicht geschätzt wird und das muss man auf jeden Fall vermeiden. In dem Kontext ist auch ganz wichtig, dem Management bei innen und dass man die Stakeholder gut mitnimmt.
Steffen: Also Modernisierung kostet Geld und das muss entweder investiert werden oder es fehlt bei der fachlichen Weiterentwicklung und da ist es dann wichtig, dass zum einen bis oben hin, aber auch zur Seite, also auch Sales sollte verstehen, was die Modernisierungsstrategie ist und die mittragen.
Johannes: Mhm. Ja. Mhm. Mhm. Mhm. Interessant.
Steffen: Und vielleicht noch ganz konkret, also in meiner Erfahrung waren QuickWinds Module, die in Generic liegen. Also früher hat man Funktionen für Authentifizierung, für Logging oder Eventing. Die hat man gerne selber gebaut und die lassen sich meist vergleichsweise leicht durch Standardprodukte ersetzen.
Johannes: Okay. Jetzt, wenn ich so durch die Arztpraxen der Nation tiggere, sehe ich häufiger noch mal, dass das so Windows-Applikationen in ganz vielen Fällen sind. Modern wäre aber vermutlich eher so eine Art Web-Anwendung zu machen. Und ich habe auch mitbekommen, dass ihr auch irgendwie Erfahrungen damit gemacht habt von so dieser klassischen Fett-Client-Architektur mit ganz viel Code auf dem
Johannes: Kleinsystem irgendwie ins Web zu gehen. Magst du mal ganz kurz erzählen, was da so eure Erfahrungen waren? Hallo.
Steffen: Grundsätzlich kann man das tun, das ist auch so ein Weg, den wir auch gehen. Hat aber ziemlich Herausforderungen, also zum einen ist die Wiederverwendung von Businesslogik oft eine große Herausforderung, also zu Zeiten des Headlines wurde generell Microarchitektur und Trennung von fachlichen und technischen Aspekten noch nicht so viel Bedeutung beigemessen. Da hat man dann oft zufällig, dass da Logik und Präsentation vermischt sind.
Steffen: Da die Business Logik rausgeextrahiert wird, kann anspruchsvoll sein. Außerdem ist Business Logik im FAT-Client meist nicht auf Multithreading ausgelegt. Das muss man sich sehr genau anschauen. Das kann auch passieren, dass das dann durch die Hintertüren ein kompletter Rewrite wird. Dann ist es besser, von vornherein mit einem Rewrite Gedanken ranzugehen.
Johannes: Mhm. Mhm. Mhm. Mhm.
Steffen: Außerdem ist Integration eine ziemliche Herausforderung, die funktioniert halt nur in eine Richtung. Ich kann die Web-Oberfläche in ein Fettklein integrieren, aber eben nicht umgekehrt. Und das hat Auswirkungen auf Priorisierung und Strategie.
Johannes: Jetzt hast du schon gesagt, es ist natürlich irgendwie vielleicht sogar notwendig, dass man da rangeht und sagt, ich mache da einen Rewrite. Das ist ja aber auch häufig ein riesiges System, was davon betroffen wäre.
Johannes: Also, wie geht ihr damit um, wenn das wirklich mehrere Personen, Jahregroße, Legacy-Code-Basis ist, die ihr zum Beispiel jetzt von so einem fett kleinen zu einer Web-Anwendung umbauen möchtet? Wie hilft, also wie behält ihr euch da, so eine Sanierung zuzunehmen? Das müssen wir, glaube ich, rauscutten.
Steffen: Ja, das war’s.
Johannes: Wie macht ihr das, also so eine riesige Veränderung zu strukturieren oder anzugehen?
Steffen: Also bei sehr großen Systemen hilft natürlich nur inkrementelles und iteratives Vorgehen, also zum Beispiel Strangler Architecture Pattern. Es bringt nichts, das komplette System auf einmal modernisieren zu wollen. Das würde viel zu lange dauern. Darum gehen wir in der Regel Modul für Modul vor. Das schafft natürlich neue Herausforderungen bei Planung und eben auch Integration. Grundsätzlich setzen wir
Steffen: voll auf Modularisierung, also wir lösen die monolithischen Systeme sukzessive auf und implementieren die einzelnen Bounded Contexte als eigenständige Module, also Microservice. Jetzt hier verfolgen wir dabei den Self-Content System Ansatz und versuchen auch im Zweifel eher groß zu schneiden, um die Komplexität im Betrieb nicht zu stark wachsen zu lassen.
Johannes: Mhm. Mhm.
Steffen: Also unsere Kunden betreiben unser Produkt meist noch selber. Und für kleinere Krankenhäuser wäre der Betrieb von einer kleinteiligen Microservice- Umgebung mit Hunderten von Services einfach zu herausfordernd. Die Großen könnten das, aber auch da will man die Kosten vermeiden. Eine wesentliche Herausforderung ist Kopplung. Also die Domäne ist fachlich leider sehr eng gekoppelt. Dazu kommen noch technische Abhängigkeiten aus der Vergangenheit dazu.
Johannes: Das kann ich.
Steffen: Und das macht es zum einen natürlich schwer, irgendwo im Kern der Domäne anzufangen, weil man dann gleich bei riesigen Modernisierungsprojekten landet. Der typische Reflex, den ich oft beobachtet habe, ist, dass man am Rand der Domäne beginnt, zum Beispiel erst mal so die Verwaltung von Katalogen oder Stammdaten zu modernisieren, weil da hängt einfach nicht so viel dran, wenn man dran zieht.
Johannes: Mhm. Mhm. Mhm. Ja ja. Mhm.
Steffen: In der Regel oder oft ist es aber einfach der falsche Reflex, weil da aus der DDD Sicht ist das meistens Supporting oder sogar Generic zu verorten und da hängt dann entsprechend deutlich weniger Business Value drin. Also konzentrieren wir uns im Zweifel dann also schon auf die Core-Module und versuchen einfach einen guten Umgang mit der Kopplung zu finden, im Zweifel auch Anti-Corruption-Layer oder sowas einzuziehen. Vielleicht eher auf
Johannes: Ja, super spannend.
Steffen: Strategisch gibt es drei verschiedene Wege, die wir so gehen. Wir versuchen oder wir prüfen erst, ob nicht vielleicht ein Standardprodukt das Problem schon löst, vor allem eben in Generic und falls nicht, schauen wir uns die geänderten Anforderungen und die vorhandene Implementierung einfach gut an und wenn die Business Logik noch halbwegs aktuell gut strukturiert ist,
Steffen: Dann kann man oft Web-Oberflächen ergänzen. Teilweise lösen wir in dem Schritt auch vorhandene Module raus, um sie unabhängig betreiben oder releasen zu können. Aber man hat auch immer wieder Situationen, wo sich die Anforderungen zu stark geändert haben oder der Code einfach große Schäden hat. Da bauen wir die Module dann wirklich in Greenfield herangehensweise neu auf.
Johannes: Oh. Aha.
Steffen: und kleinere Modernisierungen, die machen wir natürlich kontinuierlich. Also Prozesse, dass die Teams ihre Module beobachten, Abhängigkeiten regelmäßig auf den neuen Stand bringen und so. Die Treiber für größere Modernisierungen sind tatsächlich hauptsächlich geänderte Anforderungen. Also wenn wir halt merken, dass Modul den Anforderungen nicht mehr gerecht wird oder dass einfach viel neue Anforderungen am Horizont erscheinen, dann planen wir die Modernisierung.
Johannes: Mhm. Mhm.
Steffen: Aber es gibt eben auch ganz viele Module, die noch allen Anforderungen gerecht werden. Die fassen wir dann nicht an oder wir ergänzen höchstens noch Web-Oberflächen.
Johannes: Ja, super spannend. Jetzt kennen wir uns schon ein bisschen länger und ich weiß, du hast auch schon bei anderen Unternehmen so im Rahmen Gesundheitswesen gearbeitet. Was ist denn so deine Erfahrung gerade, wenn es um die Branche, um das Gesundheitswesen geht? Was macht das zum besonderen, zu besonderen Herausforderungen, darin irgendwie zu modernisieren?
Steffen: Also die größte Herausforderung sind aus meiner Sicht die heterogenen Prozesse bei den Kunden. Also es gibt zum einen durch die Größe, zum anderen aber auch durch historisch gewachsene Strukturen und relativ wenig fachliche Standardisierung gibt es schon sehr sehr unterschiedliche Geschäftsprozesse bei den Kunden.
Johannes: Aha. Aha. Aha. Aha.
Steffen: Die haben in der Vergangenheit sehr viel Generik hervorgebracht, weil man versucht hat, sich dann durch Customizing zu helfen. Und bei der Migration ist dann auch einfach schon wahnsinnig viel Customizing da, was man berücksichtigen muss und was einem wieder so ein paar Leitplanken in der Migration reinhaut. Durch die Komplexität der Domäne sind die einzelnen Module oft auch sehr groß.
Johannes: Ja. Aha. Aha.
Steffen: Und das erzeugt dann wieder auch spezielle Zielkonflikte. Also zum einen will man mit einem neuen Modul ja möglichst schnell in Produktion, um Feedback zu bekommen. Und wenn man dann nur kleine Teile rauslöst, hat man oft so einen Schnitt, das will man mitten durch den Bauenden Kontext, eine breite Schnittstelle.
Steffen: zwischen Legacy-System und dem neuen System und das kostet dann zunächst mal viel und vor allen Dingen macht es auch bei der kontinuierlichen iterativen Migration viele Probleme, also man beschäftigt sich viel mit Snapshot-Events und so. Auf der anderen Seite, wenn das Modul erst fertig gebaut ist und man dann spät in Produktion geht, hat man natürlich höhere Risiken wegen spätem Feedback.
Johannes: Okay. Mhm. Ja, ja. Hallo. Hallo.
Steffen: Wir versuchen das immer mal wieder, auch mit Teilfunktionen produktiv zu gehen. Teilweise wird es akzeptiert, aber oft merkt man, dass man wirklich den Geschäftsprozess sehr vollständig auch bis ins Detail unterstützen muss, damit das Produkt nützlich ist. Und dann helfen natürlich Kundenreviews oder wir pilotieren mit kleinen Kunden.
Steffen: Auch speziell in der Branche ist, glaube ich, der regulatorische Änderungsdruck. Also zumindest in Deutschland ändert sich jedes Quartal die regulatorischen Vorgaben, Abrechnungsregeln und so weiter. Und bei größeren Modulen muss man dann einfach aufpassen, dass nicht zu viel Kapazität noch in die Anpassung der Bestandssysteme gibt.
Johannes: Mhm. Ja. Mhm.
Steffen: dass das nicht irgendwann Spagat ist, dass man das neue nicht fertig kriegt, weil man kontinuierlich irgendwie Energie in das Vorhandene steckt, das dann für die Neuentwicklung fehlt. Auf der anderen Seite ist die Regulatorik natürlich auch immer wieder Treiber für Neuentwicklung und auch Innovation.
Johannes: Gibt es neben der Regulatorik noch andere Dinge, die euch treiben zu modernisieren, also irgendwelche Trends oder technischen Fortschritte, die ihr folgen müsst, weil eure Softwarearchitektur die zum Beispiel nicht unterstützt, dass ihr dann tatsächlich so eine Art Rearchitecting machen müsst?
Steffen: Grundsätzlich wird der Betrieb von Software und Infrastruktur durch technologische Fortschritte und größere Anforderungen generell anspruchsvoller. Und die Krankenhäuser werden sich zunehmend schwerer tun, das nötige Betriebspersonal zu rekrutieren und auf dem Stand der Technik zu halten. Das ist vielen auch bewusst.
Johannes: Mhm. Mhm. Mhm.
Steffen: Also werden sich Krankenhäuser aus Effizienzgründen auch auf ihr Kerngeschäft konzentrieren wollen und da gehört nun mal der Betrieb von Software und Infrastruktur nicht dazu. Deshalb geben wir davon aus, dass es einen verstärkten Bedarf für Software as a Service oder für Auslagerung von Betrieb geben wird. Und das kann man mit der monolithischen Architektur, wie sie vielfach noch da ist, tatsächlich eher schwer unterstützen.
Steffen: Und ein stetiger Änderungsdruck entsteht auch über die IT-Sicherheit. Die Standards waren vor 15 Jahren einfach andere und da werden dann nicht mehr alle Module den jeweils aktuellen Anforderungen gerecht. Also Cloud gehört zweifellos die Zukunft, auch in der Healthcare-Branche.
Johannes: Und welche Rolle spielt zum Beispiel das Thema Public Cloud bei euch im Gesundheitswesen?
Steffen: In vielen anderen Branchen sind wir leider schon deutlich weiter. Aktuell ist aber ganz viel Veränderung und deutlich mehr Offenheit zu sehen. Bis letztes Jahr war Cloud auch teilweise kaum möglich. Da gab es zum Beispiel noch ein bayerisches Krankenhausgesetz, was gefordert hat, dass die Daten auf dem Betriebsgelände liegen. Das hat sich mittlerweile geändert.
Johannes: Ja. Ja. Ja.
Steffen: Da hat sich auch insgesamt schon viel bewegt. Früher habe ich vor allem wegen Datenschutz dann zusätzlich noch einfach eine große Zögerlichkeit gesehen. Also niemand wollte der Erste sein. Aber das legt sich jetzt immer mehr. Also die Bedenken werden weniger. Es kommen immer mehr Lösungen. Da ist viel Offenheit zu sehen.
Johannes: Ja, super spannend. Wie hilft euch denn dabei, die Softwarearchitekturarbeit oder generell Softwarearchitekten, Softwarearchitektin zu haben, dabei eure Ziele zu erreichen bei der Modernisierung? Mhm. Mhm.
Steffen: Ja, ich hatte es vorhin schon erwähnt, also Domain Driven Design hilft uns zum einen bei der strategischen Planung der ganzen Lösung und vor allem bei der konkreten Modularisierung. Da ist dann erstmal viel Wissensaufbau erforderlich, aber das hilft dann. Dann ganz konkret nutzen wir Architecture Decision Records und ARC42, um Entscheidungen zu dokumentieren.
Johannes: Ja. Ja. Ja. Ja.
Steffen: Vor allem die ADRs helfen uns, bessere Entscheidungen zu treffen, auch die Entscheidung besser in die Breite zu bringen. Durch den Ansatz schaut man sich Entscheidungstreiber und Optionen einfach noch stärker an. Und die Entscheidungen können von mehr Personen gereviewt werden. Und zum Teil stellt man da auch wirklich fest, dass zum Beispiel der letzte vernünftige Moment noch gar nicht gekommen ist und es sinnvoll sein kann, die Entscheidung noch so ein bisschen in die Zukunft zu verlagern.
Johannes: Mhm. Aha.
Steffen: Und die Trennung von Makroarchitektur und Mikroarchitektur hilft uns natürlich, die Entwicklungsteams zu empowern, Architekturentscheidungen möglichst weit unten zu treffen, was auch wieder bei der organisatorischen Skandierung hilft.
Johannes: Ja, super spannend. Du hast gerade schon gesagt, dass ihr da Know-how aufbauen musstet. Wie habt ihr das angestellt? Also wie kann ich mir das vorstellen?
Steffen: Zum einen über Recruiting, also wir sind über die letzten Jahre gewachsen und haben natürlich auch geschaut, dass wir über Recruiting da ein bisschen reinbekommen. Das reicht aber nicht immer, deshalb setzen wir auch auf externe Beratung.
Steffen: Das hilft uns zum einen schnell Technologie oder Methodenwissen in die Organisation zu bekommen, wenn es nötig ist oder wenn es irgendwo fehlt. Zum anderen holen wir uns auch regelmäßig viel Feedback zur Entscheidung, sodass wir nicht in Pfützen treten oder in Löcher fallen, in die andere, in anderen Branchen schon mal gefallen sind.
Johannes: Aha. Aha. Sehr schön.
Johannes: Ja, jetzt haben wir ganz viel über Technik, über Softwarearchitektur, über so die harten Themen in Anführungszeichen gesprochen. Aber ich finde, so eine Software, die hat ja auch immer irgendwie eine menschliche Seite und auch irgendwie die Modernisierung hat so eine menschliche Seite.
Johannes: Wie geht ihr damit um, wenn ihr da jetzt Menschen habt, die vielleicht jahrelang irgendwie gewohnt waren, auf eine gewisse Art und Weise zu entwickeln, und jetzt kommt da jemand rein und sagt, wir machen jetzt hier Post-It-Schlachten mit Event Storming. Wie kann ich mir das vorstellen? Mhm.
Steffen: Der entscheidende Punkt ist vor allem zum einen die Wertschätzung für das Bestehende in Kombination aber auch mit der klaren Kommunikation, das Verhalten sich ändern muss und wie die Rahmenbedingungen für geändertes Verhalten ist.
Steffen: Meine Erfahrung ist, dass die meisten Mitarbeitenden doch ziemlich offen für Neues sind, wenn man ihnen Ziele und Strategie und Handlungsspielraum klar benennen kann. Herausforderend kann es sein, die Mitarbeitenden dazu auch zu bringen, auch fachliche Lösungen neu zu denken.
Johannes: Hm. Hm. Hm.
Steffen: Also meist will man ja bei Greenfield nicht dasselbe Modul in neu haben, sondern der Geschäftsprozess hat sich geändert. Durch UI/UX-Arbeit kann man Prozesse viel besser oder ganz anders unterstützen und so weiter. Da sollte man die Mitarbeitenden dann auch in innovativen Methoden schulen und permanent ermutigen, auch mal neue Wege zu denken und Dinge auszuprobieren.
Johannes: Mhm. Mhm. Mhm.
Steffen: Bewehrt hat sich eine möglichst klare Trennung von Greenfield und Legacy Entwicklung. Beides ist komplex und hat sehr individuelle Herausforderungen. Wenn Teams beides in relevantem Umfang gleichzeitig machen sollen, dann ist die kognitive Last oft zu hoch oder sie verzetteln sich.
Steffen: Ganz wichtig finde ich es, dass man allen Teams und den Mitarbeitenden eine Perspektive gibt. Also man kann nicht alles auf einmal modernisieren. Da ist es klar, dass manche Mitarbeiter schon im Neuen sind und einige Mitarbeitende sich noch mit den Bestandsmodulen beschäftigen. Die meisten Teams finden Neuentwicklung spannender und da ist es dann wichtig, dass alle eine Perspektive haben und sich niemand abgehängt oder in so einer Wartung gefangen fühlt.
Johannes: Ja, ja. Mhm.
Steffen: Und oft lohnt es sich auch das Vorgehensmodell nochmal zu hinterfragen. Also in so monolithischen stark verkoppelten Systemen gibt es einfach enge Grenzen für Teamautonomie.
Steffen: Die Entwickler sind es dann teilweise gar nicht gewöhnt, Verantwortung für Mikroarchitektur zu übernehmen. Und wenn man in so einem Modul das dann Greenfield neu entwickelt, dann sollte man auch explizit nochmal über Verantwortung, Entscheidungsräume und agiles Verständnis reden. Und im Legacy-Kontext ist Scrum by the Book wegen unterschiedlichen Einschränkungen oft nur schwer nutzbar.
Johannes: Mhm. Mhm. Mhm.
Steffen: Und bei der Neuentwicklung kann es dafür umso wertvoller sein. Also sollte man, wenn man in einem Team so was Greenfield beginnt, dann auch nochmal über agile Transformationen nachdenken. Aber das ist ein anderes Thema, das ist ja nicht Fokus, dieses Podcast.
Johannes: Ja, trotzdem, ich finde gerade die menschliche Seite sollte man auch so ein bisschen immer mit betrachtet haben. Steffen, ich bedanke mich recht herzlich für das Gespräch. Ich wünsche dir noch einen schönen Abend und macht’s gut. Bis zum nächsten Mal.
Steffen: Vielen Dank, schönen Abend, macht’s gut.