Architekturarbeit in Cross-funktionalen, agilen Teams Brauchen wir noch Software-Architekten?

Jeden Tag und jede Stunde, in der Software entwickelt wird, entsteht Architektur – ob es so vorgesehen war oder auch nicht. Wenn Architektur aber einfach so entsteht, dann braucht man keine Software-Architekten – oder vielleicht doch?

Heute arbeiten die meisten Softwareentwicklungs-Projekte in einem agilen Ansatz. Dabei wird Agilität durch die agilen Prinzipien beschrieben:

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.

• Funktionierende Software ist wichtiger als eine umfassende Dokumentation.

• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.

• Reagieren auf Veränderungen ist wichtiger, als einem Plan zu folgen.

Cross-funktionale Teams entwickeln die Software. Cross-funktional meint hier, dass die Software entworfen, entwickelt, getestet und in die Produktion gebracht wird. Und natürlich heißt Entwerfen, dass Architekturarbeit geleistet wird. Und da agile Software-Entwicklung heißt, Inkrement für Inkrement zu entwickeln, heißt es auch, dass die Architektur Inkrement für Inkrement entsteht.

Was ist Architektur?

Wenn selbstverantwortliche Teams Software entwickeln, entsteht Architektur. Aber in der Regel arbeiten mehrere Teams an einem Software-Projekt. Wie kann man absichern, dass diese Teams möglichst unabhängig voneinander arbeiten können? Es muss garantiert werden, dass die Software als Ganzes funktioniert – also funktionierende Software entsteht.

Im gleichen Zuge heißt das aber auch, dass umfassende Schnittstellendokumentationen benötigt werden, so dass andere Teams diese Schnittstellen benutzen können. Software-Architektur entsteht während der Entwicklung, aber viele Teams müssen im Rahmen der Entwicklung synchronisiert werden. Wo entsteht dann die Architektur und was ist sie eigentlich?

Laut ISO/IEC/IEEE 42010 2011 umfasst Software-Architektur die funktionalen Konzepte oder Eigenschaften eines Systems in seiner Umgebung verkörpert in seinen Elementen, Beziehungen und in den Prinzipien seines Entwurfs und seiner Entwicklung. Dabei kann das System eine einfache Anwendung, eine komplexe Unternehmensanwendung oder auch eine ganze Landschaft von Unternehmensanwendungen sein. Dabei „passiert“ Architektur auf verschiedenen Ebenen.

Unternehmensarchitektur

Unternehmensarchitektur oder auch Enterprise-Architektur ist eine Architektur, die durch das jeweilige Geschäft getrieben wird. Die Geschäftsfähigkeiten werden in Funktionen heruntergebrochen und diese wiederum werden Anwendungen zugeordnet.

Systemarchitektur

Normalerweise wird die Systemarchitektur als Architektur der unterschiedlichen Infrastrukturkomponenten wie Loadbalancer, Proxyserver oder auch Event- und Messagebroker gesehen. Jede dieser Komponenten spielen eine Rolle in den jeweiligen Anwendungen. Aber aus der Sicht einer Funktion sind sie nicht sichtbar. Daher muss ein Systemarchitekt diese Komponenten so in die Anwendungen einbauen, dass die nicht-funktionalen Anforderungen abgesichert werden können.

Normalerweise sind Systemkomponenten verteilte Komponenten. Sie gehören also nicht einem Team. Aber sie haben direkten Einfluss auf die Funktionalität einer Anwendung. Daher muss es jemanden geben, der die Anforderungen aller Teams aufnimmt und im Rahmen der Möglichkeiten umsetzt.

Lösungsarchitektur

Da die Lösungsarchitektur – wie ihr Name schon vermuten lässt – direkten Einfluss auf die Lösung hat, muss sie die Funktionalität der Anwendung absichern. Normalerweise arbeiten mehrere Teams an einer Anwendung. Man muss die Unabhängigkeit der einzelnen Teams auf der einen Seite, aber auch die Ende-zu-Ende-Funktionalität der Gesamtanwendung auf der anderen Seite sicherstellen.

Die Lösungsarchitektur eines Teams wird sich über die Zeit ändern. Allerdings muss sichergestellt sein, dass andere Teams durch diese Änderungen nicht negativ beeinflusst werden.

Architektur – Lösung von Widersprüchen

Funktionierende Software heißt auch, dass Teams so aufgesetzt sind, wie die Software, die wir erhalten wollen. Conways Law sagt uns, dass die entstehende Softwarestruktur der Organisation entspricht, die sie entwickelt. Das heißt aber auch: Wenn die Teams so geschnitten sein müssen, wie die Software, die erhalten werden soll, muss die Architektur zu einem gewissen Maße vorherbestimmt werden.

Diesem Widerspruch kann man mit dem Unterschied des taktischen und strategischen Designs begegnen, wie er durch Eric Evens mit dem domänengetriebenen Entwurf definiert wurde („Domain Driven Design: Tackling Complexity in the Heart of Software” von Evans, Eric J., ISBN: 8601300201665). Taktisches Design findet innerhalb eines Teams statt. Das Team entwickelt seine eigene, spezifische Frage, um seinen Entwicklungsgegenstand zu beschreiben. Strategisches Design findet team-übergreifend statt und definiert die Domänen- und damit die Teamgrenzen.

Auch die einmal definierten Teamgrenzen ändern sich und bedürfen der regelmäßigen Überprüfung und eventueller Korrektur. Aber man muss sich bewusst machen, dass Teamänderungen Änderungsprozesse sind, die enger Begleitung bedürfen und die Geschwindigkeit der Entwicklung insgesamt senken. Aber diese Änderungen nicht herbeizuführen, würde heißen, dass die Software am Ende nicht den Anforderungen entspricht.

Ebenen der Architekturarbeit

Architekturarbeit findet auf unterschiedlichen Ebenen statt. Diese Ebenen nehmen sehr verschiedene Perspektiven auf die Geschäftsfunktionen und technische Infrastruktur ein.

Die vorangestellte Abbildung zeigt die verschiedenen Arten von Architekturarbeit, die sich auf die verschiedenen Ebenen der Architektur fokussieren. Auf Unternehmensebenen werden die Geschäftsfähigkeiten Anwendungen zugeordnet, wobei übergreifende Modelle verwendet werden. Auf der anderen Seite ordnet in der Systemarchitektur Infrastrukturkomponenten wie Loadbalancer und Server Geschäftsfunktionen zu, die durch Anwendungen repräsentiert werden.

Systemarchitektur fokussiert auf die Basis des Software-Ökosystems und die damit verbundenen Infrastrukturkomponenten. Der taktische Entwurf fokussiert auf den Entwurf einer Lösung und wird normalerweise von einem Team verantwortet. Der Entwurf – also die Architektur – entsteht mit der Arbeit innerhalb des Teams. Der strategische Entwurf fokussiert auf die Definition der Domänengrenzen und die Zuordnung der Domänen zu Anwendungen und Lösungsarchitekturen. Die Geschäftsarchitektur fokussiert – wie schon gesagt – auf die Zuordnung von Geschäftsfähigkeiten auf Anwendungen.

Brauchen wir noch Architekten?

Diese Frage lässt sich mit einem eindeutigen Ja beantworten. Auch wenn Architekturarbeit auf viele Schultern verteilt ist, können einzelne Teams die übergreifenden Fragen, die sich sowohl aus der Systemarchitektur als auch aus dem strategischen Entwurf und der Unternehmensarchitektur ergeben nicht beantworten. Diese Fragen müssen übergreifend beantwortet werden.

Ab einer bestimmten Größe kann dies auch nicht mehr nebenbei durch Architekten in den Teams geschehen, sondern es muss übergreifende Architekten geben, die übergreifende Architekturaufgaben erledigen. Diese übergreifenden Architekten schreiben aber die Lösung nicht vor, sondern befähigen vielmehr die Teams in ihrem Raum unabhängig und selbstständig zu arbeiten.

* Dr. Anngret Junker ist Principal Software Architect bei adesso. Sie arbeitet seit mehr als 25 Jahren in der Software-Entwicklung in unterschiedlichen Rollen und unterschiedlichen Domänen wie Automotive und FinTech.

(ID:46863535)