Ist Enterprise-Architektur und Agil ein Widerspruch?

English Version

Über die letzten Monate denke ich mehr und mehr darüber nach, wie Architektur-Arbeit agil ausführen kann. Natürlich kenne ich die Standard-Antworten: Architektur wird im Team gemacht, benutze KANBAN Boards, beziehe die Stakeholder mit ein, … Aber ich denke, das Problem liegt tiefer als Architekten, die nicht in die Teams integriert sind, können nicht agil sein. I denke, hier ist ein Widerspruch, der tief unter der Oberfläche liegt.

Als Architekten kümmern wir uns um die nicht-funktionalen Anforderungen, wie Performance, Stabilität, Verfügbarkeit, Veränderbarkeit, … *barkeit usw. Wenn wir eine Lösung für ein kritisches Problem gefunden haben – und alle diese *barkeits sind kritisch – wollen wir sie nicht mehr ändern. Aber jeder engagierte Product Owner will das System so schnell wie möglich ändern, um neue Funktionen jeden Tag zu implementieren, um den Kunden zufrieden zu stellen. Das ist der Widerspruch, den wir lösen müssen.

So, wie bekommen wir dann eine stabile Architektur, welche es ermöglicht, Funktionen konstant hinzuzufügen. … Oh, I sehe schon: „stabile Architektur“ ist der falsche Begriff. Der richtige Begriff muss „flexible Architektur“ sein. Flexible Architektur heißt eine Architektur, die es erlaub konstant Funktionen hinzuzufügen, ohne dass die bereits erreichten nicht-funktionalen Indikatoren gefährdet werden. Darüber hinaus können sich auch die nicht-funktionalen Anforderungen über die Zeit entwickeln, z.B. kann die Stabilität durch mehr und mehr Benutzer auf der Plattform instabil werden. Die flexible Architektur erlaubt dann Änderungen, so dass anderen Indikatoren werden nicht in die falsche geändert werden.

Wie können wir so eine flexible Architektur erreichen? Natürlich sind Micro-Services eine der Grundlagen. Geschäftsfunktionen wie „Erzeuge ein neues Geschäftsobjekt“ sind als eigener Service mit eigener Datenbank implementiert. Das minimiert Seiteneffekte zu anderen Services. Vergleichbare Ansätze werden für die Implementierung kleinere Funktionen innerhalb des Service benötigt. Vergleichbare Ansätze heißt hier, dass die Funktionen innerhalb eines Micro-Service sind ebenfalls nur lose verbunden.

Jetzt habe ich die ganze Zeit technische Argumente aufgezählt, aber ich wollte doch eine Vorgehensmethodik haben. Ich denke, ohne eine solche flexible Architektur kann einen agilen Ansatz in der Architektur-Arbeit absichern. Als ein Architekt muss man ein Coach für das Implementierungsteam sein. Es muss dem Team ermöglicht werden, dass es seine Entscheidungen treffen kann. Der Architekt muss ihm diese Freiheit geben – ohne dass er andere herausfordert. Das gilt sowohl für die Stakeholder aber auch für die anderen Teams. Entscheidungen eines Teams müssen wirklich unabhängig sein. Die Entscheidungsfreiheit eines Teams durch die Entscheidungen eines anderen Teams einzuschränken wäre wirklich hässlich.

Über alles gesehen, sichern flexible Architekturen *barkeits durch bekannte Prinzipien wie lose Kopplung an einer Hand, aber sie sichern auch die Unabhängigkeit der Teams die Freiheit ihrer technischen Entscheidungen. Die Unabhängigkeit der Teams wiederum erlauben eine kontinuierliche Lieferung von neuen Funktionen.

Zusammenfassen lässt sich sagen:

• Architektur sichert nicht-funktionale Anforderungen
• Änderungen in der Architektur durch neue Funktionen können die nicht-funktionale Anforderungen gefährden
• Flexible Architekturen erlauben die kontinuierliche Anpassung auf der einen Seite und stabile Erreichung der nicht-funktionalen Anforderungen auf der anderen Seite
• Agile Vorgehensmethoden erlauben es, solche flexiblen Architekturen zu erstellen und zu pflegen
• Ein Architekt muss ein Coach für ein agiles Team sein.