Der Software-Architekt-Aufzug

Kapitel 4. Unternehmensarchitekt oder Architekt im Unternehmen?

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Die oberen und unteren Stockwerke des Elfenbeinturms

Architektur aus dem Elfenbeinturm

Als ich als Unternehmensarchitektin, genauer gesagt als Leiterin der Unternehmensarchitektur, eingestellt wurde, hatte ich wenig Ahnung, was Unternehmensarchitektur wirklich bedeutet. Ich fragte mich auch, ob mein Team die "Füße der Unternehmensarchitektur" heißen sollte, aber diese Überlegung stieß nicht auf viel Gegenliebe. Der Grund für die Tendenz, Titeln das Wort "Head of" voranzustellen, wurde in einem Online-Forum, auf das ich gestoßen bin, treffend beschrieben:¹

Dieser Titel impliziert in der Regel, dass der Kandidat einen Direktor-/VP-/Executive-Titel anstrebte, die Organisation sich aber weigerte, den Titel zu erweitern. Durch diese Verschleierung erscheint der Kandidat nach außen hin ranghöher, ohne die internen Wähler zu verärgern.

Ich mag den Titel "Leiter/in von xyz" nicht besonders, weil er sich auf die Person konzentriert, die ein Team leitet (kein Wortspiel beabsichtigt), anstatt eine bestimmte Funktion zu erfüllen. Ich würde die Person lieber nach dem benennen, was sie erreichen muss, wobei ich davon ausgehe, dass sie das nicht alleine tut, sondern ein Team hat, das sie unterstützt.

Abgesehen von den Titelpräfixen ist die erste Reaktion der IT-Mitarbeiter, wenn sie einen Unternehmensarchitekten treffen, diese Person hoch oben im Penthouse zu platzieren(Kapitel 1), wo sie hübsche Bilder malen, die wenig Ähnlichkeit mit der Realität haben. Um von den IT-Mitarbeitern freundlicher empfangen zu werden, sollte man daher mit der Bezeichnung Unternehmensarchitekt/in vorsichtig sein. Aber wie soll man einen Architekten, der auf Unternehmensebene arbeitet, dann nennen?

Unternehmensarchitektur

Die immer wiederkehrende Herausforderung bei der Bezeichnung Unternehmensarchitekt/in besteht darin, dass sie eine Person beschreiben könnte, die das Unternehmen als Ganzes architektiert (einschließlich der Ebene der Geschäftsstrategie) oder jemanden, der IT-Architektur auf Unternehmensebene betreibt (im Gegensatz zu einem/einer Abteilungsarchitekten/in, zum Beispiel).

Um diese Unklarheit zu beseitigen, sollten wir das wichtigste Buch zu diesem Thema zu Rate ziehen: Enterprise Architecture as Strategy von Jeanne Ross, Peter Weill und David Robertson.² Hier erfahren wir Folgendes:

Die Unternehmensarchitektur ist die Organisationslogik für Geschäftsprozesse und IT-Infrastruktur, die die Integrations- und Standardisierungsanforderungen des Betriebsmodells des Unternehmens widerspiegelt.

Nach dieser Definition ist die Unternehmensarchitektur (EA) keine reine IT-Funktion, sondern berücksichtigt auch die Geschäftsprozesse, die Teil des Betriebsmodells eines Unternehmens sind . Das bekannteste Diagramm des Buches zeigt vier Quadranten, die Geschäftsmodelle mit einem höheren oder niedrigeren Grad an Prozessstandardisierung (Einheitlichkeit zwischen den Geschäftsbereichen) und Prozessintegration (gemeinsame Nutzung von Daten und Verknüpfung von Prozessen) darstellen. Anhand von Branchenbeispielen für alle Quadranten ordnen Weill und Robertson jedes Modell einer geeigneten IT-Architekturstrategie auf hoher Ebene zu. Ein Programm zur Daten- und Prozessintegration könnte zum Beispiel wenig Nutzen bringen, wenn das Geschäftsmodell aus stark diversifizierten Geschäftseinheiten mit wenigen gemeinsamen Kunden besteht. In solchen Unternehmen sollte die IT stattdessen eine gemeinsame Infrastruktur bereitstellen, auf der die einzelnen Abteilungen ihre unterschiedlichen Prozesse implementieren können. Umgekehrt profitiert ein Unternehmen, das aus weitgehend identischen Einheiten besteht, wie z. B. ein Franchise-Unternehmen, von einer hochgradig standardisierten Anwendungslandschaft. Die Matrix zeigt perfekt, wie EA die Verbindung zwischen dem Unternehmen und der IT herstellt. Nur wenn die beiden gut aufeinander abgestimmt sind, kann die IT dem Unternehmen einen Mehrwert bieten.

Business und IT miteinander verbinden

Die Verknüpfung von Geschäft und IT ist einfacher, wenn auch die Geschäftsseite des Unternehmens über eine gut definierte Architektur verfügt. Glücklicherweise hat der Begriff der Geschäftsarchitektur in den letzten Jahren stark an Bedeutung gewonnen, da die Geschäftsumgebungen immer komplexer werden und digitale Disruptoren traditionelle Unternehmen dazu zwingen, ihre Geschäftsmodelle schneller weiterzuentwickeln. Die Geschäftsarchitektur überträgt die strukturierte, architektonische Denkweise(Kapitel 8), die sich an einer formalisierten Sichtweise der Komponenten und Zusammenhänge orientiert, auf den Unternehmensbereich. Anstatt technische Systemkomponenten miteinander zu verbinden und über technische Systemeigenschaften wie Sicherheit und Skalierbarkeit nachzudenken, beschreibt die Geschäftsarchitektur "die Struktur des Unternehmens im Hinblick auf seine Führungsstruktur, Geschäftsprozesse und Geschäftsinformationen".³

Die Geschäftsarchitektur definiert im Wesentlichen das Betriebsmodell des Unternehmens, einschließlich der Struktur und Integration der Geschäftsbereiche, die sich aus der Geschäftsstrategie ableiten. In der IT-Architektur werden die entsprechenden IT-Funktionen festgelegt. Wenn die beiden nahtlos nebeneinander funktionieren, brauchst du nicht viel mehr. In dem wahrscheinlichen Fall, dass die beiden nicht gut miteinander verbunden sind, brauchst du etwas, das sie zusammenführt. Deshalb schlage ich folgende Definition der Unternehmensarchitektur vor :

Die Unternehmensarchitektur ist der Klebstoff zwischen Geschäfts- und IT-Architektur.

Diese Definition verdeutlicht, dass EA, anders als die IT-Architektur auf Unternehmensebene, keine IT-Funktion ist. Dementsprechend sollte das EA-Team in der Nähe der Unternehmensleitung angesiedelt sein und nicht tief in der IT-Organisation vergraben sein, damit es geschäftliche, technische und organisatorische Überlegungen in Einklang bringen kann.

Die Definition impliziert auch, dass man nicht viel EA braucht, wenn Business und IT eng miteinander verknüpft sind, was ein Grund dafür ist, dass man bei den sogenannten digitalen Giganten nicht viel EA findet.

Beispiel 4-1.

Die meisten digitalen Giganten haben keine EA-Abteilungen, weil ihr Geschäft und ihre IT eng miteinander verflochten sind.

Aber keine Panik! Der Spagat zwischen Geschäftsanforderungen und IT-Architektur ist ein Bereich, in dem es immer wieder an Talenten mangelt. Es scheint, dass die meisten Leute sich auf der einen oder anderen Seite des Zauns wohlfühlen, aber nur wenige können in beiden Welten glaubwürdig mitspielen und entscheiden sich auch dafür. Es ist eine gute Zeit, um Unternehmensarchitekt/in zu sein.

IT ist vom Mars, Business von der Venus

Die strikte Trennung zwischen IT und Geschäft, die in Unternehmen häufig anzutreffen ist, scheint mir problematisch zu sein. Ich neige dazu, darüber zu scherzen, dass es früher, als alles noch auf Papier statt auf Computern lief, in den Unternehmen auch keine separate "Papier"-Abteilung und keinen CPO - Chief Paper Officer - gab. In digitalen Unternehmen sind Geschäft und IT untrennbar miteinander verbunden: Die IT ist das Geschäft, und das Geschäft ist die IT.

Die Verbindung von Business und IT gibt EA eine ganz neue Bedeutung, aber auch neue Herausforderungen. Es ist, als würde man einen Aufzug in der Mitte des Stockwerks einbauen, der die Geschäftsleute im Penthouse mit den IT-Leuten im Maschinenraum verbindet, weil die jeweiligen Aufzüge nicht ganz bis zueinander reichen. Obwohl sie sehr wertvoll ist, muss das Ziel einer solchen Abteilung für Unternehmensarchitektur auf lange Sicht sein, sich selbst überflüssig oder zumindest kleiner zu machen, indem sie die jeweiligen Aufzüge verlängert. Aber keine Sorge, die rasanten Veränderungen sowohl im geschäftlichen als auch im technischen Umfeld machen es unwahrscheinlich, dass der Bedarf an Unternehmensarchitektur ganz verschwindet.

Der Aufbau einer fruchtbaren, bidirektionalen Verbindung zwischen Geschäfts- und IT-Architektur wird einfacher, wenn die Geschäftsarchitektur einen vergleichbaren Reifegrad wie die IT-Architektur aufweist. In den meisten Fällen ist die Geschäftsarchitektur jedoch noch weniger ausgereift als die IT-Architektur. Das liegt nicht daran, dass die Unternehmen keine Architektur hatten, sondern daran, dass die Leute, die für die Geschäftsarchitektur zuständig waren, nicht als solche identifiziert wurden, sondern als Geschäftsleiter, Abteilungsleiter oder COOs. Außerdem wurde die Gestaltung des Unternehmens eher dem Geschäftssinn als dem strukturierten Denken zugeschrieben. Wenn das Unternehmen architekturähnliche Artefakte erstellte, handelte es sich oft um "funktionale Fähigkeitspläne", die keine Linien enthielten(Kapitel 23).

Die Unterstützung des Geschäfts ist das oberste Ziel und die Daseinsberechtigung aller Unternehmensfunktionen. Die Positionierung der IT-Architektur auf Augenhöhe mit der Geschäftsarchitektur macht jedoch deutlich, dass die Zeiten, in denen die IT ein einfacher Auftragsabwickler war, der eine Standardressource zu möglichst niedrigen Kosten bereitstellte, (glücklicherweise) vorbei sind. Im digitalen Zeitalter ist die IT ein Unterscheidungsmerkmal im Wettbewerb und eine Chance, nicht eine Ware wie Strom.

Hinweis

Digitale Giganten wie Google oder Amazon sind keine Technologieunternehmen; sie sind Werbe- oder Fulfillment-Unternehmen, die es verstehen, Technologie als Wettbewerbsvorteil zu nutzen.

Die gängige Ausrede, dass "Google und Amazon Technologieunternehmen sind, während wir eine Versicherungsgesellschaft/Bank/ein Fertigungsunternehmen sind", gilt daher nicht mehr. Diese Unternehmen werden mit dir konkurrieren, und wenn du wettbewerbsfähig sein willst, musst du auch deine Sicht auf die IT ändern. Das ist nicht einfach, aber die digitalen Giganten haben gezeigt, wie mächtig diese Erkenntnis ist.

Wertorientierte Architektur

Der Umfang und die Komplexität der Architektur im Unternehmensmaßstab machen IT-Architektur im großen Maßstab spannend, bergen aber auch eine der größten Gefahren. Es ist viel zu leicht, sich in dieser Komplexität zu verlieren und eine interessante Zeit mit ihr zu verbringen, ohne jemals greifbare Ergebnisse zu erzielen. Solche Fälle sind die Ursache für das Klischee, dass EA im Elfenbeinturm sitzt und nur wenig Wert liefert. EA-Teams müssen daher einen klar formulierten Weg zur Wertschöpfung haben: Jede Anstrengung muss sich auszahlen, indem sie dem Unternehmen einen Nutzen bringt.

Eine weitere Gefahr liegt in den langen Feedback-Zyklen. Die Beurteilung, ob jemand eine gute EA macht, dauert sogar noch länger als die Beurteilung einer guten Anwendungsarchitektur. Auch wenn die digitale Welt kürzere Zyklen erzwingt, erstrecken sich viele EA-Pläne immer noch über drei bis fünf Jahre. So kann die Unternehmensarchitektur zu einem Schlupfwinkel für Möchtegern-Kartographen werden. Aus diesem Grund müssen Unternehmensarchitekten Wirkung zeigen(Kapitel 5).

Narren mit Werkzeugen

Einige Unternehmensarchitekten arbeiten eng mit einem bestimmten EA-Tool zusammen, das die verschiedenen Aspekte der Unternehmenslandschaft erfasst. Diese Tools ermöglichen eine strukturierte Zuordnung von Geschäftsprozessen und Fähigkeiten, die idealerweise von den Unternehmensarchitekten erstellt werden, zu IT-Assets wie Anwendungen und Servern.

Hinweis

Sorge dafür, dass deine Werkzeuge für dich arbeiten und nicht umgekehrt!

Wenn sie gut gemacht sind, können sie als strukturiertes Repository die Brücke zwischen Geschäfts- und IT-Architektur schlagen. Wenn sie schlecht gemacht sind, werden sie zu einem nicht enden wollenden Erkundungs- und Dokumentationsprozess, der zu einem Ergebnis führt, dem ein Schwerpunkt fehlt(Kapitel 21) und das bei seiner Veröffentlichung bereits veraltet ist. Es erübrigt sich zu sagen, dass ein solches Dokument wenig Wert hat.

Alle Etagen besuchen

Meine Definition von EA impliziert auch, dass einige IT-Architekten, die keine Unternehmensarchitekten sind, auf Unternehmensebene arbeiten. Das sind größtenteils die Leute, auf die ich mich in diesem Buch beziehe. Sie sind die Techniker, die gelernt haben, mit dem Aufzug(Kapitel 1) in die oberen Etagen zu fahren, um sich mit dem Management und den Business-Architekten auszutauschen, und sind daher ein entscheidendes Element bei jeder IT-Transformation.

Wie unterscheidet sich ein "Enterprise-Scale-Architekt" von einem "normalen" IT-Architekten? Zunächst einmal ist alles größer. Viele große Unternehmen sind Konglomerate aus verschiedenen Geschäftseinheiten und Abteilungen, von denen jede ein Multimilliarden-Dollar-Unternehmen sein kann und ein anderes Geschäftsmodell verfolgt. Je größer die Dinge werden, desto mehr Altlasten gibt es auch: Unternehmen wachsen im Laufe der Zeit oder durch Übernahmen, was beides zu Altlasten führt. Dieses Erbe beschränkt sich nicht nur auf die Systeme, sondern auch auf die Mentalität und Arbeitsweise der Menschen. Unternehmensarchitekten müssen daher in der Lage sein, sich in Organisationen(Kapitel 34) und komplexen politischen Situationen zurechtzufinden.

Echte EA zu betreiben ist genauso komplex und wertvoll wie das Beheben eines Java-Gleichzeitigkeitsfehlers. Die Komplexität ist auf allen Ebenen enorm, aber die gute Nachricht ist, dass du auf den verschiedenen Ebenen ähnliche Denkmuster anwenden kannst. Softwarearchitekten müssen zum Beispiel die Granularität ihres Systems und die gegenseitigen Abhängigkeiten abwägen: Ein riesiger Monolith ist ziemlich unflexibel, während tausend kleine Dienste schwer zu verwalten sind und einen erheblichen Kommunikationsaufwand verursachen können. Genau dieselben Überlegungen gelten für die Unternehmensarchitektur, wenn es um die Größe von Abteilungen und Produktlinien geht. Schließlich steht EA auch vor den gleichen Kompromissen, wenn es darum geht, zu entscheiden, welche Systeme zentralisiert werden sollen, was die Verwaltung vereinfacht, aber auch die lokale Flexibilität einschränken kann. Architektur, wenn sie ernst genommen wird, bietet auf allen Ebenen einen erheblichen Nutzen.

Unternehmen ähneln einer fraktalen Struktur: Je mehr man hinein- oder herauszoomt, desto ähnlicher sehen die Dinge aus. Der Kurzfilm Powers of 10, der 1977 von Charles und Ray Eames für IBM produziert wurde ( ), veranschaulicht dies sehr schön: Der Film zoomt von einem Picknick in Chicago alle 10 Sekunden um eine Größenordnung heraus, bis er ${10}^{24}$und zeigt ein Meer von Galaxien. Anschließend zoomt er heran, bis bei ${10}^{-18}$ das Reich der Quarks zu sehen ist. Interessanterweise sehen die beiden Ansichten gar nicht so unterschiedlich aus .

¹ Keith Rabois, Quora, 11. Mai 2010, "Was bedeutet "Head" normalerweise in Jobtiteln wie "Head of Social", "Head of Product", "Head of Sales" usw.?", https://oreil.ly/5LmbY.

² Jeanne W. Ross, Peter Weill, und David C. Robertson, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution (Boston, MA: Harvard Business Review Press, 2006).

³ Website der Object Management Group, http://www.omg.org/bawg.