Enterprise Architektur Management mal persönlich
Um es gleich vorweg zu sagen: Ich bin Enterprise Architekt. Für viele Entscheider ist es irrelevant, ob sie mit einem Software Architekten oder einem Enterprise Architekten sprechen. IT-Architekt ist IT-Architekt. Aber würden Sie als Bürgermeister einem Bauzeichner die Planung der neuen Hafencity überlassen, oder würden Sie damit eher den Stadtplaner beauftragen? Das ist natürlich keine Bewertung der jeweiligen Rollen, es soll nur zeigen, dass es eben verschiedene Rollen für verschiedene Aufgaben gibt. In der noch sehr jungen IT-Disziplin sind die Unterschiede oft fließend. Wenn Sie an den Punkt gekommen sind, über Enterprise Architektur nachzudenken, gewinnt die Unterscheidung jedoch an Bedeutung.
Gestaltungsspielräume eröffnen
Was IT-Architekten (egal welcher Ausprägung) typischerweise antreibt, ist das Gestalten. Als EA gestaltet man primär durch das Vorbereiten und Treffen von Entscheidungen. Dazu muss man das Geschäft verstehen, Aufbau und Ziel der Organisation kennen und ein solides Wissen über technische Möglichkeiten besitzen. Wenn man das alles in einen verständlichen Zusammenhang setzen kann – sei es durch Worte, Skizzen, Diagramme und, ja, auf Folien – dann entsteht Mehrwert, indem Risiken minimiert, Kosten reduziert und Resilienz erhöht werden.
Das Erstellen exzellenter Systeme ist schwierig, insbesondere bei komplexen Systemen: Je mehr Schichten, mehr Integrationen, mehr Sponsoren, desto größer ist die Notwendigkeit, das Design früh zu kommunizieren – dann, wenn die Änderungskosten (noch) gering sind.
Mir ist wichtig, wohin eine Organisation geht, was sie daran hindert, dorthin zu gelangen, und wie wir Technologien nutzen können, um entweder schneller oder günstiger ans Ziel zu kommen.
Wie ein einzelnes System zusammengestellt wird, ist etwas für Anwendungs- und Lösungsarchitekten. Wie Daten innerhalb der Organisation fließen, ist etwas für Datenarchitekten. Ich konzentriere mich darauf, wie die gesamte Organisation funktioniert, wie sie ihre Kunden einbezieht und wie sie Wert für Mitarbeiter und (andere) Shareholder schafft. Meine früheren Erfahrungen als Analyst, Softwarenentwickler, Tester und Transformation Manager erleichtern es, die Brücke zwischen der IT und dem Business zu bauen.
Das böse G-Wort
Um gleich von Anfang an komplett transparent zu sein: Die Governance Aufgaben eines EAs haben mich nie hinterm Ofen hervorgelockt. Sinnlose Freigabeformulare ausfüllen, um Kontrolle vorzugaukeln? Auch das Audit-Argument habe ich nie gekauft. Nachverfolgbarkeit von Änderungen bekommt man eleganter, weniger zeitaufwändig und nachvollziehbarer hin. Und zwar indem man a) den Leuten (aka Nutzern) erklärt, warum manche (scheinbar sinnlosen) Dinge notwendig sind und indem man b) die richtigen, auf die Nutzer angepassten, Werkzeuge einsetzt.
Insbesondere in regulierten Branchen (Stichwort GxP) muss man manche Dinge einfach dokumentieren. Keine Diskussion. Aber Governance lässt sich nicht durch zeitfressende (häufig schlecht vorbereitete) Meetings erzwingen. Kommunikation und Verständnis sind wesentlich effektiver. Doch genau da liegt der Hase oft im Pfeffer: In diesen Meetings werden EAs als Polizisten wahrgenommen, die den Zeigefinger heben, wenn eine (im Zweifel unbekannte) Vorschrift (sprich Richtlinie oder Standard) nicht eingehalten wird. Ist es da verwunderlich, dass diesen Job keiner (mehr) machen will?
Und trotzdem ist es ab einer bestimmten Organisationsgröße nötig, Kontrollmechanismen für die Weiterentwicklung der IT-Landschaft zu etablieren. Wie bekommt man das hin, ohne die Motivation, Geschwindigkeit und Lieferfähigkeit autonomer, ständig nach Innovation strebender Teams zu hemmen? Nach meiner Erfahrung liegt der Schlüssel zum Erfolg 1) in Kommunikation und Unterstützung und 2) in der Automatisierung von Governance durch den Einsatz von Technologien wie AWS Chef. Das bedeutet auch, dass EAs aktiv in Projekten mitarbeiten.
Macht DevOps EA obsolet?
Welche Rolle haben Enterprise Architekten in einer komplett autonomen, stark automatisierten DevOps Welt (denn überhaupt noch)? DevOps kann zu besserer, schneller verfügbarer Software führen. Änderungen an der Anwendungslandschaft werden so häufig durchgeführt, dass in manchen Bereichen herkömmliche EA Aufgaben wie der Aufbau und die Pflege eines Software Repositories einen geringeren Mehrwert liefern.
Durch den Einsatz von DevOps verschwindet jedoch nicht die Notwendigkeit, die Organisation als Ganzes zu verstehen. Als System gedacht, besteht jede Organisation aus Teilen, die miteinander interagieren und voneinander abhängen. Eine Änderung an einem Teil bewirkt meist Änderungen in anderen Teilen. Jemanden zu haben, der diese Abhängigkeiten kennt und bewerten kann, ist manchmal extrem wertvoll (DevOps Horror Stories: https://www.contino.io/insights/5-devops-horror-stories).
An dieser Stelle ist es Zeit, die zu Beginn eingeführte Analogie zwischen Enterprise Architekt und Stadtplaner anzupassen. Die Flexibilisierung einer Organisation, d.h. ihrer Prozesse und Strukturen (zentral vs. dezentral), - und nichts anderes ist die Einführung von DevOps in einer IT-Organisation - wirkt natürlich auch auf die Enterprise Architektur. Statt die Rolle des Planers übernimmt ein EA in diesem Kontext zunehmend die Rolle des strategischen Gärtners (ich weiß, gewagter Kunstbegriff). Denn während ersterer „Bauvorhaben“ auf Basis von Bebauungsplänen und Vorschriften genehmigt oder ablehnt, weiß letzterer, dass es unmöglich ist, jedes Unkraut zu vermeiden. Der Fokus seiner Arbeit liegt darauf, die „Gewächse“ in den einzelnen Bereichen des Gartens zu pflegen oder eben zu trimmen.
Ok, genug der blumigen Beschreibungen.