DDD, DevOps und Unternehmensarchitektur
Redaktion: Domain-driven, DevOps und Unternehmensarchitektur – das sind die drei Schlüsselworte deines Talks auf der JAX 2020. Welchen Zusammenhang gibt es aus deiner Sicht zwischen den drei Disziplinen ?
DDD und Unternehmens- architektur zeigen erst dann ihren Effekt, wenn die IT-Organisation tatsächlich etwas Nützliches an IT-Anwender abliefert.
Bernd Rederlechner: In größeren Unternehmen gibt es klassischerweise Unternehmensarchitekten, die sich als Brücke zwischen IT und Business sehen. Doch meiner Erfahrung nach fokussieren sie stark auf Standardisierung und die Auswahl von Produkten – um Einsparungen mittels eigener Plattformen und Veränderung von Infrastruktur zu erzielen.
Wegen dem fehlenden Bezug zur Software-Entwicklung hat das wohl zu einer Wahrnehmung als “Elfenbeinturm-Architekten” geführt. Wenn diese nun die strategischen Aspekte von DDD anwenden, verschiebt sich ihr Fokus hin zu den logischen, wertliefernden Strukturen der IT. Plötzlich geht es darum, mittels sinnvoller Leitlinien wie Upstream-Downstream blockierte Teams arbeitsfähig zu machen.
Umgekehrt sollte man nicht unterschätzen, dass Unternehmensarchitekten viel näher am Geschäft dran sind als IT-Techniker oder sogar Fachseiten. Sie haben Methoden wie “Capability Mapping” oder “Managed Evolution”, die DDD gut um Geschäftsaspekte ergänzen.
DDD und Unternehmensarchitektur zeigen aber erst dann ihren Effekt, wenn die IT-Organisation tatsächlich etwas Nützliches an IT-Anwender abliefert. Was nutzen die schönsten Architekturen, wenn sie erst in ferner Zukunft geerdet werden? Deshalb benötigen alle, die etwas mit IT erreichen wollen, mehr als nur Halbwissen darüber, wie man Umbauarbeiten an einer Unternehmenslandschaft so aufteilt, dass sie früh und trotzdem qualitativ hochwertig in Produktion gehen.
Taktisches DDD liefert da sicher einen kleinen Beitrag, aber DevOps bietet viel mehr. DevOps erzwingt schnelle Feedback-Zyklen und fügt der Mischung den nötigen, frühen Schuss Realität hinzu, um eine effektive Produkt- bzw. Systemlandschaft für den Unternehmenserfolg zu bauen.
Redaktion: Und was hat DevOps mit Bounded Contexts zu tun?
Bernd Rederlechner: Conways Gesetz. Klingt komisch, ergibt aber schon Sinn: Conways Gesetz sagt, dass (Unternehmens-)Software nahezu unweigerlich die Kommunikationsstrukturen der Organisation widerspiegelt.
Aus dieser Erkenntnis ist im DevOps das “umgekehrte Conway-Manöver” entstanden: Man organisiert die Teams anhand der gewählten Architektur, damit Kommunikationspfade und gewählte Systemstrukturen zusammenpassen. Ziel hierbei ist, dass die entstehenden Teams so unabhängig wie möglich von anderen Parteien agieren und unabhängige (Micro-)Services liefern können.
Aber wie sieht eine zu diesem Vorgehen passende Architektur aus? Sicherlich kein Wald von Miniatur-Services, die sich wild gegenseitig aufrufen. Da fehlt die Entkopplung.
Bounded Contexts machen deshalb den Unterschied: Sie grenzen Bereiche mit einer unterschiedlichen Sicht auf die Geschäftswelt gegeneinander ab. Innerhalb des Kontexts arbeiten alle mit einem gemeinsamen Modell, also einem gemeinsamen Verständnis von der Realität: Ein Team, dass sich mit dem Erzeugen von Rechnungen beschäftigt grenzt sich beispielsweise durch seine Weltsicht von einem Team ab, das Online-Werbung produziert. Die Vereinigung vieler solcher schnell liefernder Teams mit ihren getrennten Kontexten ist die Basis für eine hochperformante Lieferorganisation nach DevOps.
Das wirkt so stark vereinfacht wie aus einem Werbeprospekt für Manager. Im Vortrag wird es unterhaltsamer und konkreter – versprochen.
Software-Architekten als Wertbeiträger
Redaktion: IT-Architektur ist allgemein ein breit gefächertes Gebiet – ebenso unterschiedlich ist das Rollenverständnis unter IT-Architekten. Worin siehst du persönlich in deiner Position als IT-Architekt deine Hauptaufgabe? Was ist dir besonders wichtig?
Für mich hat immer dazugehört, möglichst gute IT-Strukturen dem Chaos entgegenzustellen.
Bernd Rederlechner: Tatsächlich hatte ich das Glück (oder Pech?), in allen drei Bereichen arbeiten zu dürfen. Dabei hat für mich immer dazugehört, möglichst gute IT-Strukturen dem Chaos entgegenzustellen und technische Schulden als Zukunftshypothek wo immer möglich zu vermeiden. Die Welt rundherum erwartet das implizit von einem. Man kann damit sicher seine gesamte Zeit verbringen und sich von den realen Liefer-, Produktions- und Kundenherausforderungen fernhalten.
Aber irgendwann wird der IT-Architekt feststellen, dass er so als “Verkomplizierer” von den Geschäftsbereichen wahrgenommen wird, nicht als “Wertbeiträger”. Respekt auf Geschäftsebene gewinnt der, der mit den Methoden z.B. aus DDD, DevOps oder Unternehmensarchitektur Lieferblockaden auflöst und dafür sorgt, dass Verbesserungen durch IT auch tatsächlich wirksam werden.
Mit kleinen Erfolgen und einem guten persönlichen Image ergibt sich oft irgendwann die Möglichkeit, die neuen Methoden weiter ins Unternehmen zu tragen. Zumindest bleibt aber immer die Befriedigung, jemandem tatsächlich mittels Architektur geholfen zu haben.
Redaktion: Welchen Architektur-Trend findest du momentan besonders spannend?
Bernd Rederlechner: Ich feiere natürlich das Revival von DDD. Vor allem zwei Bereiche haben meine besondere Aufmerksamkeit: Zum einem sehe ich die Rückkehr von Modellen, die sowohl Entwickler als auch Nicht-ITler lesen können. Mit graphischen Notationen sind wir da ja schon mal grandios gescheitert. Die Idee, den Code zum gemeinsamen Modell für IT und Business zu machen, halte ich für pragmatisch und vielversprechend – wenn die Entwickler mitmachen…
Zum anderen wird Event Sourcing die Architektur von großen Anwendungen und Unternehmenslandschaften fundamental verändern. Beim Event Sourcing veröffentlicht ein Bounded Context geschäftliche Ereignisse für die Nutzug durch die Allgemeinheit. Das fördert nicht nur eine Kultur der Offenheit und des Teilens in Organisationen und sorgt für Entkopplung. Konsequent zu Ende gedacht stehen Streaming Event-Architekturen: Statt nur den aktuellen Zustand z.B. eines Vertrags oder Kunden zu verwalten, bewahren so designte Systeme und Landschaften alle geschäftlichen Veränderungen als Ereignisse auf. Zustand wird nur noch aus den Ereignissen für jeden gewünschten Zeitpunkt rekonstruiert. Sie ermöglichen das Beobachten von Verhalten und öffnen ganz neue Bereiche, wo IT das Business unterstützen kann.
Redaktion: Und welches Thema im Bereich der Software-Architektur ist deiner Meinung nach im aktuellen Diskurs etwas unterbelichtet?
Bernd Rederlechner: Ich sehe immer noch, dass Entwickler und Architekten Technik um der Technik willen bauen. Das ist zwar nicht falsch, aber immer schwerer geschäftlich vertretbar. Warum benötige ich beispielsweise meine eigene Installation eines Streaming-Clusters, wenn ich einen auf Knopfdruck in der Cloud schneller und unterm Strich auch günstiger bekommen kann? Überall dort, wo man eine neue Technologie so nutzt wie alle anderen, wird man in Zukunft immer mehr gezwungen sein, fertige Services einzusetzen.
Verbündet Euch mit den Architekten und Entwicklern aus anderen Disziplinen und Fachbereichen.
Budget zum Ausprobieren cooler Sachen wird dorthin fließen, wo Eigenentwicklung mein Unternehmen am Markt differenziert. Wie also arbeiten IT-Architekten, die konsequent Teile eines Systems durch PaaS/SaaS-Services ersetzen, sobald sie Mainstream geworden sind? Wie müssen Architekturen gestaltet sein, damit sie Sollbruchstellen enthalten – nicht ganz ohne Entwicklungsaufwand, aber wenigstens für einen schmerzfreien Austausch? Wie komme ich aus einer Legacy-Welt dorthin?
Redaktion: Was ist die Kernbotschaft deiner Session, die jeder Besucher mit nach Hause nehmen sollte?
Bernd Rederlechner: DDD als lokale Optimierung innerhalb eines Projektes oder Produktes verliert viel von seiner Schlagkraft. Verbündet Euch mit den Architekten und Entwicklern aus anderen Disziplinen und Fachbereichen, kombiniert Eure Stärken und liefert mutig viele kleine Veränderungen hin zu der IT-Welt, in der Ihr gemeinsam in Zukunft leben wollt.
Redaktion: Vielen Dank für dieses Interview!
Die Fragen stellte Hartmut Schlosser.
