Ein IT-Bebauungsplan ist im Kontext von Enterprise Architecture Management kein hübsches Schaubild der IT-Landschaft. Er ist ein zentrales Architekturartefakt, mit dem die Enterprise Architecture sichtbar, vergleichbar und steuerbar wird. Während Enterprise Architecture beschreibt, aus welchen Bausteinen ein Unternehmen besteht und wie diese zusammenwirken, sorgt EAM dafür, dass diese Architektur gepflegt, bewertet und zielgerichtet weiterentwickelt wird. Der Bebauungsplan ist dabei die gemeinsame Sicht für Management, Fachbereiche, IT, Security, Betrieb und Projektportfolio.
Viele Unternehmen haben Anwendungslisten, Lizenzübersichten oder CMDB-Daten. Diese Informationen sind wichtig, reichen aber nicht aus. Für Architekturentscheidungen muss sichtbar sein, welche Anwendung welche Business Capability unterstützt, welche Informationsobjekte verarbeitet werden, welche Schnittstellen bestehen, welche Technologien verwendet werden, welche Risiken vorliegen und wie sich die Landschaft in Richtung Zielarchitektur entwickeln soll. Genau diese Zusammenhänge macht ein Bebauungsplan sichtbar.
Der Begriff Bebauungsplan ist bewusst gewählt: Wie in der Stadtplanung geht es nicht nur um einzelne Gebäude, sondern um Nutzung, Zonen, Abhängigkeiten, Entwicklungsflächen, Standards und Veränderung über Zeit. Auf die IT übertragen bedeutet das: Anwendungen werden nicht isoliert betrachtet, sondern als Teil einer Unternehmensarchitektur.
Enterprise Architecture betrachtet typischerweise mehrere Architekturdomänen: Geschäftsarchitektur, Anwendungsarchitektur, Informations- und Datenarchitektur sowie Technologiearchitektur. Frameworks wie TOGAF ordnen Enterprise Architecture genau in diesen Zusammenhang ein: Business, Application, Data und Technology Architecture müssen gemeinsam betrachtet werden, nicht als getrennte Silos. Der IT-Bebauungsplan übersetzt diese Logik in ein handhabbares Modell der konkreten Unternehmenslandschaft.
Damit wird der Bebauungsplan zum Bindeglied zwischen Strategie und Umsetzung. Er zeigt nicht nur, dass eine Anwendung existiert, sondern warum sie existiert: Welche Fähigkeit unterstützt sie? Welcher Prozess nutzt sie? Welche Informationen werden erzeugt, verändert oder konsumiert? Welche Schnittstellen sind kritisch? Welche Technologie- oder Anbieterabhängigkeiten entstehen? Welche Rolle spielt die Anwendung in der Zielarchitektur?
Ohne diese Modellierung bleibt EAM abstrakt. Mit einem Bebauungsplan wird Enterprise Architecture entscheidungsfähig: Aus einer Vielzahl einzelner Systeme entsteht ein geordnetes Bild von Fähigkeiten, Anwendungen, Informationen, Technologien, Verantwortlichkeiten und Veränderungspfaden. In manchen Enterprise Architekturen gibt es dafür eine eigene Architekturdomäne: die System- oder auch IT-Architektur.
Wir beginnen nicht mit einem Tool, sondern mit den Entscheidungen, die unterstützt werden sollen. Geht es um Modernisierung, Portfoliooptimierung, Datenarchitektur, Compliance, Cloud-Transformation oder Roadmap-Planung? Daraus leiten wir die notwendigen Sichten ab: Management, Fachbereich, IT-Betrieb, Security, Datenarchitektur, Projektportfolio oder Einkauf.
Danach wird festgelegt, welche Objekte und Beziehungen beschrieben werden: Business Capabilities, Prozesse, Anwendungen, Informationsobjekte, Datenflüsse, Schnittstellen, Technologien, Anbieter, Verantwortlichkeiten, Risiken und Lebenszyklen. Dieses Modell ist wichtiger als das Werkzeug, weil es bestimmt, welche Entscheidungen später möglich sind.
Jede relevante Anwendung wird nicht nur inventarisiert, sondern klassifiziert: Einsatzbereich, Capability-Zuordnung, Informationsrolle, Integrationsrolle, Kritikalität, Lifecycle, Sourcing, Technologie und Zielarchitektur-Fit. So entsteht aus einer Systemliste eine echte Applikationslandkarte.
Der Bebauungsplan zeigt nicht nur den aktuellen Zustand. Er beschreibt auch Zielzustände und Übergänge. Dadurch wird sichtbar, welche Anwendungen abgelöst, welche Datenflüsse verändert, welche Schnittstellen konsolidiert und welche Technologien standardisiert werden sollen.
Der Bebauungsplan bleibt nur aktuell, wenn er Teil laufender Entscheidungen wird: Projektstarts, Architekturreviews, Portfolio-Reviews, Technologieentscheidungen, Cloud-Freigaben, Daten-Governance und Roadmap-Planung. EAM definiert, wer welche Informationen pflegt und wann Änderungen in das Modell zurückgespielt werden.
Daniel Adam
Telefon: 0336 31 40 30 11
E-Mail: info@trusted-advisor.com
Ein IT-Bebauungsplan ist ein strukturiertes Modell der IT-Landschaft im Kontext der Enterprise Architecture. Er verknüpft Anwendungen, Capabilities, Informationsobjekte, Datenflüsse, Schnittstellen, Technologien, Verantwortlichkeiten, Lebenszyklen, Risiken und Zielzustände.
Eine Systemliste beantwortet meist nur, welche Anwendungen existieren. Ein Bebauungsplan beantwortet zusätzlich, warum sie existieren, welche Fachlichkeit sie unterstützen, welche Informationen sie verarbeiten, welche Abhängigkeiten bestehen und wie sich die Landschaft entwickeln soll.
Anwendungsklassifikation macht Komplexität steuerbar. Sie ordnet Anwendungen nach mehreren Dimensionen ein, etwa Einsatzbereich, Business Capability, Datenrolle, Integrationsrolle, Kritikalität, Lebenszyklus, Technologie und Sourcing. Dadurch können Anwendungen angemessen gesteuert werden.
Nein. Eine CMDB fokussiert meist auf Configuration Items und Betrieb. Ein Bebauungsplan stellt Architekturzusammenhänge, fachliche Nutzung, Zielbilder, Übergangszustände und Transformationspfade dar. CMDB-Daten können eine wichtige Quelle sein, ersetzen aber nicht das EA-Modell.
Typische Sichten sind Capability Map, Applikationslandkarte, Informations- und Datenlandkarte, Schnittstellenübersicht, Technologieportfolio, Lifecycle-Sicht, Risiko- und Kritikalitätssicht sowie Roadmap-Sicht.
Aktuell genug, um Entscheidungen zu unterstützen. Kritische Anwendungen, Informationsflüsse, Schnittstellen und Technologien sollten kontinuierlich gepflegt werden. Weniger kritische Bereiche können zyklisch aktualisiert werden.
Ein Tool kann helfen, ersetzt aber nicht die Methode. Entscheidend sind ein klares Architekturmodell, definierte Klassifikationen, Verantwortlichkeiten, Datenqualität im Repository und die Verankerung in Entscheidungsprozessen. Ein Werkzeug unterstützt und vereinfacht die Automatisierung, Qualitätssicherung und Reportingfähigkeiten bei diesen Themen natürlich enorm.
