EAM#3: Integrationsschuld: Warum nicht das neue System das Problem ist

Architektur entscheidet über Komplexität, über Kosten, über Steuerbarkeit.

Ich bin David Hohl und heiße dich herzlich willkommen bei Enterprise Architektur wirkt,

der Podcast zu ERM.

Servus, grüß dich und herzlich willkommen zu einer neuen Folge.

Heute starten wir mal mit einer kleinen Serie.

Jede Woche eine neue technische Schuld.

Dabei schauen wir uns diese Schuld genau an, wie sie auftreten, wie du sie erkennst und wie du damit auch umgehst.

Und wir beginnen dort, wo sie fast in jedem Unternehmen am größten sind.

In der Integration.

Und Integrationen haben wir ja in jedem System, sonst brauchen wir keine Architektur.

Vielleicht kennst du das ja.

Ein neues System wird eingeführt.

Es ist modern, es ist schnell, es ist in der Cloud.

Da kann es nur besser werden.

Und trotzdem kommt die Information, die wir eigentlich brauchen,

im Zielsystem nicht rechtzeitig an.

Beispiel in einem Commerce-System.

Bestellungen hängen irgendwo.

Die Reports stimmen nicht oder überhaupt nicht überein.

Und die Daten sind auch noch inkonsistent.

Das heißt ja, das neue System performt nicht richtig.

Das heißt, man geht sofort an den Hersteller, Implementator oder Dienstleister, was ist da los?

Aber tut es das wirklich?

Oder schauen wir nur auf das Symptom.

Das Symptom ist sichtbar und die technische Schuld dahinter oft nicht.

Das ist wie bei einer Grippe.

Wir husten und husten und dann nachher denken wir, ich habe was im Hals stecken und dabei habe ich was in der Lunge.

Und das ist nicht gut.

Wenn wir uns dieses Symptom mal näher anschauen.

Vielleicht kennst du das ja.

Ich habe jetzt ein neues System eingeführt und der Dienstleister behauptet,

es ist modern, es ist schnell, es wird einfach pfeifen, weil es in der Cloud ist.

Und trotzdem kommen einfach die ganzen Informationen und Daten

im eigentlichen Zielsystem nicht rechtzeitig an.

Oder es ist einfach zu langsam.

Wenn wir das Ganze ein bisschen aufhängen auf ein, vielleicht auf ein Commerce-System, dann lass uns die Bestellung mal hernehmen.

Die Bestellungen hängen irgendwo und die Reports in der letzten Instanz stimmen einfach nicht überein oder noch viel schlimmer, die Daten sind einfach nicht inkonsistent.

Und dann heißt das, das neue System, was da implementiert worden ist, performt nicht richtig.

Aber tut es das wirklich? Ist wirklich das neue System gleich der Übeltäter?

Oder sehen wir hier, wie beim Husten, nur das Symptom?

Denn das Symptom ist sichtbar.

Die Schuld dahinter leider oft nicht.

Und das ist der große Hund, der hier begraben ist.

Und den heben wir jetzt mal aus.

Wohin steht diese Schuld wirklich?

Oft betrachten wir leider nur Start- und Zielsystem.

Also da in unserem Fall jetzt, wo die Bestellung entsteht und wo sie ankommt.

Aber dazwischen liegt oft eine lange Strecke.

Und die ist leider in der Regel gewachsen.

Man redet dann immer von einer sogenannten Integrationsstrecke.

Und genau dort entsteht diese Art von technische Schuld.

Nicht im neuen System, sondern zwischen den Systemen.

Und das ist kein theoretisches Konstrukt.

Ich erzähle dir mal ein Praktisbeispiel aus meiner Vergangenheit.

Ich war mal in einem Projekt, in dem wir ein neues Commentsystem eingeführt haben.

Supergeil, super modern, geile Infrastruktur, Microservices, Microfrontends,

der ganze Hackey-Passwort-Gedöns, der Grunde ist abgehoben.

Zusätzlich haben wir noch eine Event-Reven-Architecture eingeführt,

von der ich eigentlich nicht so überzeugt war, aber am Schluss hat sie ganz schön guten Speed drauf gehabt.

Somit architektonisch war es eigentlich ein sehr sauber und jetzt aus Gründen, die wir bewusst eingegangen sind.

Und trotzdem haben wir das Problem gehabt, dass die Bestellungen einfach verzögert im ERP ankamen.

Die Rechnungen wurden erst Stunden später erzeugt und wir haben uns immer gefragt, woran liegt das?

Und was noch schlimmer war, ist, dass die Reports, die für diese Informationen, was aus einer Bestellung gezogen werden, einfach nicht übereinstimmt haben.

Also die Zahlen waren komplett widersprüchlich.

Und die erste Reaktion war damals, ich kann mich noch gut erinnern, das neue System ist instabil.

Es funktioniert nicht.

Also was haben wir gemacht?

Wir haben genau das Gegenteil gemacht.

Wir haben mal nicht das neue System optimiert, weil wir gewusst haben, das kann daran nicht liegen.

Das haben wir genauso in 100 anderen Kunden implementiert.

Das Ding pfeift.

Es ist unmöglich, an der Stelle zu suchen.

Macht auch keinen Sinn.

Wir haben nämlich woanders angefangen.

Und ich kann mich noch erinnern,

wie schwierig eigentlich diese Suche war.

Denn wir haben zuerst da im Zielsystem nachgeschaut.

Und das war eine SAP-Lösung,

die war nicht gerade die neueste, aber es ist egal.

Die war trotzdem schnell und stabil.

Das war eine On-Premise-Lösung.

Ja, hat aber überhaupt keine Null-Last gehabt.

Wir haben das System, also an dem kann es nicht scheitern.

Und somit haben wir uns eigentlich dann nachher die Strecke angeschaut.

Und zwar Ende zu Ende.

Und plötzlich wurde genau das sichtbar, was vorher niemand gesehen hat.

Denn was ist eigentlich wirklich passiert dahinter?

Die Bestellungen entstanden in unserem Commons-System, das ist sehr klar,

wurde dann nachher über ein Event an eine Mittelwehr gesendet,

oder beziehungsweise von dort abgeholt, andersrum.

Und dort hat man halt in den XML transformiert.

Und ich kann mich erinnern, diese Mittelwert, die hat dann nachher etwas Eigenartiges gemacht.

Weil sie schon etwas älter war, hat sie im Endeffekt einen normalen Patchjob drinnen gehabt.

Und diese Patchjob ist jetzt nicht in der Nacht gelaufen, was man jetzt vielleicht glauben könnte,

sondern er hat einfach alle 15 Minuten gewartet, bevor es von einem zentralen ISB einfach übermittelt worden ist.

Dort wurde es nochmal angereichert durch irgendwelche Informationen.

Ich habe keine Ahnung mehr warum, aber das Ding wurde erst dann nachher an das ERP übergeben.

Und zusätzlich existierte noch, das war auch noch sehr spannend, ein manueller Korrekturschritt.

Und was haben die gemacht?

Die haben Excel exportiert, das sind Excel dann verändert und danach wieder zurück importiert.

Weil sonst hätte man relativ schnell feststellen können, dass nach 15 Minuten ein Zyklus,

Das heißt, es muss irgendwie automatisiert sein, aber das war oft wirklich mal zwei, drei Stunden oder manchmal einen Tag dazwischen und das erklärt natürlich diese manuelle Überarbeitung dazwischen.

Und es war auch nicht bei jeder Bestellung so.

Was wir danach ja auch noch verstanden haben, dass diese manuellen Überarbeitungen, abgesehen, dass das halt zu gewissen Zeiträumen nur passiert ist, wenn die Leute gearbeitet haben,

Nur bei gewissen Bestellungen passiert ist, die zum Beispiel, wenn es B2B-Bestellungen waren, dann hat man nochmal geschaut, ob der Kunde vielleicht noch ins Konto draufkriegt und dann hat man diese Payment nochmal neu angestoßen oder der Kunde hat eine Stornierung durchgeführt oder die Bestellung verändert.

Das ist komplett wahnsinnig.

Am Ende hatten wir wirklich so sieben Stationen, wo das Ding durchgegangen ist, dann diverseste Anreichungen von Transformationen und dann nachher halt wirklich organische Leute, also Menschen, die danach noch die Verantwortlichkeit gehabt haben, dass diese eine Bestellung am Ende wirklich im ERP landet.

Aber es hat keiner eine Ende-zu-Ende-Verantwortung gehabt.

Und das sehe ich leider sehr häufig auch in aktuellen und vergangenen Projekten,

dass eine gesamte Systemarchitektursicht oft nicht vorhanden ist.

Und eine Integrationsarchitektur, das macht keiner.

Ich habe keine Ahnung warum, aber ich kenne wenige Unternehmen,

die ein vollständiges Integrationsbild haben über ihre Architektur.

Somit war das Problem schon über die letzten 15, 20 Jahre gewachsen.

Das Symptom war jetzt sichtbar und die Schuld nicht.

Was ist eigentlich so eine Integrationsschuld?

Also Integrationsschuld entsteht nicht, weil wir REST oder GraphQL oder irgendwelche Events verwenden.

Sie entstehen, wenn Integrationen historisch wachsen oder Transformationslogiken verteilt werden.

Das heißt, dass man halt verschiedene Wege nach oben führt und danach, wenn es nochmal irgendwo zusammen geschustert.

Noch viel häufiger findet man einfach, die Verantwortlichkeiten sind nicht klar und definiert.

Die Datenführerschaft oder Datenhoheiten sind einfach nicht definiert.

Also Datenentities sind nicht klar zugeordnet.

Und was immer die Regel ist, eine Ende-zu-Ende-Strecke, die kennt keiner.

Niemand weiß, was das wirklich ist.

Die technische Schuld heißt hier also, fehlende strukturelle Transparenz über eine gewisse Datenbewegung.

Und das ist kein Integrationsproblem wohlgemerkt.

Also die Integration als solches nicht der Übeltäter.

Das ist ein Strukturproblem und somit ein Architekturthema.

Wie erkenne ich so eine Integration schuld?

Tja, das ist oft nicht so einfach, um ehrlich zu sein.

Denn sie ist nicht technisch.

Wenn sie technisch wäre, könnte ich sie wahrscheinlich über verschiedene Agents,

auch heutzutage gibt es da sehr coole Integrationsagents,

mit denen ich das eigentlich durchforsten lassen kann,

analysieren oder halt, ich schaue auf eine Systemlandschaft,

gerade wenn ich ein Integrationsasset habe,

oder schaue mir wirklich einmal diese Ende-zu-Ende-Strecke in Ruhe an.

Sie ist aber strukturell.

Und was vielleicht dir hilft, auch an der Stelle,

ich habe mir probiert einmal diese vier Hauptfragen hier zu notieren,

die ich mir selbst einfach auch stelle.

Wie viele Systeme berührt eigentlich dieses eigene zentrale Datenobjekt?

Also du machst im Endeffekt ein DFT, ein Data Flow Diagram und schaust dir mal wirklich genau an,

wie dieses eine Datenobjekt über deine Systemarchitektur durchschießt und wo es im Endeffekt gespeichert wird,

wo es verarbeitet wird oder beziehungsweise angereichert wird.

Zweite Frage, gibt es für jede Integration einen klaren Owner?

Und wenn nicht, dann weißt du schon, was du erst da machen solltest.

Dritte Frage, wann wurde diese Schnittstelle zuletzt architektonisch bewertet?

Also, Methodi-Level, da kommen wir vielleicht in der nächsten Folge dazu,

bezüglich Reifegradbewertung von Schnittstellen, wie ich das tue,

welche Fragen ich da stelle und welche Bewertungssysteme hier relativ gut passen.

Dennoch kann ich das schnell auf den Punkt bringen, wie alt ist das Teil,

Wie viele Daten laufen dort durch, wie hoch ist Skalierung etc.

Und kann ich in 15 Minuten erklären, wie dieses eine Datenobjekt Ende zu Ende fließt.

Also über dieses DFT kann man das natürlich dann machen, aber wenn man sowas nicht hat,

fragt man natürlich, erklären wir mal, wie die Bestellung entsteht und wo sie am Schluss landet.

Und über welche Systeme sie durchfällt.

Wenn nur eine dieser Antworten fehlen, dann hast du genau das.

Du hast die Integrationsschuld vorhanden und sie ist da.

Und sie wirkt bereits negativ.

Integrationsschuld wirkt leider nicht linear.

Also du wirst das eher andersrum erleben.

Denn wenn ein Datenobjekt zwei Systeme anfängt zu berühren oder halt ankommt,

dann haben wir eine Koppelung.

Das heißt, die Systeme werden größer.

Wenn es ein drittes System entsteht, dann haben wir noch eine höhere Abhängigkeit.

Mit jedem zusätzlichen System steigt leider danach etwas noch viel Wichtigeres.

Der ganze Testaufwand, der Abstimmungsaufwand dahinter, die gesamte Releases und was noch, die Risikoeinschätzung.

Somit haben wir einen sehr hohen Multiplikator und das solltest du dir genau danach anschauen und hier auch mal auf den Tisch schauen, dass man hier dagegen lenkt.

Und genau deshalb wird die Integrationsschuld gerade beim Plattformwechsel sehr teuer.

Bei einem klassischen Wechsel kalkulieren viele eigentlich nur, wie viele Lizenzen brauche ich denn dafür, was kostet mir das in der Implementierung, was kostet mir die Migration und vielleicht noch, welche Weitungssysteme brauche ich denn rum herum.

Was aber oft fehlt, ist eigentlich genau diese Bereinigung von diesen historischen Integrationslogiken.

Und leider sind gerade bei vielen Unternehmen gibt es keine ADRs, also Architekt-Scientistischen-Records,

wo ich genau nachschauen kann, warum eine Integration stattgefunden hat

oder warum diese Schnittstelle so ausschaut, wie sie ausschaut.

Und auch in welcher Frequenz kommt sie an dem System an und was macht das dann nach am Ende des Tages.

Was man auch oft nicht hat, ist eine klassische Datenharmonisierung, also Minimierung von Informationen oder vielleicht sogar Ausschließung von Daten. Ich habe sehr hohe Kopplungsauflösungen und ich muss natürlich alles immer wieder testen und gerade mit diesen Abhängigkeiten wird das ein teurerer Spaß.

Und das ist der wahre Preis. Also nicht die neue Plattform ist oft der Übeltäter, kann es natürlich auch sein, ja, keine Frage, aber in der Regel nicht, sondern diese gewachsene Struktur und Architektur, die man sich angehäuft.

Wirtschaftlich gesehen haben wir dann nachher natürlich noch zusätzliche Themen, die da drinnen fallen.

Einerseits sehr erhöhter Änderungsaufwand klarerweise, verlängerter Time-to-Market,

also das zieht sich auf jeden Fall in die Länge, weil ich sehr viel anpassen muss oder angreifen muss.

Natürlich muss ich dann noch mehr testen und ich habe viel höhere Testzyklen dahinter

und ich reduziere natürlich die strategische Beweglichkeit im Unternehmen

und muss im Endeffekt sehr starrer unterwegs sein.

Und gerade wenn man ein neues Geschäftsmodell einführen möchte, also wenn man zum Beispiel auf andere Märkte hinsteuert, dann muss ich durch jede diese Kopplung hindurch.

Architektur entscheidet hier direkt über die Wirtschaftlichkeit.

Und das sollte jeder wirklich verdammt ernst nehmen, weil nur hier wirkt die Enterprise Architektur so richtig, nur nicht operativ, sondern strukturell.

Wie gehe ich jetzt damit um?

Nicht mit einem Großprogramm.

Also fang nicht an, alle Integrationen in Frage zu stellen.

Das macht auf keinen Fall Sinn.

Sondern mit Sichtbarkeit.

Man probiert das in drei Schritten aufzuzeigen.

Erster Schritt wäre die Integrationskarte erschellen.

Also welche Systeme habe ich da?

Welche Datenobjekte?

Die Laufwege dahinter?

Die Technologie hat vielleicht noch...

Wer ist verantwortlich?

Ganz wichtig.

Und dann der Maturity-Level, also die Reifegradbewertung.

Das ist zwar nicht ganz perfekt, aber streut schon mal gute Transparenz.

Zweiter Schritt, die Schuld markieren.

Das ist nicht mit einem Leuchtstift, sondern wir markieren die Schuld an der Stelle, dass es ein manueller Eingriff ist.

Oder die Transformationslogik ist außerhalb der Domäne und es kommt woanders.

oder noch viel häufiger, aber auch unklare Datenhoheiten,

veraltete Technologien oder halt auch Mehrfachkopplung.

Das sind also Beispiele, mit denen du halt die Schuld dann richtig markieren kannst,

klassifizieren kannst und dann nachher auch in deinem Basissystem hinterlegen kannst

und dann mit so halt riesigen Grad bei Neueinführungen

oder Veränderungen von bestehenden Systemen, die davon betroffen sind,

dann auch herauskristallisieren kannst.

Und dritter Schritt ist das Klassifizieren.

Also nicht jede Schuld muss sofort getilgt werden, klarerweise, aber das sollte bewusst eingeordnet sein.

Also tilgen, stabilisieren, bewusst tolerieren.

Das ist dann Steuerung.

Letzter großer Punkt, strategischer Architekturimpuls.

Enterprise-Architektur wirkt hier nicht durch Tool-Debatten, wie du merkst.

Sie wirkt durch Klarheit und Transparenz.

Drei strukturelle Prinzipien, die man hier immer verfolgen kann.

Erstens, dass du halt klare Datenführerschaften oder Daten-Ownership definierst,

also wer ist System of Record als Beispiel.

Zweitens, Minimierung unnötiger Transformationen,

also jede Transformation ist mit einem potenziellen Bruch verbunden,

das muss minimiert werden.

Und drittens, Transparenz über Kopplungsgrad,

das heißt, wie stark ist ein System wirklich vernetzt,

Also wie viele Integrationen habe ich denn da eigentlich und brauche ich denn eigentlich so viel?

Aber wenn ich das weiß, dann kann ich die Integrationsschuld bewusst eingehen.

Wenn ich es nicht weiß, zahle ich später nur noch die Zinsen.

Und das wissen wir alle, wie teuer das wird.

Fazit.

Integrationsschuld entsteht also leise, über Jahre hinweg.

Sie ist selten bewusst entschieden, das kommt oft drauf, weil es gerade bei Integrationen sehr viele Schnittstellen gibt, aber sie wirkt halt jeden Tag.

Und das Symptom ist sichtbar, dass etwas vielleicht langsam ist und nicht ankommt und die Schuld natürlich nicht.

Und genau deshalb braucht es wirklich Architektur und nicht als Dokumentation, sondern als wirtschaftliches Steuerungselement.

In der nächsten Folge schauen wir aber auf eine andere Form von technischer Schuld.

die strukturelle Schulden im Datenmodell.

Und das wird richtig spannend, das kann ich dir versprechen.

Servus und Baba und bis auf bald.