TOGAF aus Sicht eines Solution Architekten

Das erste Mal TOGAF

Es gibt Momente in Projekten, die sich einbrennen. Meiner war ein Architektur-Review bei einem großen Finanzdienstleister. Wir waren in der heißen Phase eines großen Vorhabens und eigentlich fast durch: Im Kern fehlte nur noch die Übergabe eines zusätzlichen Feldes an das führende Bestandssystem. Der Aufwand für die Anpassung wurde auf rund 10.000 Euro geschätzt.

Zielgerade also. Eigentlich.

Das Problem: Die bestehende Schnittstelle basierte auf einem Standard, der in der Unternehmensarchitektur inzwischen als veraltet galt. Der Nachfolgestandard war natürlich längst definiert — allerdings nur auf dem Papier. Implementiert war er nirgends. Die Ansage des Architekturboards war trotzdem eindeutig: Wir hätten uns an die globalen Standards zu halten. Dass die dafür notwendige Schnittstelle im Bestandssystem noch gar nicht existierte, wurde kurzerhand zu unserem Problem erklärt. Dann sollten wir sie eben aus dem Projekt heraus neu beauftragen.

Ich bin bis heute einigermaßen sprachlos angesichts der Tatsache, dass wir damals ernsthaft darüber diskutiert haben, für einen beinahe siebenstelligen Betrag eine komplett neue, hochkomplexe Schnittstelle bauen zu lassen, anstatt eine etablierte und allseits geschätzte bestehende Schnittstelle mit minimalem Aufwand zu erweitern.

Die Diskussion zog sich über Wochen, durch mehrere Hierarchieebenen und mit entsprechendem Eskalationspotenzial. Am Ende erhielten wir eine Sondererlaubnis, die bestehende Schnittstelle weiter zu nutzen. Sehr knapp. Nach sehr vielen Diskussionen.

Ich muss zugeben: Seitdem habe ich ein ambivalentes Verhältnis zur Enterprise-Architektur. Natürlich ist langfristige Architekturplanung für große Organisationen elementar. Aber sie hilft wenig, wenn sie an den Bedürfnissen der Organisation und der Marktwirklichkeit vorbeigeht und sich die sprichwörtlichen Architekten im Elfenbeinturm primär selbst verwirklichen.

Natürlich ist diese Anekdote weniger ein Argument gegen Enterprise-Architektur an sich als eines gegen schlechtes architektonisches Change Management. Aber es hat mich nicht überrascht, dass der „neue globale langfristige Schnittstellenstandard“ wenige Jahre später sang- und klanglos beerdigt wurde.

Auch wenn der Techniker in mir beim Schreiben dieser Zeilen noch immer leicht rebelliert, merke ich im Laufe meines Berufslebens immer wieder, wie wichtig und zugleich herausfordernd gutes Enterprise-Architektur-Management für Organisationen sein kann. Vielleicht war genau das auch der Grund, warum ich mich einige Jahre später dazu durchgerungen habe, mich in TOGAF zertifizieren zu lassen — wohlgemerkt, ohne die Brille eines Solution Architekten abzulegen.

Wirklich warm geworden bin ich mit TOGAF in der Schulung allerdings zunächst nicht. Dort begegnete mir das Framework vor allem als formaler, erstaunlich starrer Werkzeugkasten für Governance, Prozessdisziplin und Artefaktpflege. Das mag auch an der Vermittlung gelegen haben: Der Trainer war fachlich ohne Frage exzellent, seine eigentliche Leidenschaft galt aber ganz offensichtlich eher ITIL, ISO-Normen und sauberer Regelkonformität als der Frage, wie Architektur in dynamischen Delivery-Realitäten Orientierung gibt. Vielleicht erklärt genau das einen Teil meiner Reibung mit TOGAF — und meinen Impuls, im Framework stärker nach tragenden Prinzipien als nach formalen Artefakten zu suchen.

Was ist TOGAF?

TOGAF (The Open Group Architecture Framework) ist das meistverbreitete Rahmenwerk für Enterprise-Architektur — gepflegt von der Open Group, mit über 100.000 Zertifizierungen weltweit.

• Kern: Methoden, Werkzeuge und ein gemeinsames Vokabular für die systematische Planung und Steuerung von IT-Architekturen
• Herzstück: Die Architecture Development Method (ADM) — ein iterativer Zyklus aus acht Phasen, von der Architekturvision bis zur Governance
• Verbreitung: De-facto-Standard in großen Organisationen — insbesondere bei Behörden und im öffentlichen Sektor genießt das Framework hohes Ansehen

Was TOGAF verspricht — und was ein Solution Architekt braucht

TOGAF ist beeindruckend. Acht ADM-Phasen, ein Content Framework mit dutzenden Artefakten, ein Governance-Modell, eine Taxonomie für Building Blocks, ein Enterprise Continuum als Klassifikationsschema. Und eine Zertifizierungsindustrie, die ihresgleichen sucht. In öffentlichen Ausschreibungen öffnet das Zertifikat Türen — das ist pragmatisch betrachtet sein größter Nutzen. Ob jemand TOGAF verstanden hat, sagt es nicht aus. Für Enterprise Architekten, die IT-Strategien über Jahre und Geschäftsbereiche hinweg steuern, ist das Framework ein mächtiges Werkzeug.

Aber Solution Architekten arbeiten anders. Wir entwerfen keine Zielarchitekturen für 2029. Wir entscheiden jetzt, ob dieses System synchron oder asynchron kommuniziert. Ob wir eine eigene Datenbank brauchen oder den bestehenden Service erweitern. Ob das Feature in die bestehende Bounded Context passt oder eine neue rechtfertigt.

“

The architect rides the elevator between the penthouse and the engine room. Those who stay on one floor fulfill the role only halfway.

Gregor Hohpes Fahrstuhl-Metapher trifft den Punkt: Solution Architekten verbringen den Großteil ihres Tages nicht auf einer Etage, sondern im Fahrstuhl — zwischen Business-Anforderungen, Team-Realität und technischen Constraints. TOGAF wurde für das Penthouse entworfen. Und genau an den Übergängen zwischen den Etagen entsteht die Reibung.

Die Reibungspunkte

1. Architecture Vision Document vs. Architecture Decision Records

Das Problem: Das Enterprise Architecture Board erwartet TOGAF-konforme Artefakte. Ein Architecture Vision Document, Stakeholder Maps im vorgegebenen Template, Building Block Definitions. Das Delivery-Team dokumentiert seine Entscheidungen in Architecture Decision Records — schlank, kontextnah, versioniert im Repository, direkt neben dem Code.

Der Kern: Beide Ansätze sind sinnvoll — für ihre jeweilige Zielgruppe. Das Architecture Vision Document beantwortet strategische Fragen: Passt die Lösung zur Zielarchitektur? Welche Geschäftsfähigkeiten werden adressiert? ADRs beantworten taktische Fragen: Warum haben wir uns für Kafka statt RabbitMQ entschieden? Was waren die Alternativen? Was sind die Konsequenzen?

Das Problem entsteht, wenn eine Seite die andere zu ihrem Format zwingt. Ein Team, das Architecture Vision Documents schreiben muss, die niemand im Team liest. Oder ein Board, das ADRs nicht akzeptiert, weil sie nicht ins Template passen.

Warum „Sprache statt Gesetz” hier besser funktioniert: Wenn beide Seiten die TOGAF-Begriffe als gemeinsames Vokabular kennen, können sie übersetzen statt doppelt dokumentieren. Der Solution Architekt referenziert in seinen ADRs die relevanten Building Blocks und Principles — nicht weil TOGAF das vorschreibt, sondern weil es die Kommunikation mit dem Board beschleunigt. Das Board versteht, wo die Lösung in der Gesamtlandschaft sitzt, ohne ein 30-seitiges Dokument zu fordern. Die Sprache schafft Anschlussfähigkeit. Das Gesetz schafft Bürokratie.

2. Acht ADM-Phasen für ein Feature-Team

Das Problem: TOGAF definiert die Architecture Development Method als Zyklus aus acht Phasen — von Architecture Vision über Business Architecture, Information Systems Architecture und Technology Architecture bis hin zu Migration Planning und Governance. Für eine Enterprise-weite Transformation mag das passen. Für ein Feature-Team, das in zweiwöchigen Sprints liefert, ist das wie ein Sechsgänge-Menü in der Mittagspause.

Der Kern: Die ADM-Phasen sind keine Checkliste. Sie beschreiben Denkschritte, keine Prozessschritte. Die Frage „Haben wir die Business Architecture verstanden?” ist immer relevant. Die Frage „Haben wir Phase B formal durchlaufen und das Business Architecture Document erstellt?” ist es meistens nicht.

Hinzu kommt ein zweiter Gedanke, der in vielen Architekturdiskussionen zu kurz kommt: Gute Architekturentscheidungen trifft man nicht möglichst früh, sondern am letzten vernünftigen Moment. Also dann, wenn man genug gelernt hat, um tragfähig zu entscheiden — aber noch nicht so spät ist, dass das Warten teuer wird. Mathematisch gesprochen: der Punkt, an dem der zusätzliche Erkenntnisgewinn nicht mehr größer ist als die Kosten des weiteren Zuwartens.

Gerade hier wird die Reibung mit TOGAF im Projektalltag schnell spürbar. Sobald Phasen, Dokumente und Freigaben den Eindruck erzeugen, Architektur müsse möglichst vollständig vorab feststehen, nimmt man Teams genau die Lernschleifen, die in komplexen Vorhaben notwendig sind. Aus Solution-Architektur-Sicht geht es deshalb nicht darum, jede Entscheidung früh zu formalisieren, sondern sie rechtzeitig, bewusst und nachvollziehbar zu treffen.

Man merkt TOGAF 10 durchaus an, dass das Framework auf diese Realität reagieren will und agile Arbeitsweisen irgendwie integrieren möchte. Für mich wirkt das bislang allerdings eher additiv als wirklich überzeugend integriert — mehr „wir unterstützen jetzt auch agil“ als ein Framework, das von seinem inneren Modell her wirklich aus iterativer Delivery-Realität heraus denkt.

Hier liegt der entscheidende Unterschied: Prinzipien statt Regeln. Das Prinzip hinter Phase B lautet: Verstehe die geschäftlichen Treiber, bevor du technische Entscheidungen triffst. Das ist zeitlos gültig — egal ob man ein halbes Jahr plant oder einen Sprint. Die Regel „Erstelle ein Business Architecture Document nach Template X” ist eine mögliche Umsetzung dieses Prinzips. Aber eben nur eine.

Warum das besser funktioniert: Ein Solution Architekt, der die Prinzipien hinter den ADM-Phasen verinnerlicht hat, trifft bessere Entscheidungen als einer, der die Artefakte pflichtbewusst ausfüllt. Er fragt sich vor jedem Sprint: Verstehen wir den Business-Kontext? Haben wir die Abhängigkeiten zu anderen Systemen geklärt? Ist unsere Migrationsstrategie tragfähig? Die Antworten dokumentiert er dort, wo sein Team sie findet — im Wiki, im ADR, im Sprint-Review. Nicht in einem Artefakt, das einmal erstellt und nie wieder gelesen wird.

3. Die Zielarchitektur ist drei Jahre alt — die Technologie drei Monate

Das Problem: Das Enterprise Architecture Team hat vor drei Jahren eine Zielarchitektur definiert. Sorgfältig, TOGAF-konform, in allen Gremien abgestimmt. Seitdem hat sich die technologische Landschaft grundlegend verändert — neue Cloud-Services, neue Sicherheitsanforderungen, neue regulatorische Vorgaben. Aber die Zielarchitektur steht. Und das Board erwartet Konformität.

Der Kern: TOGAF sieht Architecture Change Management vor — Phase H im ADM-Zyklus. In der Theorie wird die Zielarchitektur kontinuierlich angepasst. In der Praxis ist der Aufwand für eine formale Änderung der Enterprise Architecture so hoch, dass sie nur alle paar Jahre stattfindet. Die Konsequenz: Solution Architekten arbeiten gegen eine Zielarchitektur, die die aktuelle Realität nur noch teilweise abbildet.

Das erzeugt einen stillen Konflikt. Der Solution Architekt weiß, dass eine neuere Technologie besser geeignet wäre. Das Board besteht auf Konformität mit der bestehenden Zielarchitektur. Beide haben innerhalb ihres Rahmens Recht — aber der Rahmen passt nicht mehr.

Warum Prinzipien hier den Ausweg bieten: Hinter jeder Zielarchitektur stehen Designprinzipien — Standardisierung, Wiederverwendbarkeit, Sicherheit, Skalierbarkeit. Diese Prinzipien altern langsamer als konkrete Technologieentscheidungen. Wenn ein Solution Architekt zeigen kann, dass seine Lösung die Prinzipien der Zielarchitektur erfüllt, auch wenn sie von der konkreten Technologievorgabe abweicht, ist das ein argumentativ stärkerer Standpunkt als die bloße Berufung auf ein drei Jahre altes Dokument.

4. Governance endet, wo Sprint Planning beginnt

Das Problem: TOGAF definiert Architecture Governance als kontinuierlichen Prozess — Compliance-Reviews, Architecture Contracts, formale Abnahmen. In der Praxis endet dieser Prozess an der Grenze zum Delivery-Team. Das Board reviewt die Lösungsarchitektur, gibt sie frei — und dann verschwindet die Lösung in den Sprint-Backlog. Was zwischen Freigabe und Produktion passiert, liegt außerhalb des Governance-Radars.

Der Kern: Das ist kein TOGAF-Problem. Es ist ein Organisationsproblem. Aber TOGAF bietet für diesen Übergang wenig Hilfe. Das Framework geht implizit davon aus, dass die Architektur vor der Implementierung feststeht und während der Umsetzung stabil bleibt. In agilen Projekten ist das die Ausnahme, nicht die Regel. Architekturentscheidungen entstehen während der Implementierung — im Pair Programming, im Code Review, im Debugging.

Warum „Sprache statt Gesetz” diese Lücke schließt: Wenn Entwickler im Team die grundlegenden TOGAF-Konzepte kennen — nicht als Zertifizierungswissen, sondern als gemeinsames Vokabular —, können sie Architekturentscheidungen einordnen, ohne den formalen Governance-Prozess zu durchlaufen.

Ein konkretes Beispiel: Im Code Review fällt auf, dass das Team einen zweiten Message Broker einführen will — neben dem bestehenden. Ein Entwickler, der das Architecture Principle „Technology Standardization” kennt, erkennt den Konflikt. Er eskaliert nicht ans Board, sondern schreibt einen ADR, referenziert das betroffene Prinzip und bringt es im nächsten Architecture Sync ein. Das ist Governance durch Vokabular, nicht durch Gremium. Ohne das gemeinsame Vokabular wäre die Entscheidung stillschweigend durchgegangen — oder erst Monate später im nächsten formalen Review aufgefallen.

Die fünf TOGAF-Konzepte, die bleiben

Nicht alles an TOGAF ist Overhead. Einige Konzepte haben sich in meiner Arbeit als Solution Architekt bewährt — nicht weil ich sie formal anwende, sondern weil sie mein Denken strukturieren.

Fazit

TOGAF ist kein schlechtes Framework. Es ist ein mächtiges — und wie alle mächtigen Werkzeuge gefährlich in den falschen Händen. Das Problem liegt nicht im Framework selbst, sondern darin, wie es angewendet wird: als Regelwerk, das Konformität erzwingt, statt als Sprache, die Verständigung ermöglicht.

Für Solution Architekten lautet die relevante Frage nicht „Sind wir TOGAF-konform?”, sondern „Verstehen wir die Prinzipien hinter den Artefakten — und wenden wir sie in einer Form an, die zu unserem Kontext passt?”

Dahinter steht für mich noch ein größerer organisatorischer Gedanke: das Subsidiaritätsprinzip. Entscheidungen sollten auf der niedrigsten Ebene getroffen werden, auf der sie sinnvoll und verantwortungsvoll getroffen werden können. Genau dort ist in der Regel auch das meiste Kontextwissen vorhanden. Ein Enterprise-Architektur-Management, das diesen Gedanken ernst nimmt, versucht deshalb nicht, jede Entscheidung an sich zu ziehen. Es setzt Leitplanken, formuliert Prinzipien, schafft Transparenz und greift nur dort steuernd ein, wo lokale Entscheidungen spürbare systemische Auswirkungen haben.

Gerade deshalb braucht gutes EAM weniger starre Kontrolle und mehr prinzipiengeleitete Führung. Weniger Artefaktgläubigkeit. Weniger Konformität um ihrer selbst willen. Und mehr Vertrauen in die Architekturarbeit der Teams.

Wer TOGAF als Gesetz versteht, schafft Bürokratie. Wer es als Vokabular versteht, schafft Verständigung. Und wer Enterprise-Architektur so lebt, dass Entscheidungen möglichst nah am Problem getroffen werden können, hat aus meiner Sicht nicht nur TOGAF verstanden, sondern auch den eigentlichen Zweck von Architektur: Orientierung zu geben, ohne unnötig Handlungsfähigkeit zu zerstören.

---

Sie stehen vor einer ähnlichen Herausforderung — Architektur-Governance und agile Delivery unter einen Hut zu bringen? Erfahren Sie mehr über unsere Beratungs- und Engineering-Leistungen.