Enterprise Architecture beginnt nicht mit TOGAF. Sondern mit der Frage, was das Unternehmen können muss.

Viele denken bei Enterprise Architecture zuerst an IT-Standards, Governance, Architekturdiagramme oder Frameworks wie TOGAF und ArchiMate. Das gehört dazu.

Aber es ist nicht der Anfang.

Der eigentliche Anfang liegt früher – bei der Frage:

Was muss unser Unternehmen können, um sein Geschäftsmodell heute und morgen erfolgreich zu betreiben?

Genau hier beginnt Business Architecture.

Zuerst die Begriffe definieren:

Die Begriffe Business Architecture und Enterprise Architecture lassen sich nicht besonders elegant ins Deutsche übersetzen.

„Geschäftsarchitektur“ klingt schnell abstrakt.„Unternehmensarchitektur“ klingt oft nach IT-Landschaft. Beides greift zu kurz.

Deshalb hilft es, die Begriffe über ihre Funktion zu verstehen.

Business Architecture beschreibt die strukturierte Sicht auf das Geschäft:

• Welche Fähigkeiten braucht das Unternehmen?

• Welche Prozesse sind kritisch?

• Wo entsteht Wert?

• Welche Verantwortlichkeiten gibt es?

• Welche Zielgruppen werden bedient?

• Welche regulatorischen Anforderungen wirken auf das Geschäftsmodell?

• Welche Veränderungen im Operating Model sind notwendig?

Oder einfacher:

Business Architecture macht sichtbar, was ein Unternehmen können muss – und wie diese Fähigkeiten zusammenhängen.

Enterprise Architecture baut darauf auf.

Sie verbindet den geschäftlichen Bedarf mit der Unternehmenslandschaft aus:

• Anwendungen

• Daten

• Schnittstellen

• Technologien

• Standards

• Plattformen

• Governance

• Betrieb
  

Enterprise Architecture schafft den Ordnungsrahmen, damit Geschäftsbedarf, IT-Landschaft und Betrieb zusammenpassen.

Unternehmen betreiben keine Einzellösung. Sie betreiben eine Flotte.

Ein Unternehmen ist nicht wie ein einzelnes Fahrzeug.

Es ist eher wie eine Organisation mit einer gewachsenen Flotte.

Es gibt unterschiedliche Fahrzeuge für unterschiedliche Zwecke:

• PKW

• Transporter

• Spezialfahrzeuge

• Fahrzeuge für Kurzstrecken

• Fahrzeuge für hohe Lasten

• Fahrzeuge mit besonderen Sicherheitsanforderungen

Jedes Fahrzeug hat eine unterschiedliche Aufgabe.

Trotzdem sind sie alle Teil derselben Flotte.

Genauso verhält es sich im Unternehmen.

Ein CRM-System erfüllt einen anderen Zweck als ein ERP-System.Eine Integrationsplattform hat andere Anforderungen als ein Reporting-Tool.Eine Kunden-App folgt anderen Prinzipien als eine interne Fachanwendung.

Aber am Ende muss alles zusammenpassen.

Business Architecture klärt den Bedarf

Bevor jemand einen neuen Geschäftswagen auswählt, sollte klar sein:

• Wofür wird das Fahrzeug gebraucht?

• Wer nutzt es?

• Welche Aufgabe soll es erfüllen?

• Welche Anforderungen gibt es?

• Welche Alternativen gibt es bereits in der Flotte?

• Passt der Bedarf zur Richtung des Unternehmens?
  

Genau hier setzt Business Architecture an.

Nicht bei der Lösung.Sondern beim Bedarf.

Übertragen auf Unternehmen heißt das:

• Welche Business Capability soll gestärkt werden?

• Welcher Prozess soll verbessert werden?

• Welches geschäftliche Problem wird adressiert?

• Welche Veränderung im Operating Model ist betroffen?

• Welche Abhängigkeiten entstehen?

• Gibt es bereits bestehende Lösungen?

• Passt der Bedarf zur Strategie?
  

Ohne diese Klärung startet Architektur oft zu spät.

Dann wird über Tools, Systeme oder Plattformen gesprochen, bevor wirklich verstanden ist, welche geschäftliche Fähigkeit verbessert werden soll.

Enterprise Architecture ist strategisches Flottenmanagement

Enterprise Architecture übernimmt anschließend die Perspektive auf die gesamte Flotte.

Sie fragt nicht nur:

Ist dieses eine Fahrzeug gut ausgestattet?

Sondern:

Passt dieses Fahrzeug zur gesamten Flottenstrategie?

Denn ein einzelnes Fahrzeug kann modern, sicher und leistungsfähig sein – und trotzdem nicht zur Flotte passen.

Vielleicht ist es zu teuer im Betrieb.Vielleicht braucht es Sonderprozesse.Vielleicht passt es nicht zur vorhandenen Infrastruktur.Vielleicht erzeugt es neue Abhängigkeiten.Vielleicht gibt es bereits ein anderes Fahrzeug mit ähnlichem Zweck.

Genau so kann eine IT-Lösung für sich genommen überzeugend wirken und trotzdem die Unternehmensarchitektur schwächen.

Enterprise Architecture schafft deshalb den Ordnungsrahmen:

• Welche Zielarchitektur verfolgen wir?

• Welche Plattformen wollen wir stärken?

• Welche Standards gelten?

• Welche Integrationsprinzipien sind verbindlich?

• Welche Technologien sollen reduziert werden?

• Welche Risiken sind akzeptabel?

• Welche Ausnahmen sind begründbar?

• Welche Lösungen passen langfristig zum Unternehmen?
  

Enterprise Architecture baut also nicht jedes Fahrzeug selbst.

Sie sorgt dafür, dass die gesamte Flotte sichtbar, steuerbar, wartbar und zukunftsfähig bleibt.

Governance ist nicht der TÜV am Ende

Governance wird häufig als Prüfung am Ende verstanden. Das greift zu kurz.

In der Fahrzeugmetapher ist Governance eher die Fuhrparkordnung und der Entscheidungsprozess.

Wenn jemand einen Geschäftswagen auswählt, bewegt er sich in einem definierten Rahmen:

• Welche Fahrzeugklassen sind erlaubt?

• Welche Kostenrahmen gelten?

• Welche Sicherheitsstandards müssen erfüllt sein?

• Wer entscheidet?

• Welche Ausnahmen sind möglich?

• Wie wird der Betrieb sichergestellt?
  

Der TÜV prüft später, ob ein Fahrzeug sicher und zulassungsfähig ist.

Aber der TÜV entscheidet nicht, ob ein SUV, ein Transporter oder ein Elektrofahrzeug zum Bedarf des Unternehmens passt.

Diese Entscheidung entsteht früher – im Zusammenspiel aus Bedarf, Flottenstrategie, Regeln, Standards und konkretem Einsatzprofil.

Genau so ist es in der Architektur.

Security, Compliance und Quality Gates prüfen wichtige Mindestanforderungen.

Architecture Governance sorgt dafür, dass neue Lösungen nicht isoliert entstehen, sondern sich im vereinbarten Rahmen bewegen.

Welche Rolle spielen Application Consultants?

In dieser Metapher sind Application Consultants die fahrzeugnahen Spezialisten.

Sie definieren nicht die gesamte Flottenstrategie.Sie schreiben auch nicht die Fuhrparkordnung.

Aber sie kennen ein konkretes Fahrzeugmodell sehr genau. Sie wissen:

• welche Funktionen möglich sind

• welche Konfigurationen sinnvoll sind

• wo der Standard ausreicht

• wo Anpassungen nötig werden könnten

• welche Sonderausstattung später Wartung erschwert

• wie Nutzer im Alltag mit dem Fahrzeug arbeiten

• wo technische oder fachliche Grenzen liegen
  

Übertragen auf Unternehmen heißt das:

Application Consultants kennen konkrete Anwendungen oder Plattformen sehr gut.

Zum Beispiel SAP, Salesforce, ServiceNow, Microsoft Dynamics oder spezifische Fachanwendungen.

Sie helfen dabei, fachliche Anforderungen in eine nutzbare Lösung zu übersetzen – möglichst nah am Standard, aber passend zum Bedarf.

Oder in der Metapher:

Application Consultants wissen, wie man ein konkretes Fahrzeug richtig einstellt, ausstattet und im Alltag nutzbar macht.

Damit sind sie ein wichtiger Teil der Umsetzung.

Aber ihre Arbeit entfaltet den größten Wert, wenn der Rahmen davor klar ist:

• Welcher Bedarf wurde durch Business Architecture beschrieben?

• Welche Leitplanken kommen aus der Enterprise Architecture?

• Welche Regeln gibt die Architecture Governance vor?

• Welche Lösung beschreibt die Solution Architecture?

• Welche Anforderungen stellen Betrieb, Security und Compliance?
  

Dann entsteht nicht nur eine funktionierende Einzellösung.

Dann entsteht eine Lösung, die zur gesamten Flotte passt.

Die Rollen in der Metapher

So wird die Abgrenzung klarer:

Fahrzeugwelt	Architekturwelt
Geschäftsbedarf an Mobilität	Business Architecture
Strategisches Flottenmanagement	Enterprise Architecture
Fuhrparkordnung und Entscheidungsprozess	Architecture Governance
Konkrete Fahrzeugauswahl und Gesamtkonfiguration	Solution Architecture
Fahrzeugspezialist / Modellberater / Ausstattungsberater	Application Consultant
TÜV, Zulassung und Sicherheitsprüfung	Security, Compliance, Quality Gates
Werkstatt, Wartung und Betrieb	Operations
Regelmäßige Bewertung der Flotte	Application Portfolio Management

Damit wird sichtbar:

• Business Architecture ersetzt nicht Enterprise Architecture.

• Enterprise Architecture ersetzt nicht Solution Architecture.

• Governance ersetzt nicht Architekturarbeit.

• Application Consulting ersetzt nicht den Architekturrahmen.
  

Jede Perspektive hat ihren eigenen Zweck.

Der Mehrwert entsteht im Zusammenspiel

Der eigentliche Mehrwert entsteht dort, wo diese Perspektiven sauber ineinandergreifen.

Frameworks wie TOGAF, ArchiMate, BPMN, Zachman oder Capability Maps können dabei helfen.

Aber sie sind nicht der eigentliche Punkt.

Sie sind Werkzeuge, um Komplexität sichtbar, besprechbar und steuerbar zu machen.

Der Kern: Die Rolle der Enterprise Architecture, vom Unternehmensbedarf zur Lösungsstrategie

Enterprise Architecture beginnt nicht mit dem einzelnen System.

Sie beginnt mit dem Verständnis dafür, was das Unternehmen können muss.

Daraus entsteht ein Ordnungsrahmen für die gesamte Unternehmenslandschaft.

Oder in der Fahrzeugmetapher:

• Business Architecture klärt, welche Mobilität das Unternehmen braucht.

• Enterprise Architecture definiert die passende Flottenstrategie.

• Governance sorgt dafür, dass neue Fahrzeuge im vereinbarten Rahmen ausgewählt werden.

• Solution Architecture beschreibt die konkrete Lösung und Integration.

• Application Consultants sorgen dafür, dass das konkrete Fahrzeug sinnvoll konfiguriert und nutzbar wird.

Denn nicht jedes gute Fahrzeug ist automatisch das richtige Fahrzeug für die Flotte.

Und nicht jede gute Lösung ist automatisch die richtige Lösung für das Unternehmen. Genau dort beginnt Architekturarbeit.