Was macht Unternehmensarchitektur wirklich aus? Nach mehr als drei Jahrzehnten in der Praxis bin ich überzeugt: Es sind nicht die Frameworks, nicht die Tools und nicht die Zertifikate. Es sind fünf grundlegende Einsichten, die darüber entscheiden, ob EA-Arbeit Wirkung entfaltet oder im Leeren läuft.
Architektur ist kein technisches Problem
Kernthese: EA ist kein technisches, sondern ein organisatorisches und menschliches Problem. Die eigentliche Herausforderung liegt nicht in der Auswahl des richtigen Tools oder Frameworks, sondern in der Fähigkeit, Menschen, Prozesse und Entscheidungsstrukturen zusammenzubringen.
Evidenz: In der Praxis scheitern EA-Initiativen selten an technischen Unzulänglichkeiten. Sie scheitern an fehlendem Commitment des Managements, an politischen Widerständen, an unklaren Verantwortlichkeiten oder daran, dass Architekturarbeit schlicht nicht als wertschöpfend wahrgenommen wird. Wer jemals versucht hat, ein Architecture Review Board einzuführen, kennt das Phänomen.
Konsequenz: Enterprise-Architekten müssen vor allem Kommunikatoren, Moderatoren und politisch versierte Gestalter sein. Technisches Wissen ist notwendig, aber nicht hinreichend. Der Architekt, der sich in seinem Modellierungstool vergraben hat, wird weniger Wirkung entfalten als derjenige, der die richtigen Gespräche führt.
Komplexität ist nicht wegzurationalisieren
Kernthese: Unternehmen sind komplexe soziotechnische Systeme. Diese Komplexität lässt sich nicht durch Methoden, Frameworks oder Modelle eliminieren – sie lässt sich allenfalls handhaben. Wer glaubt, mit dem richtigen Framework alle Architekturprobleme lösen zu können, unterliegt einem gefährlichen Irrtum.
Evidenz: TOGAF, ArchiMate, COBIT – alle diese Standards sind wertvolle Hilfsmittel. Aber keines davon hat je ein Unternehmen transformiert. Die Realität zeigt: Je größer und älter ein Unternehmen, desto gewachsener und verwobener seine IT-Landschaft. Kein Modell kann diese Wirklichkeit vollständig abbilden. Modelle sind immer Vereinfachungen – und Vereinfachungen lassen immer etwas weg.
Konsequenz: Der reife Enterprise-Architekt akzeptiert Komplexität als gegeben. Er strebt nicht nach der perfekten Architektur, sondern nach der besseren. Sein Werkzeugkasten ist groß, aber er wählt pragmatisch das jeweils Passende – und nicht das Vollständigste. „Gut genug" ist oft besser als „perfekt auf dem Papier".
Frameworks sind Mittel, keine Ziele
Kernthese: Es gibt eine verbreitete Neigung in der EA-Community, Frameworks zu fetischisieren. TOGAF-Zertifizierung, ArchiMate-Konformität, COBIT-Compliance – all das wird zum Selbstzweck, obwohl es eigentlich nur Mittel zum Zweck sein sollte. Das Ergebnis ist häufig ein aufwändiger Methodenapparat, der mehr Energie verschlingt als er freisetzt.
Evidenz: Organisationen, die ihren EA-Prozess primär um ein Framework herum aufbauen, verlieren häufig den Blick fürs Wesentliche: Welchen konkreten Beitrag leistet die Architekturarbeit zum Geschäftserfolg? Die Antwort auf diese Frage findet sich nicht im Framework-Handbuch.
Konsequenz: Frameworks sollten als Checklisten und Orientierungshilfen genutzt werden – nicht als Vorschriften. Ein guter Architekt kennt die Standards, aber er ist ihnen nicht verpflichtet. Er passt sie an seinen Kontext an, lässt weg, was nicht nützt, und ergänzt, was fehlt. Architektur ist Handwerk, keine Compliance-Übung.
Architektur entsteht immer im Kontext
Kernthese: Unternehmensarchitektur existiert nicht im Vakuum. Sie entsteht in einem spezifischen organisatorischen, kulturellen, historischen und politischen Kontext. Eine Architekturentscheidung, die in Unternehmen A funktioniert, kann in Unternehmen B scheitern – nicht weil sie technisch falsch ist, sondern weil der Kontext ein anderer ist.
Evidenz: Best Practices sind kontextgebunden. Was bei einem Finanzdienstleister mit strenger Regulatorik sinnvoll ist, passt möglicherweise nicht zu einem agilen Startup. Was in einer zentralisierten Organisation funktioniert, schlägt fehl in einer föderalen Struktur. Die Geschichte der IT ist voll von Projekten, die theoretisch richtig, praktisch aber gescheitert sind.
Konsequenz: Vor jeder Architekturentscheidung steht die Kontextanalyse. Wer ist betroffen? Welche Machtstrukturen existieren? Was sind die treibenden Kräfte und die bremsenden Widerstände? Ein guter Architekt ist auch ein guter Analytiker seiner eigenen Organisation.
Strategie schlägt Planung
Kernthese: Architektur ist strategische Arbeit. Sie muss aus der Geschäftsstrategie abgeleitet sein und auf sie einzahlen. Ein IT-Zielbild ohne Verankerung in der Unternehmensstrategie ist ein Konstrukt ohne Fundament – es mag technisch beeindruckend sein, aber es wird keine Unterstützung finden und keine Wirkung entfalten.
Evidenz: Viele EA-Initiativen beginnen mit dem Tool, nicht mit der Strategie. Man kauft ein Repository, befüllt es mit Daten – und fragt sich am Ende, warum niemand damit arbeitet. Der Grund: Es fehlt die strategische Anbindung. Architekturarbeit, die nicht zur Lösung realer Geschäftsprobleme beiträgt, wird als Overhead wahrgenommen.
Konsequenz: Der Enterprise-Architekt muss die Geschäftsstrategie verstehen – und aktiv mitgestalten. Er sitzt nicht am Ende der Kette und übersetzt Vorgaben in IT-Strukturen. Er ist von Anfang an dabei, wenn strategische Entscheidungen getroffen werden. Sein Beitrag ist es, die technische und organisatorische Machbarkeit sicherzustellen – und frühzeitig auf Risiken hinzuweisen.
Mein Fazit
Enterprise-Architektur ist kein Selbstläufer und kein Selbstzweck. Sie ist eine anspruchsvolle, kontextsensitive Disziplin, die technisches Verständnis mit organisatorischer Klugheit und strategischem Denken verbindet. Wer sie auf Methoden und Tools reduziert, wird enttäuscht sein. Wer sie als das versteht, was sie ist – ein Instrument zur kontinuierlichen Gestaltung komplexer Organisationen – wird einen echten Beitrag leisten.
Pragmatismus bleibt der Schlüssel.