Wenn Sie Nachwuchs haben, kommt irgendwann der Moment, wo dieser Sie fragen wird, womit Sie eigentlich so Ihre Brötchen verdienen. Hier ist man schnell der Held, wenn man Astronaut ist, was außerdem noch den Vorteil hat, dass es recht einfach zu erklären ist. Leider ist dies eher selten der Fall. Was können Sie tun, wenn Sie für die komplexe Softwarearchitektur beispielsweise eines Finanzkonzerns verantwortlich sind? Dann wird es um so schwieriger, und das obwohl die Bezeichnung „Held“, wenn man denn damit erfolgreich ist, hier auch gar nicht so unangebracht wäre.

Herbert Dowalil, Im Märchenschloss – kinderleichte Enterprise Architektur

Abbildung 1: Märchenschloss, gebaut von Valentina Dowalil.

Eines vorweg: dieser Artikel wird nicht von der Art Enterprise Architektur, welche auf einer so hohen Abstraktionsebene tätig ist, dass sie versucht Softwarearchitektur und Business gemeinsam zu betrachten, handeln. Solche Unterfangen zeichnen sich üblicherweise durch eine mehr oder weniger vollständige Ergebnisfreiheit aus, weshalb ich mich lieber auf einen anderen Aspekt konzentriere: Es wird vielmehr darum gehen, wie eine sehr komplexe Architektur, welche von mehreren Teams gleichzeitig bearbeitet wird, auf Dauer produktiv und flexibel bleibt. Und dies wird imho ausschließlich durch effiziente Strukturierung und Modularisierung erreicht. Ich bezeichne so etwas übrigens lieber als strukturelle Makro Architektur, da mir der Terminus Enterprise Architektur schon länger mit viel zu vielen negativen Aspekten überfrachtet scheint.

Ein sehr weiser Physiker hat einmal gemeint, dass man etwas selber nicht verstanden hat, wenn man es nicht einem sechsjährigen Kind erklären könnte. Wenn mich auch interessiert, wie er dies mit seiner Allgemeinen Relativitätstheorie angehen würde, so stimme ich dieser Ansicht weitgehend zu. Praktischerweise habe ich zurzeit ein entzückendes Kindergartenkind zuhause, nämlich meine kleine Tochter Valentina. Wie abstrakt mein Job ist, fällt mir immer genau dann auf, wenn sie mich fragt, was ich eigentlich den ganzen Tag so mache. Gar nicht so einfach, aber demnach eine willkommene Gelegenheit, um zu überprüfen, ob man eigentlich selber noch weiß, was man so tut.

Die Erklärung

Nun, liebe Valentina, stell dir einmal vor, dein Regenbogen-Kindergarten bekäme den Auftrag von den Eltern (in diesem Beispiel die Kunden), eine besonders großes Prinzessinnenschloss aus Bausteinen zu bauen. Es soll sowohl einen Turm mit 2 Stockwerken und einem Dach haben, als auch einen Thronsaal, Schlafgemächer und einen Ponystall. Stehen soll das Ganze auf einem soliden passenden Fundament, so wie in Abb. 2 dargestellt. Jede der Gruppen, die aus jeweils etwa 15 Kindern besteht, wäre alleine mit der Aufgabe aufgrund Ihres Umfangs überfordert. Es bliebe also eurer Kindergartenleitung nichts anderes übrig, als diese Tätigkeit auf die 4 Gruppen aufzuteilen. Tatsache ist aber, dass sich die Prinzessinnen, die später darin wohnen sollen, dort auch zurechtfinden und wohlfühlen sollen. Es soll möglich sein, von einem Raum in den anderen zu wechseln, von einem Stockwerk ins andere, und auch von einem Abschnitt in einen anderen. Wie koordiniert man die Komplexität eines solchen Vorhabens und teilt es auf 4 Gruppen zu jeweils 15 Kindern auf?

Die Kunst liegt demnach darin, das gesamte Unterfangen in 4 Teilaufgaben zu teilen, die danach möglichst autonom erledigt werden können, und am Ende dann trotzdem gut zusammenpassen. Es lohnt sich also, sich den Plan gemeinsam mit den Eltern (= Auftraggebern) nochmal etwas näher anzusehen bevor man loslegt. Da es 4 Gruppen gibt, könnte man dazu tendieren, jedes Team mit dem Bau eines Stockwerkes bzw. dem Fundament zu beauftragen. Dies würde aber dazu führen, dass sich die Gruppen über den Querschnittplan des Schlosses auf jeder Ebene einig werden müssten, und außerdem komplexe Dinge wie die Statik des Schlosses über die Gruppen hinweg zu koordinieren wären. Es würde eine laufende Abstimmung durch die Gruppenbetreuerinnen organisiert werden müssen, weil die Kinder im Zuge der Erstellung der Stockwerke jede Menge dazulernen werden. Die Alternative wäre, die Aufgaben entlang der vertikalen Strukturen des Schlosses aufzuteilen, wodurch sich die Gruppen nur auf die Position und den Umfang der Türrahmen wird einigen müssen, was mit Sicherheit wesentlich einfacher ist. Die Kinder können sich dann die allermeiste Zeit auf das konzentrieren, was ihnen am meisten Spaß macht, nämlich das Spiel mit den Bauklötzen. Dadurch wird es dem Kindergarten auch nie an ausreichend Kindern (= Mitarbeitern) fehlen.

Aber Papa…

Schlau und skeptisch wie meine Tochter ist, hatte sie an der Stelle natürlich etwas einzuwenden: Was ist mit der Farbe? Die einzelnen Trakte sollen doch nachher optisch zusammenpassen? Außerdem muss sich irgendjemand um das Fundament kümmern. Das ist natürlich richtig, und wäre am besten durch die Kindergartenleitung organisiert. Aus jeder Gruppe werden die Kinder genommen, die sich für das jeweilige Querschnitts-Thema (wie farblich optische Abstimmung) am meisten interessieren. Diese würden sich dann regelmäßig in sogenannten „Communities of Practice“ treffen, um diese Dinge abzustimmen.

So ein Vorgehen setzt allerdings eine Sache voraus: Dass die Kindergartenleitung den einzelnen Gruppenbetreuerinnen (= Führungskräften) und in weiterer Folge auch den Kindern (= Mitarbeitern) ein gewisses Maß an Vertrauen entgegenbringt. Wenn sie das nicht tut, wird sie viel eher danach trachten, die einzelnen Tätigkeiten genau in ihrem Sinne zu standardisieren, verschiedene Aufgaben konkreten Rollen zuzuweisen, und so versuchen, auf die Erstellung des Schlosses konkret Einfluss zu nehmen. Wenn Sie schonmal zuhause einen Kindergeburtstag organisiert haben, dann können Sie sich vielleicht vorstellen, wie einfach es ist, das Handeln von 60 Kindern von einer zentralen Stelle aus zu koordinieren.

Was kann sonst noch schiefgehen?

Nun, die Kindergartenleitung könnte auf einen Verkäufer reinfallen, der meint, er hätte einen fertigen zentralen Trakt für das Schloss anzubieten. Es wird eine zusätzliche Gruppe gegründet, die sich nur um diesen zentralen Trakt kümmern. Bei jeder Änderung an einem der Trakte, die tatsächlich von den Eltern gewünscht wurden, müssen sich die Erbauer derselben mit der neuen 5. Gruppe abstimmen. Wenn es ein Problem im zentralen Trakt geben sollte, so kommt man danach auch nicht mehr aus irgendeinem der Trakte in einen anderen. In der Welt der Makro Architektur entspricht dies wenig überraschend einem Enterprise Service Bus oder ESB. Überraschend ist es allerdings, wie oft dieses Antipattern immer wieder gefunden wird. In letzter Zeit werden gerne API Gateways oder auch Apache Kafka als Vorwand genommen, für die Implementierung solch zentraler Logik.

Woran merkt man, dass im Kindergarten etwas schiefläuft?

Außer Kontrolle geraten ist das Unterfangen Schlossbau dann, wenn die Organisation die Kinder eher vom Bau abhält, als sie dabei zu unterstützen. Sobald die Anzahl der Betreuerinnen die Anzahl Kinder übersteigt, haben Sie bereits ein Problem. Dasselbe gilt, wenn die Kinder mehr Zeit mit Abstimmungen ihrer Arbeit untereinander verbringen, als mit dem Spiel mit den Bauklötzen selbst. Die Meta-Arbeit, welche nur da ist um die Reibungslosigkeit der eigentlichen Arbeit zu koordinieren, würde dann diese tatsächliche Arbeit übersteigen. In so einem Fall wird es schwierig, begabte Kinder weiterhin für genau diesen Kindergarten zu begeistern. Solche Bürokratien entwickeln auf Dauer nämlich nicht selten ein Eigenleben und werden dann als eine Art Kult zelebriert. Im Sinne der Eltern, oder der Kinder, ist dies allerdings keineswegs.

Fazit

Wenn die eigene Arbeit eine sehr komplexe ist, kann die Neugier eines Kleinkindes ab und an ganz hilfreich sein, wenn man sich die Frage stellen möchte, ob man in seinem Tun nicht bereits etwas den Faden verloren hat. Im Kern geht es nämlich bei Softwarearchitektur immer noch darum, ein großes Ausmaß an Komplexität in geordnete Bahnen zu lenken. Wenn man dieses Gleichnis betrachtet, so darf die Frage erlaubt sein, warum es in den meisten Enterprise inhouse-ITs bereits zu einer Art Stillstand kommt, was die Produktivität in der Weiterentwicklung der Softwarelandschaft angeht. Abgesehen davon, dass sich viele Unternehmensführungen schlichtweg weigern, sich dieses Scheitern einzugestehen, ist es oft nicht so einfach zu erkennen, an welchen Grenzen man die Arbeit der Teams am besten aufteilt. Üblicherweise sind die besseren Grenzen nämlich um die einzelnen Teilbereiche der Problemdomäne herum zu ziehen, und nicht um technische Aspekte, wie Userinterface, Orchestrierung (ESB), Logik und Persistenz (DB). Und selbstverständlich macht es, nach Conway´s Law, dann nur Sinn, die Teams auch genau um diese Boundaries in der Software herum zu organisieren. Hierzu ist es nötig, dass das Management diesen fachlich orientierten Teams es zutraut, sich um all die technischen Aspekte die jeweils anfallen in ausreichender Qualität selbständig kümmert, und ihnen auch den Freiraum gibt, sich in ausreichendem Ausmaß dazu abzustimmen. Üblicherweise klappt es dann auch mit dem gerne allgemein beklagten Personalmangel in der IT.

Im Märchenschloss – kinderleichte Enterprise Architektur, Abbildung 2: Schloss

Abbildung 2: Schloss