Blog

Trainieren Sie Ihre Architekten in Agiler Architektur!

Kenny Baas-Schwegler

Aktualisiert Oktober 16, 2025

9 Minuten

Wenn Unternehmen auf eine agile und DevOps-Arbeitsweise umstellen, fragen sie sich manchmal, wie sie mit Architekten verfahren sollen. Einige Unternehmen ignorieren Architekten bei ihrer Transformation, andere bilden ihre Architekten weiter und wieder andere machen die DevOps-Teams für die Architektur verantwortlich. Ein Kernproblem, das wir sehen, ist, dass die für die Transformation Verantwortlichen wenig Erfahrung im Umgang mit Architektur auf agile Weise haben. Die agilen Coaches sind damit beschäftigt, die Organisation auf Prozessebene agil zu machen. Die Scrum Master sind mit dem agilen Prozess auf Teamebene befasst. Und bei einigen Transformationen hat das Team auch einen agilen technischen Coach, der dem Team neue Praktiken und Techniken aus Continuous Delivery, DevOps und SRE beibringt. Im Gegensatz dazu beobachten wir, dass Architekten, wenn überhaupt, nur geschult werden und kein Coaching erhalten. In diesem Artikel wird dargelegt, warum es wichtig ist, den Umgang von Unternehmen mit Architekten zu überdenken und damit zu beginnen, Architekten auf dem Weg zu einer agilen Architektur ausdrücklich zu coachen.

Wie sich die Rolle der Architekten in Agile und DevOps verändert

In der Branche wird heftig darüber diskutiert, ob wir noch Architekten brauchen, wenn wir die leistungsstarken Softwareteams für die Architektur verantwortlich machen können. Das ist eine Idealsituation, die nur sehr schwer in die Realität umgesetzt werden kann, und unabhängig davon, wie Sie sich organisieren, müssen Sie Architektur immer noch außerhalb der Entwicklungsteams praktizieren. In diesem Beitrag werden wir beschreiben, warum:

Software-Teams arbeiten auf verschiedenen Ebenen und konzentrieren sich auf ihren Zweck innerhalb des Systems. Sie konzentrieren sich weniger auf eine höhere Arbeitsebene und haben auch keinen Anreiz, darüber nachzudenken.
Softwareteams sind Teil des Systemdesigns Ihres Unternehmens. Wir müssen dennoch sicherstellen, dass sie zu Ihrer Geschäftsstrategie und Ihren Wertströmen passen und mit ihnen übereinstimmen.
All diese Teile sollten für ihre eigenen Architekturentscheidungen verantwortlich gemacht werden. Es liegt in der Verantwortung der Architekten, dies zu ermöglichen, und das erfordert, dass die Architekten neue soziale Fähigkeiten erlernen, die sich nur schwer durch Training selbst verbessern lassen und Coaching erfordern.

Woher kommt also der Drang, die Architekten abzuschaffen? Nun, früher haben die Architekten ihre Arbeit in einer Wasserfallorganisation außerhalb der Teams erledigt. Die Entwicklungsteams haben also das Gefühl, dass die Architekten in ihrem Elfenbeinturm sitzen, isoliert von den Teams, und Entscheidungen für die Teams treffen, die außerhalb ihres Kontextes liegen und nichts mit dem zu tun haben, was in der Praxis möglich ist. Entscheidungen für die Teams zu treffen, war in einem Wasserfallkonzept (einigermaßen) sinnvoll, weil Sie die gesamte Architektur entwerfen mussten, bevor Sie sie an die Entwicklungsteams weitergeben konnten. Und dann durchläuft das Unternehmen eine agile Transformation, bei der hauptsächlich das Scrum-Framework zum Einsatz kommt. Es wird nichts über die Architektur gesagt. Es heißt: "(Wir sind dazu übergegangen,) funktionierende Software über umfassende Dokumentation über Prozesse und Tools zu stellen. Und diese Aussage brachte die Teams gewöhnlich auf die Idee, dass die alte Art und Weise, umfangreiche Architekturdokumente zu schreiben, nicht mehr benötigt wird. Aber das Problem, das wir sehen, ist, dass die Teams auch nicht wissen, wie man Softwarearchitektur richtig macht, weil sie in der Vergangenheit nie damit beauftragt wurden und dazu in der Lage waren. Und wie Douglas Martin sagte, sind Architektur und Design unvermeidlich; man kann entweder eine gute oder eine schlechte Architektur haben.

Die Frage, ob Design notwendig oder erschwinglich ist, ist völlig nebensächlich: Design ist unvermeidlich. Die Alternative zu gutem Design ist schlechtes Design, nicht gar kein Design. - Douglas Martin

Dann kam die DevOps-Transformation, die sich auf die Verschmelzung von Entwicklungs- und Betriebspraktiken konzentrierte, so dass die Teams die volle Verantwortung für das, was sie entwickelten, übernehmen konnten. Und als Bonus wurden auch die Architekturfähigkeiten eingeführt, die den Teams halfen, in die richtige Richtung zu gehen. Außerdem wurde ein Großteil der Verantwortung von den Architekten auf die Teams übertragen. Wie wir bei einer agilen Transformation beobachtet haben, bleiben die Architekten außen vor, was nicht bedeutet, dass wir sie nicht brauchen.

Wir benötigen immer noch Architekten

Softwareteams entwickeln sich immer mehr zu autonomen, leistungsstarken Teams, die die Produkte oder Dienstleistungen, die sie entwickeln, selbst in die Hand nehmen und näher an ihre Kunden oder Stakeholder herankommen. Außerdem lernen sie durch die kontinuierliche Verbesserung ihrer Teampraktiken und Fähigkeiten den Geschäftswert, den sie liefern, besser kennen - eine hervorragende Sache. Aus diesem Grund sehen wir immer weniger "IT-Architekten" in Unternehmen. Etwas, worüber Edo Poll bereits in seinem Artikel 'The value of Agile Architecture in a modern organization' geschrieben hat . Und die Unternehmen müssen auch dafür sorgen, dass diese leistungsstarken autonomen Teams auf die Unternehmensstrategie ausgerichtet bleiben. Wir beobachten zwei Hauptansätze:

Unternehmen implementieren einen agilen Skalierungsrahmen, der sich darauf konzentriert, bürokratische Prozesse zu implementieren, um die Kopplung zwischen den Teams zu verwalten, damit sie aufeinander abgestimmt bleiben, was die Autonomie der Teams verringert.
Oder die Teams erhalten volle Autonomie und konzentrieren sich ganz auf ihr eigenes Ziel, wissen aber nicht, welchen Einfluss sie auf den Geschäftswertstrom des Unternehmens haben.

Und genau aus diesem Grund brauchen wir immer noch Architekten, die Geschäfts- und Technologieteams für einen schnellen Ablauf organisieren und entweder Entscheidungen mit diesen Teams erleichtern und treffen oder mit ihnen Entscheidungen treffen, um ihnen ihre Auswirkungen bewusst zu machen. Architekten arbeiten in einem Unternehmen auf verschiedenen architektonischen Ebenen und in verschiedenen Bereichen. In dem Whitepaper ' Architektur als Geschäftskompetenz, ' Ruth Malan und Dana Bredemeyer beschreiben die Beziehung zwischen einem Architekten und einem Team treffend. "Es kann nicht Sache der Entwickler und Business-Analysten sein, zu entscheiden, welche Teile der Architektur angewandt und welche ignoriert werden sollen. Wenn Sie Ihre Architekten als Berater und nicht als Entscheidungsträger behandeln ... können Sie nur erwarten, dass Sie eine Ansammlung von Teilen mit unvorhersehbaren Eigenschaften erhalten." Die Teile der Architektur auf den verschiedenen Ebenen sind nicht von den anderen Ebenen abstrahiert; sie sind verschiedene Teile des Systems. Teams können immer noch Entscheidungen über ihren Bereich treffen, aber nicht über den Bereich einer anderen Ebene.

Also dUnterschiedliche Ebenen des Umfangs erfordern andere Fähigkeiten und eine andere Denkweise. Dieses Konzept der Architekturbereiche deckt sich auch mit den Arbeiten von Elliott Jaques über die Arbeitsebenen. Jaques stellt eine großartige Analogie her, indem er sagt, dass sich die verschiedenen Arbeitsebenen in Bezug auf die Denkweise so sehr unterscheiden, wie sich Wasser von Dampf unterscheidet. Ähnlich, wie sich der Anwendungsbereich vom Bereich unterscheidet. Jede Ebene erfordert andere Aspekte und hat andere Eigenschaften.

Unterschiedliche Arbeitsebenen haben eine so unterschiedliche Natur in Bezug auf die Denkweise, wie, in Analogie, Wasser und Dampf unterschiedlich sind - Elliott Jaques

Architekten sollten sich immer noch mit den verschiedenen Ebenen des Umfangs befassen, so wie sie es vor der agilen Phase getan haben, um Gregor Hope zu zitieren: "Fahren Sie mit dem Architekturfahrstuhl". Der Unterschied in der agilen Architektur besteht darin, dass die Architekten jetzt die Führung bei neuen Möglichkeiten übernehmen und dann die Verantwortung kontinuierlich an Teams und Manager weitergeben müssen. Wir können dies durch partizipatives Design erreichen. Wir modellieren die Lösungen gemeinsam mit Interessengruppen, Benutzern und Teams. Dies erfordert jedoch eine neue Reihe von Fähigkeiten eines Architekten. Diese Fähigkeiten konzentrieren sich mehr auf den sozialen Bereich als auf den technischen.

Beginnen Sie mit dem Coaching Ihrer Architekten

Anstatt Ihre Architekten während der Transformation loszuwerden, schulen Sie sie. Bringen Sie den Architekten bei, wie man Kollabo rative Architekturentscheidungen und führen kollaborative Modellierungsworkshops durch. Bringen Sie ihnen bei, wie sie diese Workshops zwischen Domänenexperten, Interessengruppen und Softwareentwicklungsteams moderieren können, um ein gemeinsames Realitätsgefühl mit einer gemeinsamen Sprache und einem gemeinsamen Verständnis zu entwickeln. Die Moderation dieser Sitzungen erfordert von den Architekten, dass sie in die Fähigkeiten von Menschen und Gruppen investieren, wie z.B. den Raum zu halten, mit Widerstand umzugehen, die Macht der Rangordnung zu erkennen, mit kognitiven Voreingenommenheiten umzugehen, Zustimmung zu schaffen und Konflikte zu bewältigen. Und um all diese neuen Dinge zu lernen, braucht es Übung und vor allem Coaching. Coaching ist unerlässlich, denn jeder wird unsicher sein, wenn er zum ersten Mal mit den Herausforderungen einer Gruppe konfrontiert wird. Und das ist auch verständlich, denn wir betreten einen neuen Bereich von Fähigkeiten. Technische Probleme sind relativ einfach zu lösen, wenn man genügend Zeit und Wissen hat. Der Umgang mit sozialen Problemen ist viel schwieriger, weil sie komplex sind. Sie erfordern Erfahrung und Nachdenken, um sie zu lösen. Jede Situation ist anders, und die meisten Probleme, mit denen sich Architekten befassen, haben mit den inneren Gefühlen eines Menschen zu tun. Wenn sich zum Beispiel jemand in einer Gruppe nicht willkommen fühlt, ist das eine Herausforderung, der man sich während dieser Sitzungen bewusst sein muss. Handelt es sich dabei nur um ein bestimmtes Gefühl der Person, mit dem sie zu kämpfen hat? Oder ist sie in dieser Sitzung wirklich nicht willkommen? Kein Wunder, dass Architekten dann auf das zurückgreifen, was sie bereits wissen. Sie treffen Entscheidungen in Isolation und werden dann als Elfenbeinturm-Architekten abgestempelt.

Wenn dies geschiehtns ziehen wir Berater hinzu, um das Problem zu lösen. Ihre Aufgabe ist es, diese Sitzungen zu moderieren und die Organisation bei der Umgestaltung und Verlagerung der Verantwortlichkeiten und der Änderung der Teamtopologie zu beraten, indem sie kollaborative Modellierungssitzungen leiten. Und manchmal helfen sie dem Architekten, sich weiterzubilden. Aber sobald sie das Unternehmen verlassen und ihren Job machen, sind die zugrunde liegenden Probleme mit den derzeitigen Architekten nicht gelöst. Natürlich gehört es zu den Aufgaben der Berater, die Architekten während ihres Engagements zu coachen, aber das ist nie das Hauptaugenmerk. Deshalb halten wir es für unerlässlich, das Coaching von Architekten im Rahmen einer solchen Transformation explizit zu machen. Zunächst sollten Sie die Architekten durch Schulungen weiterbilden und dann individuelle Ziele und Entwicklungspfade definieren, um Lücken in den Fähigkeiten und Erfahrungen zu schließen, indem Sie das erlernte Wissen in der Praxis anwenden. Als Nächstes sollten Sie die Architekten damit beginnen lassen, diese Sitzungen zu moderieren, damit sie darüber nachdenken können, was ihnen schwer gefallen ist und welche Probleme sie hatten. Dann coachen Sie sie bei der Moderation von Sitzungen, um diese Probleme zu bewältigen und selbst zu lösen.

Tags:

Verfasst von

Kenny Baas-Schwegler

A lot of knowledge is lost when designing and building software — lost because of hand-overs in a telephone game, confusing communication by not having a shared language, discussing complexity without visualisation and by not leveraging the full potential and wisdom of the diversity of the people. That lost knowledge while creating software impacts the sustainability, quality and value of the software product. Kenny Baas-Schwegler is a strategic software delivery consultant and software architect with a focus on socio-technical systems. He blends IT approaches like Domain-Driven Design and Continuous Delivery and facilitates change with Deep Democracy by using visual and collaborative modelling practices like Eventstorming, Wardley mapping, context mapping and many more. Kenny empowers and collaboratively enables organisations, teams and groups of people in designing, architecting and building sustainable quality software products. One of Kenny's core principles is sharing knowledge. He does that by writing a blog on his website baasie.com and helping curate the Leanpub book visual collaboration tool. Besides writing, he also shares experience in the Domain-Driven Design community as an organiser of Virtual Domain-Driven Design (virtualddd.com) and Domain Driven Design Nederland. He enjoys being a public speaker by giving talks and hands-on workshops at conferences and meetups.

Unsere Ideen