Operating Architecture,
nicht Enterprise Architecture.

Warum dieser Text überhaupt nötig ist.

Wir werden regelmäßig gefragt, ob wir „TOGAF machen". Oder „BPMN machen". Oder „KI im Mittelstand machen". Die ehrliche Antwort lautet jedes Mal: nein, wir machen genau das nicht. Wir benutzen diese Werkzeuge — aber das ist nicht der Beruf, sondern das Handwerkszeug. Der Beruf ist ein anderer, und er hat noch keinen sauberen Namen, weil er sich gerade erst ausbildet.

Wir nennen ihn Operating Architecture: die Arbeit daran, eine Organisation so aufzustellen, dass Menschen und Maschinen im KI-Zeitalter überhaupt sinnvoll zusammen arbeiten können. Das ist mehr als Enterprise Architecture, weniger als Beratung im klassischen Sinn — und eindeutig nicht „noch ein Tool".

Dieser Text erklärt, was wir damit meinen, woran wir uns von klassischer EA abgrenzen, wie wir Prozesse ganzheitlich anschauen — und warum am Ende dieser Arbeit ein selbst gebautes Werkzeug steht, das wir FlowVisual nennen.

Was klassische Enterprise Architecture gut konnte.

Enterprise Architecture, wie sie in den letzten dreißig Jahren entstanden ist, hat einer Generation von Großunternehmen geholfen, ihre IT-Landschaft zu sortieren. TOGAF, Zachman, ArchiMate — diese Frameworks waren nicht falsch. Sie haben Begriffe geliefert, eine Strukturierungssprache, ein Verfahren namens ADM und damit überhaupt erst die Möglichkeit, über eine Applikationslandschaft mit hunderten Systemen rational zu sprechen.

In der Welt, für die diese Frameworks gebaut wurden, war eine Tätigkeit fast immer eindeutig zugewiesen: ein Mensch macht das, ein System macht jenes. Schnittstellen waren Schnittstellen. Prozesse waren Reihenfolgen. Daten waren Tabellen. Und die wichtigste Architekturfrage war: welche Anwendung gehört in welche Domäne, welches System ersetzt welches.

Was sich seitdem geändert hat — und was deshalb nicht mehr aufgeht.

Heute ist eine Tätigkeit selten noch eindeutig zugewiesen. In jedem zweiten Schritt fragt sich jemand: könnte das nicht ein Modell? In jedem dritten Schritt liegt die Antwort irgendwo zwischen Mensch und Maschine — eine Vorklassifikation durch ein Modell, eine Entscheidung durch einen Menschen, eine Ausführung durch ein System, ein Review durch eine zweite Person. Und das alles innerhalb dessen, was früher schlicht ein Schritt war.

Klassische Enterprise Architecture hat dafür keine Sprache. Sie kennt Akteure, Systeme, Daten — aber sie kennt nicht die Übergabe zwischen Mensch und Maschine als eigenes architektonisches Element. Genau diese Übergabe ist aber inzwischen das Element, an dem Organisationen tatsächlich scheitern oder funktionieren.

Operating Architecture als eigenständige Disziplin.

Operating Architecture ist nicht das Ablösen von Enterprise Architecture. Sie kommt eine Ebene später, an einer Stelle, an der die alte EA schon fertig war: nicht beim Bauplan des Unternehmens, sondern beim Funktionieren des Tagesbetriebs.

Das mag nach einer kleinen Verschiebung klingen — ist es aber nicht. Es ändert, was man überhaupt anschaut, mit welcher Frage man anfängt, welche Werkzeuge man nimmt, und vor allem: wer am Ende verantwortlich ist.

Andere Frage am Anfang.

Klassische EA fragt: „Wie sieht unsere Architektur aus, und was muss daran besser werden?" Wir fragen: „Wo entstehen in eurem Tagesbetrieb regelmäßig Reibung, Workarounds, Eskalationen, stille Verluste? Und woran liegt das?" Aus dieser Frage heraus arbeiten wir uns nach hinten durch — über Prozesse, über Daten, über Systeme, bis dahin, wo eine wirkliche Veränderung ansetzen muss. Manchmal landet man im Tooling. Oft genug landet man bei Verantwortlichkeiten, bei fehlenden Übergaben, bei einer Erwartung, die nirgends ausgesprochen ist.

Anderer Gegenstand der Arbeit.

Wir bauen keine 200-seitigen Architekturdokumente. Wir bauen operative Beschreibungen, die so präzise sind, dass sie für Menschen lesbar und für Systeme ausführbar sind — gleichzeitig. Das ist nicht Symbolik, das ist eine harte technische Anforderung. Wenn dieselbe Beschreibung dem Sachbearbeiter, dem Auditor und dem Workflow-System dient, ist Operating Architecture in Reichweite.

Anderer Erfolg.

Eine klassische EA-Initiative gilt häufig dann als gelungen, wenn das Architecture Board ein Zielbild verabschiedet hat. Wir betrachten unsere Arbeit dann als gelungen, wenn in einem konkreten Prozess — Bestellabwicklung, HR-Onboarding, Servicefall, Rechnungslauf — am Montag erkennbar weniger nachgefasst, korrigiert oder eskaliert wird als am Freitag davor. Alles andere ist Vorspiel.

Wir schauen Prozesse ganzheitlich an. Was das tatsächlich heißt.

„Ganzheitlich" ist ein abgenutztes Wort. Bei uns hat es eine konkrete Bedeutung: ein Prozess wird nicht über eine Brille analysiert (die der IT, die der Fachseite, die des Controllings), sondern über fünf gleichzeitig. Wenn nur eine fehlt, kommt am Ende eine Optimierung heraus, die in einer der anderen Dimensionen kaputtgeht.

Ein „ganzheitliches" Bild eines Prozesses entsteht erst, wenn diese fünf Schichten am selben Schritt gleichzeitig betrachtet werden. Klassische EA macht das nicht — sie ist auf einer höheren Flughöhe. BPMN allein macht es auch nicht — es modelliert vor allem die Prozessebene. Process Mining ist nah dran, aber blind für Mensch- und Verantwortungs-Schicht. Und genau deshalb scheitern Optimierungs-Initiativen so oft an Stellen, an denen niemand sie erwartet hat.

Wie wir konkret arbeiten.

Vier Schritte, in genau dieser Reihenfolge. Jeder ist ohne den davor sinnlos.

1. 01

   Hinsehen, ehrlich.

   Wir kommen nicht mit einem Zielbild ins Haus. Wir kommen mit Fragen, Notizblock und der Bereitschaft, drei Tage lang in einer Abteilung danebenzustehen. Was wir suchen, sind die Stellen, an denen Menschen Workarounds bauen — denn dort steckt die echte Information darüber, wo etwas nicht trägt.

2. 02

   Beschreiben, mit Konsequenz.

   Was wir gefunden haben, modellieren wir so, dass es sowohl ein Mensch lesen als auch eine Maschine ausführen kann. Wir nutzen BPMN nicht, weil es Pflicht wäre, sondern weil es das einzige Notationssystem ist, das diese doppelte Lesbarkeit aushält. Das Modell ist nicht Dokumentation, es ist die Quelle der Wahrheit.

3. 03

   Mensch- und Maschinenanteil bewusst trennen.

   Pro Schritt entscheiden wir explizit: ist das Urteilsvermögen, gehört es einem Menschen — und welcher Teil der Arbeit ist Reibung, die ein System übernehmen sollte. Diese Entscheidung ist der Kern der Disziplin. Sie wird nicht einer KI überlassen.

4. 04

   Umsetzen mit jemandem, der das Ergebnis trägt.

   Wir bringen Modelle in Workflow-Engines, RPA, in Schnittstellen, in Reports — aber nie ohne eine namentliche Person auf Kundenseite, die für das Ergebnis dieses Schritts verantwortlich ist. Ohne diese Person scheitert jede Umsetzung. Mit ihr funktioniert sie überraschend oft.

Warum wir FlowVisual gebaut haben.

Während wir genau diese Arbeit gemacht haben, ist uns immer wieder dasselbe Problem begegnet: die gängigen Werkzeuge erlauben es zwar, einen Prozess zu zeichnen, aber nicht, ihn realistisch durchzurechnen. Was passiert, wenn an Schritt drei eine Bearbeitungszeit schwankt? Wenn an Schritt sieben eine Eskalationsquote bei zwölf Prozent liegt? Wenn ein bestimmter Teil neuerdings durch ein Modell vorklassifiziert wird, das in 92 % der Fälle richtig liegt — wie verändert das die Lasten der nachgelagerten Schritte?

Diese Fragen sind keine Spielerei. Sie sind der Unterschied zwischen einem gut aussehenden BPMN-Diagramm und einem Prozessmodell, das einer CFO-Diskussion standhält. Genau hierfür hatten wir nichts Gescheites. Also haben wir es gebaut.

Was bleibt von TOGAF, BPMN, Lean, Six Sigma?

Eine ehrliche Antwort, weil wir oft danach gefragt werden:

• TOGAF / Zachman / ArchiMateals Begriffsapparat brauchbar, als Prozesslehrbuch ungeeignet. Wir nehmen die Sprache, lassen den Zertifikats-Apparat liegen.
• BPMN 2.0unverzichtbar — aber nicht als Modellierungs-Selbstzweck, sondern als gemeinsame Sprache zwischen Mensch- und Maschinen-Schritten.
• Lean / Six Sigma / Kaizendie Haltung „kontinuierlich, klein, ehrlich" trägt weiter denn je. Die Statistik-Apparatur sechsstelligen Sigmas dagegen ist meist Theater.
• Process Miningdas beste Mittel, sich vor sich selbst nicht mehr zu belügen. Wenn Logdaten verfügbar sind, fängt unsere Diagnose dort an.
• KI / LLMs / Agentsein einzelner Schritt im Prozess. Nicht der Prozess selbst, nicht das Ziel, nicht die Strategie. Wir setzen sie, wo sie nachweislich besser ist als Regeln — sonst nicht.

Was wir bewusst nicht tun.

• Wir verkaufen keine Zertifikate, weder eigene noch fremde. Operating Architecture ist eine Disziplin, kein Kursprogramm.
• Wir bauen keine 200-seitigen Architekturdokumente, die nach dem Kickoff niemand mehr öffnet. Was wir liefern, muss am Montag tatsächlich benutzt werden.
• Wir empfehlen keine Tools nach Hersteller-Logo. Wir empfehlen, was zu einer ehrlich diagnostizierten Stelle passt — manchmal ist das ein neues System, oft ist es etwas, was schon da ist.
• Wir setzen kein KI-Pilotprojekt auf, das den Begriff aufs T-Shirt drucken lässt. Wenn ein Schritt von einem Modell besser erledigt wird, setzen wir es ein. Wenn nicht, lassen wir es.
• Wir messen unsere Arbeit nicht an Workshops, Decks oder „Ergebnisräumen", sondern daran, dass Reibung in einem konkreten Prozess weniger wird.

Wofür dieser Text steht.

Wenn dieser Text einen Zweck hat, dann diesen: klarzumachen, dass Operating Architecture nicht das nächste Buzzword ist, sondern eine notwendige Reaktion auf eine veränderte Realität. Mensch und Maschine treffen heute in jedem zweiten Schritt aufeinander. Eine Organisation, die das nicht bewusst gestaltet, wird sich daran zerreiben — egal, wie viele Lizenzen sie kauft und wie viele Frameworks sie zertifiziert hat.

Bewusst gestalten heißt: hinsehen, ehrlich beschreiben, sauber trennen, mit jemandem umsetzen, der das Ergebnis trägt. Das ist die ganze Disziplin in einem Satz. Alles andere — Werkzeuge, Frameworks, KI — sind Ausführungs-Details.

Wenn Sie wissen wollen, wie das in Ihrer Organisation konkret aussehen würde, sprechen wir.