Architektur, die liefert: Modernisieren mit Doppelmandat aus Architekt und PO

Modernisierungen scheitern seltener an der Technik als an einer Lücke: der zwischen Architekturvision und Lieferung. Wer Architektur lediglich empfiehlt, statt sie bis in die Umsetzung zu verantworten, errichtet meist die nächste Schicht der Architekturhistorie. Wie sich diese Lücke schließen lässt, zeigt dieser Erfahrungsbericht aus der Modernisierung einer großen, gewachsenen Plattform.

In großen Softwaresystemen scheitert die Lieferung selten allein an der Technik. Was fehlt, ist Ownership: die Möglichkeit, Entscheidungen zu treffen und so durchzusetzen, dass sie sich in lieferbare Funktionalität übersetzen.

In klassischen Setups arbeiten Frontend, Backend, QA und Operations als technische Silos, häufig vollständig entkoppelt von der Fachabteilung als weiterem Silo. Jedes Silo liefert seinen Teil und verteidigt seinen Schnitt. Features durchlaufen eine Kette von Übergaben, und mit jeder dieser Übergaben sinkt die Verantwortung für das Ergebnis. Am Ende ist niemand vollumfänglich für die Umsetzung einer Fachlichkeit zuständig, sondern jeder nur für den eigenen Beitrag.

Was daraus über die Jahre entsteht, ist keine stringente fachliche und technische Architektur, sondern eine Architekturhistorie: die Summe vieler Einzelentscheidungen unter Zeitdruck, organisatorischer Brüche und Lieferantenwechsel. Jede dieser Entscheidungen war für sich genommen vernünftig. In Summe haben sie eine Plattform hervorgebracht, die niemand mehr im Ganzen entworfen hat. Sie ist über die Zeit so geworden.

Ich nenne diesen Zustand Architecture by Accident und meine den Begriff etwas anders, als er häufig verwendet wird. Es geht nicht um ad hoc zusammengesetzte, undokumentierte Architektur; die einzelnen Entscheidungen waren meist bewusst, begründet und handwerklich sauber. Das Subtilere ist der Verlust einer durchgehenden Intention über die Zeit. Niemand hat schlecht entschieden, und doch hat niemand das Ganze entworfen. Die Verantwortungsbereiche wurden nie klar abgegrenzt; über die Zeit hat sich alles ergeben und ineinander verwoben.

Hier sitzt der eigentliche Gegner jeder Modernisierung: nicht der alte Code, nicht das veraltete Framework, sondern die fehlende ganzheitliche Ownership für die Umsetzung einer Fachlichkeit.

Wenn fehlende Ownership und die Architekturhistorie die beiden Hauptprobleme sind, liegt eine radikale Reaktion nahe: alles wegwerfen und neu bauen, vom Datenbankschema bis zum Org-Chart. Ein Big-Bang-Rewrite reißt jedoch viele Baustellen gleichzeitig auf und verengt sich am Ende doch häufig auf die technische Dimension: Code, Laufzeitumgebungen, Frameworks. Daneben entsteht ein neues Org-Chart, und die alten Übergaben werden in moderner Form wieder aufgebaut. Die Geschichte dieser Versuche ist gut dokumentiert; sie endet selten gut.

Wir haben uns für einen anderen Weg entschieden: nicht alles gleichzeitig umbauen, sondern zunächst einen wichtigen Baustein herauslösen, ihn verstehen und gezielt neu aufsetzen. Im konkreten Fall war das der Kaufprozess vom Warenkorb bis zur Bestellabgabe. „Neu” meint dabei nicht nur neue technische Werkzeuge, sondern eine Architekturvision, die Technik, Fachlichkeit und Organisation zusammen denkt. Das Legacy-System läuft zunächst weiter, während ein klar abgegrenzter Teil als neues System entsteht und schrittweise die fachliche Verantwortung übernimmt (das Strangler-Fig-Pattern nach Martin Fowler). Geschnitten haben wir nicht entlang des bestehenden Org-Charts, sondern entlang des fachlichen Flusses aus Kundensicht.

Die schrittweise Ablösung verschafft Zeit für zwei Dinge, die nicht recht zusammenpassen wollen: die Architekturhistorie wertzuschätzen und zugleich mit ihr zu brechen. Wertschätzen heißt, die Entscheidungslogik der Historie zu verstehen: Jede merkwürdige Brücke und jede schräg klingende fachliche Anforderung hatte ihren Grund; wer die Gegebenheiten der IST-Plattform ignoriert, wiederholt deren Fehler im Neubau mit moderneren Werkzeugen. Brechen heißt umgekehrt, sich von der bestehenden Topologie nicht diktieren zu lassen, wie das Neue aussehen muss. Wer nur wertschätzt, modernisiert nicht; wer nur bricht, verliert das Wissen, das in der Historie eingefroren liegt. Diesen Doppelschritt halte ich für den unterschätzten Kernakt jeder Modernisierung.

Ein Beispiel aus dem Projekt macht beides greifbar: die Berechnung von Versand- und Lieferkosten samt Verfügbarkeits- und Lieferterminlogik und eigenen Sonderfällen je Teilsortiment. Die Verantwortung dafür lag über mehrere Silos verteilt; es gab nicht die eine Person, die die Herleitung vollständig erklären konnte, und einzelne Herleitungen widersprachen sich. So sieht Legacy aus. Und doch steckt in jeder dieser Herleitungen eine fachliche Wahrheit, ohne die sich nicht bestimmen lässt, was das Neue können muss. So weit das Wertschätzen. Der Bruch besteht darin, dass diese Funktionalität, gemeinsam mit vielen weiteren Bestandteilen des Kaufprozesses, heute ungeteilt in der Verantwortung des Teams „Kaufen und Begleiten” liegt, das wir als Vertikale bezeichnen, statt die alte Siloaufteilung im Neubau zu konservieren.

Praktisch bedeutet das: klare Verantwortungsgrenzen zwischen alter Plattform und neuer Vertikale, eine bewusst dünne, dokumentierte Schnittstelle dazwischen (ein Anti-Corruption Layer am Eingang der Vertikale) und der Mut, an anderer Stelle vorerst nichts anzufassen. Mit dieser Abgrenzung wollten wir der Organisation zugleich zeigen, wie eine andere Arbeitsweise funktioniert und wie klare Verantwortlichkeiten Effizienz und Stabilität erhöhen. Ist dieser Beweis erbracht, lässt sich der Modernisierungsprozess auf weitere Teile der Plattform ausweiten, dann mit Prozessen, die in der Organisation bereits gelebt werden. Modernisierung ohne Big Bang ist kein Verzicht auf Ambition, sondern Ambition mit Augenmaß.

Eine Vertikale ist nach unserer Definition ein Team mit Verantwortung für eine fachliche Capability vom Konzept bis zum Betrieb. Der Begriff ist wörtlich gemeint: Statt horizontal nach Profession und technischer Schicht zu trennen, schneidet die Vertikale senkrecht durch alle Schichten eines klar abgegrenzten fachlichen Bereichs. Ihre Grenzen sind fachliche, keine technischen. James Lewis und Martin Fowler beschreiben dieses Prinzip in ihrem Microservices-Artikel als Organized around Business Capabilities: Teams werden um den fachlichen Gegenstand herum gebildet, nicht entlang technischer Schichten. Wo geschnitten wird, entscheidet der fachliche Fluss.

Cross-funktional zu sein ist die Konsequenz dieser Verantwortung, nicht ihre Definition: Ownership setzt voraus, dass alle für die Capability nötigen Skills im Team vorhanden sind. Wer die gesamte Lieferung verantwortet, darf für keine Disziplin auf ein anderes Team warten müssen. Konkret sitzen PO, Frontend, Backend, QA, Operations und Fachexperten an einem Tisch und arbeiten als ein Team am selben Backlog, in derselben Iteration, mit derselben Definition of Done. Vom fachlichen Konzept über Code und Tests bis zu Rollout und Betrieb liegt alles in einer Hand; nichts wird über den Zaun geworfen. Was das Team baut, betreibt es auch, einschließlich Bereitschaft, Incident-Response und der unbequemen Frage, warum eine Metrik plötzlich abkippt.

Damit ein solches Team tragfähig liefert, müssen aus Architektursicht zwei Eigenschaften zusammenkommen: Ownership und Entkopplung. Ownership meint, dass das Team für seinen fachlichen Ausschnitt vollständig verantwortlich ist und entscheiden darf, ohne Genehmigungen über mehrere Lager einzuholen. Entkopplung meint, dass es seine Geschäftsfunktion möglichst autark ausführen kann: wenige, klar abgegrenzte Schnittstellen zu anderen Teams und so wenig synchrone Laufzeitabhängigkeiten wie möglich. Wo eine fachliche Anforderung gegen die Entkopplung drückt, ist sie ein Architekturproblem, kein Sprint-Problem. Ohne diese beiden Eigenschaften bleibt Cross-Funktionalität eine Fassade.

Eine Besonderheit unseres Setups ist die cross-company Zusammensetzung: Das Projektteam besteht aus Mitarbeitenden von Auftraggeber und Dienstleister, eine Mannschaft statt zwei. Es gibt keine Über- und Unterstellung entlang der Vertragslinien und kein „liefert/nimmt ab”-Ritual im Sprint. Das ist anstrengend, weil unterschiedliche Erfahrungshorizonte zu vereinen sind. Und darum geht es: Erfahrungen zu verbinden, ist ein Schlüssel. Eine Modernisierung, die nur eine Seite trägt, hinterlässt ein System, das die andere Seite nicht selbst weiterentwickeln kann; allein aus der Bestandsorganisation heraus scheitert sie oft an fehlender Erfahrung mit neuen Arbeitsweisen. Die gemischte Mannschaft bringt beides zusammen und erbringt nebenbei den Beweis, dass die neue Arbeitsweise in dieser konkreten Organisation funktioniert, nicht nur auf einer Folie.

Unsere Pilot-Vertikale verantwortet die Capability „Kaufen” vom Warenkorb bis zur finalen Bestellung und liefert in kurzen Releasezyklen. Begleitet wird sie von einem Plattform-Architekten mit Blick auf die Gesamtplattform; diese Rolle war für mich vorgesehen.

Als Plattform-Architekt sollte ich die Architekturvision entwickeln, Konzepte schreiben, Reviews durchführen, Entscheidungen gemeinsam mit Teams und Stakeholdern treffen und das neue Umsetzungsteam von außen beraten. Die Produktverantwortung sollte in der Bestandsorganisation bleiben.

Eine in der Theorie gute Rollenabgrenzung. Aber eine, die in einer historisch gewachsenen Organisation systematisch zwischen den bestehenden Reibungs- und Übergabepunkten verlorenzugehen droht. Organisationen unter Druck greifen nachvollziehbarerweise auf das zurück, was sie kennen: vertraute Lieferpfade, Entscheidungen entlang bekannter Lagerlinien. Wer ohne Erfahrung mit cross-funktionalen Teams unter Zeitdruck Verantwortung für eine neue Arbeitsweise übernehmen soll, hat berechtigte Vorbehalte.

Sichtbar wurde das vor allem bei Scope-Fragen. Ein konkretes Beispiel: Soll die Wunschliste nur für eingeloggte Nutzer funktionieren oder auch ohne Login? Eine Variante war deutlich aufwendiger und stand in keinem guten Kosten-Nutzen-Verhältnis, wurde aber von der Bestandsplattform unterstützt. Die Entscheidung zog sich: viele Personen befragt, viele Meinungen ausgetauscht, immer wieder vertagt. Nicht aus Unwillen, sondern weil die gewohnten Mechanismen der Organisation griffen. Ähnliches zeigte sich bei der Qualitätssicherung: Über Jahre hatte die Organisation gelernt, dass Tests und Abnahme Sache der QA-Abteilung sind, eine direkte Folge der technischen Silos. Der Reflex des Teams war entsprechend zunächst, automatisierte E2E-Tests brauche man nicht.

In vielen solcher Diskussionen, fachlich wie technisch, zeigte sich dasselbe Muster: Dem Team fehlte nicht Beratung, sondern Erfahrung und Sicherheit mit der neuen Arbeitsweise, und damit die Entscheidungsfreude, sie konsequent zu leben. Als wachsender Zeitdruck und ein zunehmend zögerlich auftretendes Team zusammenkamen, geriet das cross-funktionale Team ins Wanken, bevor es richtig angefangen hatte.

In der Rücksprache mit den Auftraggebern war schnell klar: Am Muster des cross-funktionalen Teams halten wir fest. Was fehlte, war erfahrene Führung für genau diesen Modernisierungsprozess: jemand, der Verantwortung für die Fachlichkeit übernimmt, mit Entscheidungsfreude vorangeht und die technische Umsetzung kennt. Die Wahl fiel auf mich, weil ich das Team kannte, die Architekturvision entworfen hatte und beide Seiten mitbrachte, die fachlich-prozessuale wie die technische. Der entscheidende Hebel war kein neues Org-Chart, sondern ein Rollenwechsel auf meiner Seite: Ownership übernehmen und vorleben, statt zu empfehlen.

In einer Organisation mit Erfahrung in solchen Teams wären zwei Personen der sauberere Schnitt gewesen, ich als Architekt und jemand anderes als PO. Das hätte jedoch die Übergabestelle wieder eingezogen, die wir loswerden wollten, und dafür fehlte unter dem Zeitdruck der Spielraum: Entwurf und Priorisierung mussten unmittelbar in einer Hand liegen, bevor das wankende Team ins Kippen geriet.

Damit kam ein zweiter Hut hinzu: Product Owner. Als PO halte ich Backlog, Priorisierung und die Kommunikation mit Fachabteilungen und Stakeholdern; als Architekt die Linien zur Gesamtplattform und die Konsistenz mit der übergreifenden Architekturvision.

Die naheliegende Befürchtung: Ein PO, der zugleich Architekt ist, baut sich eine eigene Spielwiese und verliert den Plattform-Blick. Die Sorge ist berechtigt, und wir gehen aktiv mit ihr um. Architekturentscheidungen, die über die Vertikale hinausreichen, treffe ich nicht im Vertikal-Backlog; sie entstehen in Gesprächen mit den Key Playern der betroffenen Teams und Bereiche. Die tragfähigen Ergebnisse dieser Diskussionen werden als Architecture Decision Records festgehalten, als nachvollziehbarer Pfad zwischen Diskussion, Entscheidung und der Story, in der die Entscheidung wirksam wird. Innerhalb der Vertikale dagegen bin ich entscheidungsfähig, und das ist der Unterschied, der Tempo macht.

Dass der Rollenwechsel nicht nur das Bauchgefühl verbessert hat, sondern messbar wirkte, lässt sich zeigen. Wir haben die durchschnittliche Bearbeitungszeit der komplexen Stories oberhalb von drei Story Points vor und nach dem Rollenwechsel verglichen. Vorher liefen aufwendige Planungsprozesse, die Zeit kosteten und in denen vorhandene Muster der IST-Plattform reflexhaft reimplementiert wurden, ohne nach dem Zweck einer Funktion zu fragen. Danach schnitten wir diese Stories mit klarer Use-Case-Verantwortlichkeit auf eine kleine Gruppe aus dem Team mit den notwendigen Skills zu. Das Ergebnis: Nach vier Sprints hatte sich die durchschnittliche Bearbeitungszeit dieser Stories fast halbiert, der Durchsatz entsprechend nahezu verdoppelt.

Zwei Dinge haben diesen Sprung getragen. Erstens die Übergabe der Verantwortung für einen Use-Case an die Entwickelnden, die ihn umsetzen: Ohne Verständnis für die Funktionalität und den fachlichen Intent dahinter lässt sich ein Use-Case nicht umsetzen. So entstehen fachliches Verständnis und Verantwortungsübernahme auch im Umsetzungsteam. Zweitens Continuous Deployment mit automatisierten E2E-Tests, zunächst bis in die Integrationsumgebung: Weil sich Änderungen schnell deployen ließen und die Testsuite gegen ungewollte Seiteneffekte absicherte, konnten vormals aufwendige Test- und Abnahmeabsprachen stark beschleunigt oder ganz abgeschafft werden. Hier zeigt sich das Zusammenspiel beider Hüte: der fachliche Use-Case-Schnitt auf der einen Seite, die Architekturverantwortung für die Deployment-Pipeline auf der anderen. Durch das Doppelmandat ließ sich beides entscheiden und mit den passenden Leitplanken versehen.

Die Modernisierung bleibt dabei ein Marathon. Stringenz in der Richtung ist wichtiger als das Tempo des einzelnen Schritts: Gerade weil die Schritte klein sind, muss ihre Richtung klar und konsistent sein, sonst summiert sich die Modernisierung Schritt für Schritt wieder zu einer Architekturhistorie.

Die Architektenrolle wird oft sehr technisch wahrgenommen. Das ist nicht falsch, greift aber zu kurz. Meine Jahre in der Entwicklung und als Engineering Lead helfen mir täglich; sie sind die Eintrittskarte, nicht das Spiel. In den klassischen Silostrukturen hat es selten an technischer Kompetenz gefehlt, und trotzdem hat es nicht funktioniert.

Zwei Dimensionen, die in der Architektenrolle oft unausgesprochen bleiben, sind entscheidend. Fachlichkeit: In Anlehnung an Domain-Driven Design ist vor jeder technischen Entscheidung zu klären, was der fachliche Gegenstand ist und wo seine Grenzen verlaufen. Technik folgt der Fachlichkeit. Im Projekt hieß das oft, eine vermeintlich bekannte Funktion erst dann nachzubauen, wenn ihr fachlicher Zweck rekonstruiert war, und nicht, weil die alte Plattform sie besaß. Kommunikation: Gregor Hohpe beschreibt in The Software Architect Elevator, was ein guter Architekt heute können muss: zwischen den Ebenen einer Organisation Fahrstuhl fahren, konkret mit Tech Leads und Fachabteilungen, strategisch mit Geschäftsführung und Stakeholdern. Wer auf einem dieser Stockwerke nicht souverän auftritt, verliert den Anschluss und damit die Möglichkeit, Architektur tatsächlich durchzusetzen.

Beide Dimensionen tragen direkt in die PO-Rolle hinüber. Als PO muss ich präzise wissen, was fachlich in den Ownership-Bereich meines Teams fällt und was nicht. Hier sitzt der stärkste innere Konflikt der Doppelrolle: Was fachlich in unseren Scope gehört, muss ins Backlog, auch wenn ich als PO sofort spüre, dass es das Pensum sprengt. Das löst sich nicht durch Wegschauen, sondern durch ehrliches Erwartungsmanagement mit Stakeholdern und Team.

Die schwierigste Frage im Alltag ist nicht, was zu tun ist, sondern auf welcher Flughöhe man als Architekt-PO unterwegs sein darf. Zu hoch, und das Team hängt an Empfehlungen, die niemand übersetzen kann; zu tief, und man wird zum Engpass, der Mikromanagement betreibt und das Team nicht reifen lässt.

Wer beide Hüte trägt, muss den Rollenwechsel bewusst vollziehen, mitunter mehrmals am Tag: im Refinement PO, im Architektur-Review Architekt. Entscheidend ist, sichtbar zu machen, in welcher Rolle eine Entscheidung fällt, und sie als ADR oder Backlog-Item festzuhalten, nicht im Flur. Bei Architektur- und Schnittfragen formuliere ich Leitplanken, etwa „keine direkte Kopplung an die Legacy-Datenbank, Integration über ein definiertes Event”; die Umsetzung liegt beim Team. Bei Patterns, die das Team noch nicht sicher beherrscht, gebe ich technische Beispiele vor. Von Produktivcode halte ich grundsätzlich Abstand: Er entsteht im Team, das die Mikrostrukturen der Codebasis besser kennt als ich. Regiere ich hinein, ist das Mikromanagement und wirkt trotz kurzfristig gefühlter Beschleunigung als Performance-Killer. Dasselbe gilt auf der Produktseite: Als PO setze ich die Leitplanken über das WAS, den Use-Case, den Nutzen für den Kunden, die Akzeptanzkriterien; wie die Lösung konkret aussieht, entscheidet das Team mit mir im Austausch.

Das ist Lead by Example mit eingebauter Verfallsfrist: Sobald ein Pattern sitzt, gehört es dem Team.

Drei Patterns haben Geschwindigkeit und Qualität zugleich erhöht. Sie sind nicht originell, aber konsequent gelebt.

Backlog als Architekturwerkzeug und ADRs: Das Backlog ist die geschriebene Form der Architekturvision. Jede Story trägt einen Mehrwert über alle Disziplinen hinweg, hat Akzeptanzkriterien im Given/When/Then-Format und ist gegen die Vision priorisiert, nicht gegen Stakeholder-Lautstärke; weitreichendere Entscheidungen werden als ADR festgehalten. Architektur wird so zu etwas, das man liefert, nicht nur schreibt.

Use-Case-Slicing: Wir schneiden dünn. Eine typische Story bewegt ein konkretes Verhalten an einer konkreten Stelle der User Journey: nicht „Warenkorb-Backend bauen”, sondern „der Nutzer legt einen Artikel mit gewählter Variante in den Warenkorb”. Das zwingt alle Disziplinen in dieselbe Story und bewahrt die Vertikale davor, wieder horizontal zu zerfallen.

Rollout-Sicherheit als Default: Continuous Deployment, automatisierte E2E- und Smoke-Tests, Feature-Toggles und Observability gehören in die Definition of Done, nicht in einen Nachgang. Sonst bleibt End-to-End-Verantwortung ein Folienbegriff. Zur Selbstbeobachtung dienen die DORA-Metriken, nicht als Reporting-Pflicht, sondern als Indikator, ob die Vertikale ihr Versprechen einlöst.

Architekturarbeit ist vielschichtig: Technik, Fachprozesse, Organisation. Eine technische Entscheidung ohne organisatorische Anpassung zerläuft an den Schnittstellen zwischen Teams; eine Reorganisation ohne technische Architektur bleibt am Whiteboard. Wenn von Modernisierung die Rede ist, geht es meist um Technologie: neue Sprachen, neue Frameworks, neue Schnittstellen, inzwischen auch AI. Das ist sichtbar und fühlt sich nach Fortschritt an. Aber es ist nur die Hälfte der Geschichte. Eine reine Technologie-Modernisierung verlagert das Problem in eine modernere Syntax; solange die zugrunde liegenden Strukturen unverändert bleiben, ändert sie an Ownership und Delivery nichts.

Conway’s Law beschreibt diese Spiegelung: Die Architektur eines Systems folgt der Kommunikationsstruktur der Organisation, die es baut. Wer die Systemarchitektur ändern will, muss die Organisationsstruktur mitändern. Genau dort zahlt sich das Doppelmandat aus: Technik- und Prozessentscheidungen fallen am selben Schreibtisch, statt zwischen zwei Schreibtischen verlorenzugehen. Modernisierung in unserem Sinne ist deshalb auch Arbeit an der Organisation: an Strukturen, an Prozessen, mit den Menschen. Das dauert länger als ein Framework-Update und kostet Diskussionen und Geduld. Aber es ist das, was die Modernisierung tragfähig macht: Eine Plattform mit moderner Codebasis und

Fünf Muster aus der Pilot-Vertikale tragen über den konkreten Fall hinaus:

1. Modernisierung beginnt bei ganzheitlicher Ownership, nicht bei Technologie. Sonst entstehen im Neubau die alten Schnitte mit moderneren Frameworks.

2. Architekturhistorie wertschätzen und brechen. Sie ist Kontext, nicht Vorlage.

3. Ein Team als Blueprint, kein Big Bang. Das schützt den Cashflow und bringt den Rest der Organisation auf einen wiederholbaren Weg.

4. Doppelmandat mit eingebauter Verfallsfrist. Kann die Bestandsorganisation die PO-Rolle nicht aus sich heraus tragen, werden beide Hüte bewusst zugleich getragen: Ownership übernehmen und die neue Arbeitsweise vorleben, statt sie nur zu empfehlen. Nach dem ersten Launch der Vertikale wird die PO-Rolle wieder an die Bestandsorganisation übergeben, damit das Modell nicht an einer Person hängt.

5. Cross-Company ist kein Nice-to-have. Eine gemischte Mannschaft kann anstrengend sein, für alle Beteiligten. Zugleich schlägt sie die Brücke von der Legacy zur Modernisierung: Sie macht das Muster überhaupt möglich und verankert Strukturveränderungen durch praktische Umsetzung in der Organisation.

Was dieser Ansatz nicht ist: ein Skalierungsmuster. Eine Person kann nicht parallel fünf Vertikalen als PO halten, und es wäre nicht klug, es zu versuchen. Wenn die Organisation reift und weitere Vertikalen aufzieht, müssen diese ihre Owner aus sich heraus finden. Der Architekt-PO-Weg ist dann das, was er von Anfang an sein sollte: ein Startbeschleuniger für die erste, prägende Vertikale.

Die Doppelrolle aus Architekt und PO war kein Patentrezept, sondern eine pragmatische Konsequenz aus den Gegebenheiten der Organisation. Sie ist eine Möglichkeit, keine Silver Bullet: Sie kann eine Modernisierung beschleunigen, indem sie die Lücke zwischen Entwurf und Lieferung für die erste Vertikale schließt, aber sie ist keine Dauerlösung. Entscheidend ist am Ende nicht, ob beide Rollen in einer Person liegen, sondern dass beide Rollen gut ausgefüllt werden. Deshalb ist das bewusste Trennen der Rollen genauso wichtig wie das anfängliche Zusammenlegen. Die Personalunion ist der Anstoß; die Blaupause ist die Vertikale, die auch ohne sie weiterläuft. Auch die Abgabe der Verantwortung gehört zur Verantwortung.
_______
Quellen und Inspiration: Eric Evans, „Domain-Driven Design” (Addison-Wesley 2003); Nicole Forsgren, Jez Humble, Gene Kim, „Accelerate” (IT Revolution 2018); James Lewis und Martin Fowler, „Microservices” (martinfowler.com/articles/microservices.html); Martin Fowler, „Strangler Fig Application” (martinfowler.com/bliki/StranglerFigApplication.html); Gregor Hohpe, „The Software Architect Elevator” (O’Reilly 2020).

Hier finden Sie den Artikel in voller Länge im IT Spektrum.