Case Study (4/8): TOGAF statt Blindflug
- Jan Böckelt
- 2. Juli
- 3 Min. Lesezeit
Phase B – Business Architecture: Das Geschäft im Zentrum der Architektur
Kapitel 5: Phase C + D – Information Systems & Technology Architecture |
Kapitel 6: Phase E – Opportunities & Solutions |
Kapitel 7: Phase F – Migration Planning |
Kapitel 8: Phase G + H – Implementation Governance & Change Management |
In den vorangegangenen Kapiteln haben wir das TOGAF Framework vorgestellt, die Preliminary Phase beleuchtet und mit der Phase A eine grundlegende Architekturvision für das fiktive Unternehmen in2GlobalTech entwickelt.
Nun wird es konkret: Phase B – Business Architecture steht im Mittelpunkt und bringt erstmals die Geschäftsprozesse, organisatorischen Fähigkeiten und Unternehmensstrukturen in den Fokus der Architekturentwicklung.
Die Phase B: Geschäftsstrategie als Fundament
Phase B des TOGAF 10 Frameworks verfolgt das Ziel, eine fundierte Business-Architektur zu entwerfen, die die strategischen Ziele der Organisation widerspiegelt. Dabei entsteht ein belastbares Modell, das die Verbindung zwischen Geschäftsanforderungen und technologischer Umsetzung schafft – als Basis für alle weiteren Architekturentscheidungen.
Diese Phase markiert den Übergang von der Vision zur Struktur: Sie gibt Antworten auf die Frage, wie Unternehmensziele durch technologische Lösungen konkret unterstützt werden können.
Der Status quo: Baseline Business Architecture
Der erste Schritt ist die präzise Erhebung und Dokumentation der aktuellen Geschäftsarchitektur. Bei in2GlobalTech umfasst dies:
Die Analyse bestehender Geschäftsprozesse, z. B. im globalen Vertrieb hochwertiger Konsumgüter
Die Bewertung der organisatorischen Fähigkeiten, etwa in der Nutzung von Microsoft Teams zur internen Kommunikation oder Entra ID zur Identitätsverwaltung
Die Überprüfung der Organisationsstruktur, insbesondere mit Blick auf die Kompatibilität mit einer globalen Cloud-Strategie
Im Fokus steht die Frage: Unterstützt die bestehende Struktur die strategischen Ziele – oder steht sie ihnen im Weg?
Für in2GlobalTech bedeutet das: Prozesse, Tools und Strukturen müssen evaluiert werden hinsichtlich ihrer Eignung für eine sichere, skalierbare und kollaborative IT-Landschaft – über Standorte hinweg.
Herausforderungen greifbar machen: Business Scenarios
Die sogenannte Business Scenarios-Technik im TOGAF 10 Framework macht abstrakte Anforderungen greifbar – und ist ein zentrales Werkzeug, um komplexe Geschäftszusammenhänge in architektonisch umsetzbare Lösungen zu überführen. Im Kern geht es darum, relevante Herausforderungen aus dem Geschäftsalltag systematisch zu identifizieren und sie in konkrete Szenarien zu übersetzen. Diese zeigen auf, wie Architektur ganz gezielt dazu beitragen kann, strategische Ziele zu erreichen.
Statt in Technik zu denken, wird zunächst gefragt: Welches Problem muss gelöst werden – für wen, in welchem Kontext, mit welchen Hürden? Daraus entsteht ein klares Bild, das sowohl die Bedürfnisse der Stakeholder abbildet als auch die Brücke zwischen Business und Technologie schlägt. Der Mehrwert: Architektur wird nicht zur Reaktion auf Einzelwünsche, sondern zum gestaltenden Instrument für das, was das Unternehmen wirklich voranbringt.
Ein typisches Business Scenario besteht aus folgenden Bausteinen:
Treiber – die geschäftlichen oder technologischen Herausforderungen
Akteure – betroffene Personen oder Gruppen
Ziele – angestrebte Resultate
Herausforderungen – Hürden und Risiken
Lösungsansatz – der geplante Weg zur Zielerreichung
Beispiel: Business Scenario bei in2GlobalTech
Element | Beschreibung |
Treiber | Zunehmender Bedarf an einer skalierbaren und sicheren Dateninfrastruktur |
Akteure | IT-Manager, Datenschutzbeauftragter, Mitarbeitende, Geschäftsleitung |
Ziele | Sichere Cloud-Migration, Einhaltung von Compliance-Vorgaben, minimale Downtime |
Herausforderungen | Technische Komplexität, Datenschutz während des Transfers, Nutzerakzeptanz |
Lösungsansatz | Moderne Sicherheitsarchitektur, benutzerfreundliche Plattform, gezielte Schulungen |
Solche Szenarien übersetzen abstrakte Anforderungen in greifbare Transformationsbedarfe und erleichtern die Kommunikation mit Stakeholdern.
Von der Analyse zum Architekturmodell
Alle Erkenntnisse dieser Phase werden systematisch dokumentiert – im sogenannten Architecture Definition Document. Es ist mehr als eine Sammlung technischer Vorgaben. Es beschreibt das Zielbild der Business Architecture, zeigt, wie der aktuelle Zustand aussieht, welche Lücken geschlossen werden müssen und welche Prinzipien dabei gelten.
Für in2GlobalTech ist dieses Dokument das strategische Rückgrat der kommenden Phasen. Es schafft Klarheit gegenüber Stakeholdern, fördert Konsens und stellt sicher, dass alle Beteiligten auf dasselbe Ziel hinarbeiten.
Strategisch handeln: Die Roadmap aktualisieren
Wo Phase A die Vision definiert, liefert Phase B die ersten konkreten Schritte. Deshalb wird in dieser Phase auch die Architecture Roadmap weiterentwickelt. Sie ordnet Vorhaben, priorisiert Projekte, benennt Meilensteine und zeigt Abhängigkeiten zwischen den Initiativen auf. Damit wird die Zielarchitektur nicht nur beschrieben, sondern aktiv geplant – mit Blick auf Umsetzung, Risiken und Business Value.
So wird aus einem Framework ein Fahrplan. Und aus einem Fahrplan eine Steuerzentrale für die Transformation.
Fazit: Das Business als Taktgeber der Architektur
Phase B macht unmissverständlich klar: IT-Architektur beginnt nicht mit Technik, sondern mit dem Geschäft. Nur wenn Geschäftsprozesse, Ziele und Herausforderungen verstanden und sauber abgebildet sind, kann eine nachhaltige und zukunftsfähige Architektur entstehen. TOGAF liefert dafür das methodische Rückgrat. Und in2GlobalTech zeigt, wie daraus konkrete Handlungsempfehlungen werden.
Vom Geschäftsprozess zur Anwendung
Im nächsten Kapitel steigen wir in die Phase C ein – Information Systems Architecture. Jetzt wird’s technisch: Wie lassen sich die identifizierten Geschäftsanforderungen auf Anwendungs- und Datenebene abbilden? Welche Tools und Strukturen braucht es, um das Business digital abzubilden? Antworten gibt’s im fünften Teil der Case Study.
