Renovieren Sie Ihre IT-Landschaft: Der erste Schritt vor der Umstellung auf Agilität

An meinem ersten Tag als Xebia-Mitarbeiter wurde ich sofort in ein sehr interessantes Projekt für einen Kunden aus dem Finanzsektor eingebunden. Im Nachhinein betrachtet hatte es fast alle Zutaten, um ein perfekter Fall für unsere Neue IT Paradigma. Unsere Prüfung der IT-Abteilung brachte schnell einen perfekten Sturm von "Hindernissen" ans Licht, mit denen dieses Unternehmen konfrontiert war: ein deprivierter Technologiestapel, eine silobasierte Wasserfallkultur, die von manuellen Übergaben, bürokratischen Prozessschritten und Elfenbeinturmverhalten dominiert wird, ein durchschnittlicher Release-Zyklus von mehreren Monaten, Kunden, die abwandern, Investoren, die zögern, weiter in das Unternehmen zu investieren, und obendrein eine ängstliche Belegschaft mit niedriger Moral und nur noch wenigen Experten, die willens und in der Lage sind, einen Abwärtstrend umzukehren.

Erschwerend kam hinzu, dass dieser Kunde auch die Hilfe einer Strategieberatungsfirma in Anspruch nahm, die damit beschäftigt war, die Geschäftsstrategie, das Betriebsmodell und die Produkt-/Marktkombinationen zu überarbeiten. An dem Tag, an dem wir mit unserer Prüfung begannen, waren die Strategieberater von gerade dabei, das Slidedeck fertigzustellen, das dem Vorstand vorgelegt werden sollte. Darin wurde eine unvermeidliche Empfehlung ausgesprochen: " beginnen Sie mit der Investition in eine agile Transformation" so schnell wie möglich. Durch die Bildung einer Reihe vollwertiger agiler Teams, die nach Scrum arbeiten, könnte in einer Reihe effektiver Iterationen (Sprints) ein Renovierungsfahrplan umgesetzt und dieses Unternehmen wieder erfolgreich gemacht werden: Die Kunden würden Lizenzen für das überarbeitete Produkt kaufen, die bestehenden Kunden würden bleiben, und nach dem Hausputz wären erhebliche Kostensenkungen möglich.

"Ich sage es Ihnen nur ungern, aber so funktioniert das nicht" , war mehr oder weniger meine Botschaft an den CIO.

In den folgenden Wochen verbrachten wir die meiste Zeit damit, diese Behauptung mit so vielen Beweisen zu untermauern, wie wir finden konnten, und alternative Szenarien auszuarbeiten. Es hat uns einige Mühe gekostet, zu erklären, warum die Umstellung auf agile Methoden nicht nur eine zu einfache Lösung für den Status quo war, sondern auch ein gefährlicher Schritt, den wir jetzt gehen sollten. Schließlich hatten wir nach einigen Tagen der Befragung von Mitarbeitern und der Sichtung von Quellcode und Dokumentation herausgefunden, dass der Technologiestapel im Grunde ein einziger unübersichtlicher Monolith war, gegen den Foote und Yoders großer Schlammball wie ein Spielzeug aussehen würde. Agile Teams zu bilden und von ihnen zu erwarten, dass sie Teile dieses Spagetthi-Balls unabhängig voneinander refaktorisieren, ist einfach falsch. Mindestens zwei zusätzliche Investitionen waren gerechtfertigt:

• Es musste eine neue funktionale und technische Architektur geschaffen werden, um Dienste/Funktionen zu definieren, die einen gewissen Geschäftswert darstellen oder generieren können.
• Es musste eine Funktion zur kontinuierlichen Bereitstellung implementiert werden, die es den Teams ermöglicht, neue Versionen ihrer Software unabhängig und viel häufiger (täglich statt monatlich) zu testen, bereitzustellen und zu veröffentlichen.

Die Architektur der IT-Landschaft dieser Organisation war leider ein großes Problem für den CIO und den Rest des Managementteams. Die dem Vorstand vorgelegte Roadmap für die Renovierung enthielt zwar ein beträchtliches Budget für das Coaching agiler Teams für etwa ein halbes Jahr, um das angestrebte agile Unternehmen zu schaffen, aber es wurde wenig bis gar kein Budget für die Überholung der komplexen technischen Landschaft bereitgestellt, die der Showstopper des ganzen Projekts sein sollte. Als Xebia weigerten wir uns natürlich, nur ein paar unserer agilen Coaches zu schicken und boten ein Szenario an, in dem das Coaching bei der Testautomatisierung, die Entwicklung einer Microservices-Architektur und die Erstellung einer Continuous-Delivery-Pipeline zentrale Bestandteile waren. Die Entscheidung über unseren alternativen Vorschlagsteht noch aus. Die Zeit wird zeigen, welche Möglichkeiten dieses Unternehmen hat, um die enormen technischen Schulden zu bekämpfen, die sich in den letzten Jahren angehäuft haben.

Für mich symbolisiert diese Geschichte auch die Bedeutung, die "Architektur" bei vielen unserer Kunden immer noch hat, wenn es darum geht, schlankere und gemeinere Unternehmen zu schaffen. Und das ist interessant, denn unsere Kunden scheinen diese Disziplin entweder ein wenig vergessen zu haben oder sie haben die Nase voll von den Versprechungen, die Architekten in den letzten Jahren nicht eingehalten haben. Architektur ist nicht so sexy wie DevOps oder Continuous Delivery, und CIOs sind viel eher bereit, in agile Transformationen zu investieren als in etwas, das sie an SOA erinnert. Aber die Wahrheit ist, dass wir in vielen Unternehmen in den letzten zehn Jahren nicht viel gelernt haben, wenn es um die Schaffung solider IT-Architekturlandschaften geht. . Und das wird diese Unternehmen in Zeiten, in denen die IT schneller, flexibler und zuverlässiger denn je werden soll, teuer zu stehen kommen. Lassen Sie uns also bitte aufhören, aus großen Schlammbällen Elefanten im Raum zu machen, und beginnen Sie damit, einen Teil der Komplexität und des Legacy-Dschungels zu beseitigen, dem wir begegnen.