Warum ich als Software-Architektin nicht überflüssig bin

Gedanken zur Rolle des Software-Architekten im agilen Umfeld

In der guten alten Zeit war die Welt für einen Software-Architekten noch in Ordnung. Er bekam eine Aufgabe gestellt, über die er in Ruhe nachdenken durfte, um geeignete Lösungsmöglichkeiten zu finden. Hatte er eine Lösungsmöglichkeit gefunden, beschrieb er sie mehr oder weniger formal, und übergab sie an die Entwicklung. In diesem Moment hatte er die Lösung bereits wieder vergessen, denn sein Kopf beschäftigte sich schon mit dem nächsten, schönen Problem.

Der Software-Architekt – die wichtigste Figur in der Entwicklung

Der Software-Architekt war die wichtigste Figur in einem Softwareprojekt. Gottgleich. Natürlich gab es auch früher schon Projektleiter, Business-Analysten, Steuerkreis-Mitglieder, etc. Aber ER war der wichtigste von allen.

Natürlich war auch in der guten alten Zeit nicht alles Gold was glänzt. Meist bekam selbst der gottgleiche Software-Architekt, unser Think Tank, unsere Quelle der Erleuchtung , nicht das, was er eigentlich entworfen hatte. Aber immerhin: wenn etwas funktionierte, hatte er es impliziert entworfen, wenn es nicht funktionierte, dann waren die anderen schuld. Es war eine schöne Welt – zumindest für den Architekten.

Tatsächlich war es keine Boshaftigkeit der Softwareentwickler, nicht das zu entwickeln, was ein Architekt entworfen hatte. Nein, sie mussten Dinge entwickeln, die die augenblickliche Anforderungslage abbildete, die den technologischen Möglichkeiten entsprachen. Anforderungen standen und stehen nicht still. Sie entwickeln sich. Sie passen sich den Möglichkeiten an. Technologie bleibt nicht stehen. Neue Möglichkeiten entwickeln sich, die das Problem besser lösen können. In der Entwicklung nicht auf solche Änderungen zu regieren, heißt schlicht schon beim ersten Produktivgang obsolete Software zu betreiben. Das war früher schon so und auch heute ist dies unverändert so.

Der Wandel der Rolle

Heutzutage entwickeln cross-funktionale Teams Software. Sie entwickeln sie, sie testen sie, sie entwerfen sie. Ja, Teams entwerfen Software. Und Software zu entwerfen, heißt die Architektur zu entwerfen, zu designen.

Aber wo ist der Softwarte-Architekt, wenn das Wissen über das Gesamtsystem in den Teams verteilt ist und diese Teams am besten wissen, was sie tun? Die Antwort ist relativ einfach: der Software-Architekt oder die Software-Architektin muss Teil des Teams sein.

Und was passiert mit den Themen, die nicht unbedingt einem Team zugeordnet werden? Wenn wir nicht nur mit Feature-Teams agieren, sondern uns mit Themen wie Authentifizierung, Logging, Business-Monitoring, Security usw. beschäftigen? Wer kümmert sich um solche cross-cutting Concerns? Offensichtlich benötigen Organisationen Vertreter, die sich teamübergreifend querschnittlichen Fragestellungen annehmen.

Das Big Picture im Blick

Heutzutage entstehen Lösungen für Themen – auch für übergreifende Themen – in Teams. Es sind häufig gute Lösungen, die zu dem Umfeld passen, in dem das Team arbeitet. Team A baut eine Lösung für Problem X. Team B baut eine ähnliche Lösung für ein ähnliches Problem. Beide Teams sind schnell und unabhängig. Sie brauchen niemanden, der in ihre Lösungen „hinein regiert“. Allerdings hätte Team B vielleicht Teile von Team A wiederverwenden können. Stichwort: Wiederverwendbarkeit.

Ich bin persönlich kein großer Fan von solcher Wiederverwendbarkeit, da sie oftmals Abhängigkeiten schafft, wo sie nicht unbedingt sein müssten. Aber wirtschaftliches Arbeiten verlangt auch, dass wir über den Tellerrand unseres eigenen Teams hinweg schauen.

Dieses „über den Tellerrand hinweg schauen“ setzt – aus meiner sehr persönlichen Sicht – ein „Big Picture“ voraus. Einzelne Teams können dies ohne die Hilfe der anderen nicht schaffen. Während der Initialisierung eines Projektes hilft die Erarbeitung eines Big Pictures, das gegenseitige Verständnis zu schaffen. Aber wenn ein Big Picture auch im weiteren Verlauf helfen soll, muss es erlaubt sein, dass es sich verändert. Wahrscheinlich ändert es sich nicht grundlegend, sondern subtil. Aber auch solche Änderungen müssen erlaubt sein und beachtet werden.

Die Gemeinschaft von Praktikern

Wir haben also zentrale Themen wie das Big Picture und die cross-cutting Concerns, bei denen Teams unterstützt werden sollten. Interessanterweise schränkt eine solche Unterstützung die Selbstverantwortlichkeit der Teams nicht ein, sondern ermöglicht sie erst. „Anbieten“ ist dabei das Schlüsselwort, nicht „Vorschreiben“. Wenn eine  teamübergreifende Instanz bspw. Lösungen für Pflegbarkeit, Verfügbarkeit oder Sicherheit anbietet, hören Teams gerne zu. Vorbei sind die Zeiten, in denen eine gottgleiche Figur seine Erkenntnisse einfach an das Programmier-Volk übergab, um sich zügig neuen Probemen zuzuwenden.

Ein weiteres Angebot ist der Austausch in einer Gemeinschaft von Praktikern, gerne auch Community of Practice genannt. Die Teams delegieren Mitglieder in diese Community, um Fragen der täglichen Arbeiten wie Architektur, Technologie, Vorgehensweisen, Betrieb etc. zu besprechen.

Und hier kommt die Software-Architektin oder der Software-Architekt als Unterstützung wieder ins Bild. Er oder sie kann bei gegensätzlichen Auffassungen vermitteln, Einigungen herstellen, und auch Entscheidungen dokumentieren. Darüber hinaus ist es in Regel auch für eine teamunabhängige Instanz einfacher, neue Technologien in Beispielimplementierungen auszuprobieren, um entsprechendes Wissen in die Teams zu tragen.

Die notwendige Voraussetzung: Entscheidungskompetenz

Eine Community of Practice verwandelt sich in der gelebten Unternehmenspraxis schnell in einen zahnloser Tiger, wenn sie keine Entscheidungskompetenz erhält. Entscheidungen innerhalb gegebener Leitplanken müssen in der Community getroffen werden können. Ein Regieren des Managements in diese Entscheidungskompetenz hinein hat oftmals fatale Folgen. Und auch der Software-Architekt oder die Software-Architektin muss sich dran gewöhnen, dass er oder sie zwar gehört wird, aber die Stimme nur eine unter vielen ist. Andernfalls werden sich die Mitglieder der Community nicht mehr engagieren.

Wenn die Community Entscheidungskompetenz erhält, verhält sich niemand mehr wie ein Architekt. Der Begriff Architekt kommt aus dem Griechischen und bedeutet soviel wie Meister-Schöpfer.¹ Heutzutage sind allein die Teams die Meister-Schöpfer des Geschäftsinhalts.

Die Community kann die Verantwortung für alles übernehmen, dass nicht unmittelbar „Business“ ist. (Das gilt übrigens auch für UX/UI Design, aber das ist ein Thema für einen anderen Blogbeitrag. 😉) Sie kann über alle architektonischen Fragen entscheiden, die nicht innerhalb der Teams geklärt werden können. Ist eine Entscheidung getroffen, müssen sich die Teams auch daran halten. Da die Entscheidungen durch Teammitglieder getroffen werden, lässt sich in der Regel eine hohe Akzeptanz voraussetzen. Mehr noch, die Teammitglieder informieren ihre Teams auch über Diskussionen, selbst wenn noch keine Entscheidungen getroffen wurde. So gelangt das Wissen der Community in die Teams und diese können umgekehrt ihre individuelle Sicht in die Diskussion einbringen. Alle gewinnen!

Noch ein kleiner Gedanke: Wie mit anderen Entscheidungen auch, Community-Entscheidungen ergeben nur Sinn, wenn sie nachhaltig sind. Es gilt also zu beobachten, ob die Entscheidungen in den Teams beachtet werden und gegebenenfalls, warum dies nicht der Fall ist. Natürlich kann sich auch eine Gemeinschaft von Praktikern irren.  Daher müssen auch die Community-Mitglieder bereit sein, eigene Fehler zu akzeptieren und getroffene Entscheidungen zu revidieren.

Fazit

Wo bleibe ich jetzt? Als Software-Architektin kann ich die Community unterstützen und mit Rat und Tat zur Seite stehen. Ich kann Investitionsentscheidungen vorbereiten und gemeinsam mit den Teams entsprechende Argumentationen finden. Vielleicht kann man es als Karriereknick sehen – ich sehe es als Karrieresprung. Nur jemand mit großer Erfahrung, großem Wissen und einfach jeder Menge Menschlichkeit, kann diese Rolle ausfüllen und auch noch Spaß daran haben. Es ist eine Expertenrolle, die wirklich den Namen Experte verdient. Und das ist auch der Grund, warum ich als Software-Architektin nicht überflüssig bin.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

[1] https://en.wikipedia.org/wiki/Architect

Dr. Annegret Junker hat im t2informatik Blog weitere Beiträge veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.