Gedanken zur Organisation von Architektur

Wenn Sie Teil eines Unternehmens sind, werden Sie jeden Tag auf verschiedene Architekten treffen. Der eine stellt sich als Lösungsarchitekt vor, der andere nennt sich Unternehmensarchitekt, und beide erwähnen einen Domänenarchitekten. Es mag sich anfühlen wie verschiedene Namen für ein und dieselbe Sache, und vielleicht sogar eine noch größere Frage: Brauchen wir all diese verschiedenen Architekten überhaupt? Sollte das Team nicht in der Lage sein, all diese Architekturentscheidungen selbst zu treffen?

Brauchen wir überhaupt Architekten?

Wenn wir uns das aktuelle technologische und organisatorische Paradigma ansehen, können wir nur feststellen, dass sich die Welt massiv von der vor 10 oder 20 Jahren unterscheidet. Wir leben in einer Welt, in der wir über Cloud-Anbieter sofort auf Infrastruktur zurückgreifen können. Mit gängiger Software lassen sich Funktionen per Mausklick und mit einer Kreditkarte erwerben und integrieren.

Vorbei sind die Zeiten, in denen umfangreiche Projektpläne und Business Cases erstellt werden mussten. Sie müssen die vorgeschlagene Lösung für ein bestimmtes Problem nicht mehr mit dem Budgetverantwortlichen verhandeln. Keine langen Debatten mit anderen Ingenieuren über die angestrebte Lösung. Das ist gut für unsere Agilität, hat aber auch Konsequenzen.

Wertstromteams haben mehr Autonomie und Möglichkeiten erhalten, Hardware und Software auszuwählen, zu kaufen und zu integrieren. Wenn auch über Cloud-Anbieter, bei denen Sie Ihre Infrastruktur automatisch skalieren können, oder über Software-as-a-Service-Anbieter, die Ihnen Funktionen "out of the box" anbieten. Vorbei sind die Zeiten, in denen gut durchdachte Dokumente erstellt wurden, die von Kollegen im Unternehmen geprüft und getestet wurden.

Das kommt natürlich der Geschwindigkeit der Lieferung und der Flexibilität bei der Auswahl von Lösungen zugute. Folglich erfordert es aber auch mehr Reife von einem Team. Die vorgeschlagene Lösung und die getroffenen Entscheidungen müssen nicht nur in den Kontext des Teams, sondern auch in den der Organisation passen. Die Komplexität und der Druck, die Konsistenz und das beste Interesse für die Organisation als Ganzes zu wahren, lasten nun auf den Wertstromteams. Die Spannung, zwischen verschiedenen Optionen und Interessengruppen zu wählen, liegt nun allein in der Verantwortung des Teams.

Die Funktion des Architekten ist von entscheidender Bedeutung, wenn es darum geht, bewusste Entscheidungen zu treffen, die für die Kunden und das Unternehmen als Ganzes von Vorteil sind. Entweder durch Begrenzung der Anzahl der Optionen, die einem Team zur Verfügung stehen, oder durch Verfeinerung und Verbesserung der Argumentation und Akzeptanz von Kompromissen zwischen vorgeschlagenen Lösungen.

Eine Architektur, die von zwei Perspektiven geleitet wird

Zunächst einmal sind Architekturbereiche nicht als statische Elemente zu betrachten. Architekten sollten dynamisch sein und den Zweck des Managements in der Organisation und die technischen Herausforderungen der Entwicklungsteams verstehen. Gregor Hohpe beschreibt dies als eine Fahrt mit dem Fahrstuhl. Eine Möglichkeit, den Umfang zu bestimmen, ist ein Blick auf die Komplexität. Der Umfang der Komplexität eines Wertstromteams unterscheidet sich von der Komplexität eines ganzen Unternehmens.

Inspiriert von Ruth Malan und Dana Bredemeyer können wir das Modell verwenden, bei dem die Architekturfunktion in zwei Achsen organisiert werden kann: auf der vertikalen Achse befindet sich die Lokalität der Entscheidungsfindung und auf der horizontalen Achse die Komplexität und das Detail der Herausforderung:

Lassen Sie uns mit der Achse der Komplexität beginnen. Der Aufgabenbereich eines Teams betrifft oft eine begrenzte Anzahl von Komponenten, Microservices oder anderen Funktionalitäten. Das Hauptziel des Teams besteht darin, sicherzustellen, dass die Funktionalität der Komponente die Erwartungen des Kunden übertrifft oder erfüllt.

Wenn wir zu bereichsorientierten Einheiten, Geschäftsbereichen und Unternehmen aufsteigen, wird die Komplexität noch größer. Auf Geschäftsfeld- und Unternehmensebene beispielsweise sind die Belange anders gelagert als bei einem Team. Man muss die besten Interessen mehrerer Teams, kommerzielle Interessen und organisatorische Belange unter einen Hut bringen. Einfach ausgedrückt: Die Welt ist ein bisschen größer und zunehmend komplexer.

Die Entscheidungsfindung ist die andere Achse, die es zu berücksichtigen gilt, insbesondere die Auswirkungen einer Entscheidung. Die auf organisatorischer Ebene getroffenen Entscheidungen geben in der Regel Grenzen und Richtlinien für die Organisation vor. Diese sollen die Optionen für die kleineren Einheiten der Organisation begrenzen und dazu beitragen, dass diese Einheiten bessere Entscheidungen im besten Interesse der Einheit und der Organisation treffen können. Wir können sagen, dass die Verantwortung mit der Komplexität zunimmt und die Entscheidungsfindung mit der Lokalität:

Was ist mit der Rolle der Architektur?

Zunächst einmal sehen wir Architektur als eine Funktion. Eine Funktion, die an eine alltägliche Rolle delegiert werden kann, oder eine Funktion, die einer bestehenden Rolle zugewiesen wird. Dies könnte ein leitender Ingenieur sein oder einer Gruppe von Personen zugewiesen werden, z. B. dem Produktentwicklungsteam. Ein leitender Ingenieur oder Teamleiter kann als Tie-Breaker eingesetzt werden.

Für ein Unternehmen ist es wichtig, sich über die Einstellung der Architekten, die es einstellt und mit der es betraut, bewusst zu sein. Der Charakter und die Arbeitsweise der Architektenfunktion haben einen großen Einfluss auf die Ingenieurskultur. Wenn Sie einen wohlwollenden Diktator mit der Leitung beauftragen, hat dies andere Auswirkungen als ein Architekt, der das Team bei seinen Architekturentscheidungen coacht und unterstützt.

Allerdings kommt es hier auf den Kontext an. Ein Architekt für eine betriebsinterne Produktentwicklungsabteilung benötigt andere Fähigkeiten und Einstellungen als ein Architekt, der mit Anbietern zusammenarbeiten und eine erfolgreiche Integration sicherstellen muss. Der letztgenannte Architekt muss sich besser mit dem Management von Lieferanten und den entsprechenden Verhandlungen auskennen.

Brauche ich einen Architekten?

Auch hier kommt es auf den Kontext an und allgemeine Antworten können hier nicht gelten. Wir haben jedoch einige Überlegungen anzustellen.

• Haben Sie die Fähigkeiten und die Zeit, um die technischen Entscheidungen zu leiten? Können Sie, insbesondere als Leiter einer kleinen technischen Abteilung, die Zeit aufbringen, um den Entscheidungsprozess zu steuern? Aus der Perspektive von Zeit und Fähigkeiten.
• Lässt sich die Komplexität einer Organisationseinheit und die Auswirkung von Entscheidungen durch die gemeinsame Verantwortung einer Gruppe von Personen bewältigen? Im Falle einer Gruppe ausgereifter Hauptingenieure und eines klaren Entscheidungsrahmens könnte dies beispielsweise besser funktionieren als ein spezieller Bereichsarchitekt.

Wir sprechen hier zwar über die Funktion der Architektur, schlagen aber auch vor, dass diese Grundsätze und Leitlinien für eine breitere Palette von Disziplinen gelten. Design und Benutzererfahrung sind ein hervorragendes Beispiel dafür. Ein Designsystem ist gewissermaßen ein Entscheidungsrahmen, der die lokale Entscheidungsfindung ermöglicht und die Übereinstimmung mit der Unternehmensmarke und -erfahrung gewährleistet.