Bebauungsplanung

Warum Bebauungsplanung?

Die Bebauungsplanung ist ein Kernelement jeder Enterprise Architektur. Sie ist kein statisches Artefakt, sondern ein kontinuierlicher Prozess, der regelmäßig durchgeführt und an die sich verändernden Anforderungen eines Unternehmens angepasst wird. Eine Bebauungsplanung kann zu verschiedenen Zielen im Unternehmen beitragen, wie zum Beispiel:

• Wenn das Ziel in der Modernisierung der IT-Landschaft besteht, dann ist die Bebauungsplanung die Leitlinie, die sinnvolle Modernisierungsmaßnahmen definiert.
• Möchte ein Unternehmen in neue Geschäftsfelder vorstoßen und benötigt dafür neue IT, dann ist die Bebauungsplanung die Basis für diesen Vorstoß.
• Wenn ein Unternehmen von technologischen Innovationen profitieren möchte, ist die Bebauungsplanung das Werkzeug, um die Einführung neuer Technologien im Unternehmen zu steuern.

Es ist die Pflicht von Enterprise Architekten, die zu erreichenden Ziele zu kennen. Und es die Pflicht einer IT- oder Unternehmensleitung diese Ziele zu definieren. Denn:

Wenn ein Kapitän nicht weiß, welches Ufer er ansteuern soll, ist kein Wind der richtige.

Bebauungsplanungen haben Konsequenzen: Sie führen zu Veränderungen in der Prozess- und IT-Landschaft. Diese können schleichend durch kontinuierliche Verbesserungen erfolgen. Oder sie werden durch dedizierte Projekte gesteuert. Dies hängt von der Größe der Veränderungen und der Organisation des Unternehmens ab. In jedem Fall kosten diese Veränderungen Geld, Zeit und Ressourcen. Sind die Ziele, die mit diesen Veränderungen erreicht werden sollen, nicht klar, werden Geld, Zeit und Ressourcen verschwendet.

Szenario

In meinem Artikel über  Souveräne Bebauungsplanung in der Juni-Ausgabe 2025 der Zeitschrift  ix habe ich bereits das Szenario einer Kaffeerösterei verwendet, das ich hier zur Veranschaulichung der Bebauungsplanung weiterentwickeln möchte. Die fiktive Kaffeerösterei ist wie viele echte Unternehmen in mehrere zentrale Bereiche unterteilt. Herzstück ist die eigene Produktion, in der die Kaffeebohnen sorgfältig geröstet und anschließend verpackt werden. Für die Versorgung mit Rohkaffee sorgt der Einkauf: Dieser kümmert sich um die Auswahl geeigneter Lieferanten und importiert die Bohnen vor allem aus Afrika und Südamerika.

Auch eine eigene Logistikabteilung gehört zur Rösterei. Sie sorgt einerseits dafür, dass die rohen Bohnen zuverlässig in die Produktion gelangen, und organisiert andererseits den Versand der gerösteten Ware an die Kundinnen und Kunden. Da die Bohnen nicht immer direkt weiterverarbeitet oder ausgeliefert werden, ist eine Lagerverwaltung notwendig, die sich um die sachgerechte Aufbewahrung kümmert. Für den Verkauf der fertigen Produkte ist ein weiterer Bereich zuständig: Die Rösterei betreibt sowohl ein Ladenlokal vor Ort als auch einen Online-Shop.

Im Ladenlokal haben Besucherinnen und Besucher außerdem die Möglichkeit, den Kaffee direkt vor Ort zu probieren. Dafür wurde ein kleines, gemütliches Café eingerichtet, das zum Verweilen einlädt. Neben den genannten Kernbereichen gibt es auch unterstützende Abteilungen, die für einen reibungslosen Ablauf im Hintergrund sorgen - dazu gehören unter anderem die Personalverwaltung, die Buchhaltung und die IT.

IT-Strategie und Unternehmensziele

Um eine Bebauungsplanung zu erstellen, muss ein Enterprise Architekt das Umfeld kennen, in dem er sich befindet. Neben dem Kerngeschäft des Unternehmens sind auch die IT-Strategie und die unternehmerischen Ziele unverzichtbar.

Im Szenario der Kaffeerösterei nehmen wir an, dass der CIO die folgenden strategischen IT-Leitlinien postuliert hat:

• Wirtschaftlichkeit und Effizienz sind oberste Gebote.
• Verwaltungsvorgänge und der IT-Betrieb sollen so weit wie möglich automatisiert sein.
•  IT-Souveränität ist kein primäres Ziel. Es soll jedoch möglich sein, den Geschäftsbetrieb bei rechtlichen oder technischen Cloud-Problemen aufrecht zu erhalten.
• Primär sollen Cloudsysteme genutzt werden. Für die wichtigsten Daten (Kundendaten, Lieferantenkontakte, Lieferverträge etc.) sollen jedoch lokale Backups vorhanden sein. Das Unternehmen setzt auf die  No-Cloud-Strategie (für not only Cloud).
• Es dürfen in einem limitierten Budgetrahmen auch Technologien ausprobiert werden, die noch nicht im Einsatz sind, aber das Potenzial haben, die Effizienz zu verbessern und neue Geschäftsfelder zu erschließen.

In einem Gespräch mit der Geschäftsleitung erfahren wir die unternehmerischen Ziele der Kaffeerösterei.

• Der Kundenservice ist aktuell noch nicht ausreichend ausgebaut und beherrscht noch kein Kundenbeziehungsmanagement (CRM). Diese Fähigkeit soll ausgebaut werden. Dabei dürfen auch direkt Chatbots zum Einsatz kommen.
• Im Einkauf und in der Produktion müssen die gekauften bzw. gerösteten Bohnen kontrolliert werden. Dies wird aktuell von Mitarbeitern per Hand erledigt. In Zukunft sollen für die Qualitätssicherung Bilderkennungsverfahren zum Einsatz kommen, um gleichbleibende Ergebnisse zu erzielen.
• Die Werbung soll nicht mehr nur klassisch erfolgen, sondern durch Social-Media-Kampagnen unterstützt werden. Hierfür wird IT-Unterstützung zur Generierung von Social-Media-Content benötigt.

Randbedingungen

Ein Blick in die Kaffeerösterei zeigt, dass die Arbeit größtenteils vor Ort stattfindet. Die zentralen Arbeitsbereiche - Produktion, Lager und Café - sind ebenso wie die Verwaltungsbüros direkt auf dem Firmengelände angesiedelt. Homeoffice spielt nur eine untergeordnete Rolle. Die interne Kommunikation erfolgt überwiegend persönlich, ergänzt durch E-Mail und Telefon. Der Austausch mit Lieferanten und Logistikdienstleistern läuft in der Regel per E-Mail, telefonisch oder über die jeweiligen Online-Portale ab.

Weitere Randbedingungen, die bei einer Bebauungsplanung berücksichtigt werden müssen, ergeben sich aus der IT-Leistungsfähigkeit des Unternehmens. Dabei stellen sich Fragen wie:

• Hat das Unternehmen einen dedizierten IT-Bereich?
• Sind die Prozesse des IT-Bereichs eingespielt? Dies betrifft sowohl den IT-Betrieb als auch die Projektabläufe.
• Hat das Unternehmen Administratoren, DevOps-Mitarbeiter oder Ähnliches, die sich mit den verwendeten oder geplanten Technologien gut auskennen?
• Hat das Unternehmen die passenden Softwareentwickler, falls einzelne Bausteine der IT-Landschaft entwickelt werden müssen?
• etc.

Solche Faktoren müssen bei einer Bebauungsplanung berücksichtigt werden, damit eine mögliche Zielarchitektur überhaupt realisiert werden kann. In jedem Unternehmen gibt darüber hinaus Probleme oder  Schulden in der IT . Diese müssen bewertet und dann gegebenenfalls im Bebauungsplan berücksichtigt werden.

Ebenen und Elemente des Bebauungsplans

Die Bebauungsplanung findet auf den 4  Ebenen der Enterprise Architektur statt. Diese sollen hier kurz wiederholt werden:

• Die Business Ebene befasst sich mit den geschäftlichen Aspekten der Architektur wie  Geschäftsfähigkeiten oder  Geschäftsprozessen.
• Auf der Anwendungsebene werden die  Anwendungen und Systeme betrachtet, die benötigt werden um die Geschäftsprozesse abzubilden und die Daten zu verarbeiten.
• Die Datenebene konzentriert sich auf das Management und die Organisation der  Unternehmensdaten. In der Enterprise Architektur verwendet man hierzu meistens die Abstraktionsebene der  Datenobjekte.
• Die Technologieebene betrachtet die technologische Infrastruktur des Unternehmen mit  IT-Plattformen und  IT-Komponenten als kleinste Bausteine.

Ein Bebauungsplan sollte über mehrere Jahre Bestand haben. Die agile Bebauungsplanung sollte dabei kontinuierlich den aktuellen Erfordernissen angepasst werden. Daher ist es wichtig, sich innerhalb eines Unternehmens auf die Elemente des Plans sowie ihre Formen und Farben zu einigen. Im agilen Kontext ist die Nutzung von Archimate in der Regel nicht notwendig, stattdessen kann ein vereinfachtes  Metamodell verwendet werden. Dabei ist es nicht notwendig, das Rad immer wieder neu zu erfinden, denn:

Binsenweisheit: In allen Unternehmen nutzen Mitarbeiter und Kunden Anwendungen, um Daten zu verarbeiten und Geschäftsprozesse abzuwickeln.

In diesem Blog verwende ich stets die gleichen Farben für die Ebenen und Elemente einer Architektur. Diese sind:

• Gelb/Orangetöne für die Business-Ebene und ihre Elemente
• Blau für die Anwendungsebene und ihre Elemente
• Lila für die Datenebene und
• Grün für die Technologieebene und alle technischen Elemente.

Dies steigert den Wiedererkennungswert von Diagrammen deutlich und erhöht somit auch die Akzeptanz im Unternehmen.

Der Bebauungsplan

Im Folgenden möchte ich zeigen, wie ein vereinfachter Bebauungsplan auf den jeweiligen Ebenen aussehen kann und wie die strategischen Leitlinien und Randbedingungen darin berücksichtigt werden. Ein echter Bebauungsplan in einem Unternehmen ist deutlich komplexer und aufwändiger, aber für die Veranschaulichung der Grundprinzipien genügt das hier Gezeigte.

Randbedingung: Die Organisationsstruktur

Man kann keinen Bebauungsplan für ein Unternehmen erstellen, wenn man dessen Organisationsstruktur nicht kennt. Im vorliegenden Beispiel gehe ich davon aus, dass die Kaffeerösterei organisatorisch in drei fundamentale Bereiche unterteilt ist: Der größte Bereich ist der Produktionsbereich. Hier findet sich alles von der Beschaffung und Logistik bis hin zur Herstellung der Kaffeebohnen. Weiterhin gibt es den Kundenbereich, der das lokale Café und den Online-Shop betreibt, sowie den Verwaltungsbereich, in dem die Führungs- und Unterstützungsprozesse ablaufen.

Diese Organisationsstruktur spiegelt sich in den prozessualen und technischen Strukturen des Unternehmens wider. Sie ist zwar nicht in Stein gemeißelt, aber man sollte die Organisationsstruktur in einem Unternehmen nicht leichtfertig ändern. Wenn eine Anpassung notwendig ist, sollten entsprechende Projekte zur Anpassung der Prozessstrukturen und der Integrationsarchitektur gestartet werden. Wenn man das nicht tut und die hierarchischen und technischen Strukturen auseinanderdriften, führt das mittelfristig zu immer längeren Projektlaufzeiten und einem immer höheren Aufwand für die Abstimmung von Änderungen in Prozessen oder Technologien.

Business Ebene

Im Rahmen der Bebauungsplanung gibt es auf der Business-Ebene zwei gängige Darstellungsformen. Einerseits gibt es die Prozesslandkarte, die vor allem zeigt, wie ein Unternehmen seine Geschäfte abwickelt. Andererseits gibt es die Darstellung als Business Capability Map (Karte der Geschäftsfähigkeiten). Diese Sichtweise zeigt vor allem, was ein Unternehmen tut. Je nachdem, wie ein Unternehmen funktioniert, kann die eine oder die andere Betrachtungsweise nützlicher sein. Allerdings sollte man beachten, dass beide unterschiedliche Dinge aussagen (wie vs. was). Es ist also nur bedingt sinnvoll, beide Sichtweisen im Unternehmen zu verwenden und zusätzlich eine Verknüpfung beider anzustreben. Als Enterprise Architekt lauscht man ins Unternehmen hinein und hört sich an, wovon die Mitarbeiter sprechen. Wenn sie häufiger von  Prozessen oder Abläufen sprechen, dann fokussiert man sich auf die Prozesslandkarte. Wenn die Mitarbeiter im Kerngeschäft hingegen mehr von ihren  Fähigkeiten sprechen, wird die Business Capability Map die führende Sicht. Beide Sichtweisen parallel und gleichwertig zu pflegen, ist sehr aufwendig und nicht produktiv.

Prozesslandkarte oder Business Capability Map: Entscheiden Sie sich für eines davon als führende Darstellung!

Beide Karten zeigen die Tätigkeiten der Kaffeerösterei auf dieser hohen Flugebene und schaffen die Verbindung zur Organisationsstruktur des Unternehmens. Entsprechend der unternehmerischen Ziele sind die neuen Bereiche und Neuerungen gekennzeichnet. In der Prozesslandkarte kämen bei den Kernprozessen die neuen Prozesse Social Media Marketing und Kundenservice hinzu. Die Prozesse in der Logistik und Produktion würden KI-Updates erhalten. Dasselbe zeigt die Sicht der Business Capabilities: Es kommt eine neue Gruppe von Capabilities - das Customer Relationship Management - hinzu, und die Gruppe der Fähigkeiten rund um Verkauf & Marketing wird um die neue Fähigkeit des Social Media Marketings erweitert. Die Updates befinden sich bei den Beschaffungs- und Produktionsfähigkeiten jeweils in der Qualitätssicherung.

Anwendungsebene

Strategische Anwendungs- und Datenlandschaft

Bei einem Bebauungsplan in der Enterprise Architektur ist die Anwendungsebene die „Spinne im Netz”. Sie schafft die Verbindung zwischen der Organisation im Unternehmen, den abstrakten Geschäftsprozessen bzw. -fähigkeiten und den konkreten technischen Systemen. Auf der obersten Flughöhe empfiehlt es sich, die wichtigsten Anwendungen, Integrationssysteme und Datenobjekte gemeinsam auf einer Karte zu betrachten. So erhält man den besten ersten Überblick über die gesamte IT-Landschaft. Dabei darf man allerdings nicht den Fehler machen, zu sehr ins Detail gehen zu wollen. Dafür bleibt in den tiefer liegenden Schichten immer noch genug Zeit.

Die erste Frage, mit der sich ein Architekt beschäftigen muss, ist, nach welchem Muster diese Ebene geschnitten wird. Es gibt verschiedene Möglichkeiten, die in dem Artikel  Enterprise Architektur Schnittkanten ausführlicher erläutert werden. Wichtig ist, diese Entscheidung nicht leichtfertig zu treffen und die Segmentierung dann beizubehalten. Auf dieser Ebene ist es darüber hinaus wichtig, die Schnittkanten zwischen den Segmenten technisch zu realisieren - durch explizite Schnittstellen oder Integrationssysteme. Denn im Gegensatz zu den Segmentierungen der Business-Ebene sind die Schnittkanten auf der Anwendungs- und Datenebene nicht nur konzeptioneller Natur, sondern haben auch technische Implikationen. Weitere Informationen finden Sie auch hier:  Integrationsarchitektur. Die wesentlichen Entitäten auf dieser Ebene sind die  Anwendungen und die  Datenobjekte.

Die hiesige Struktur der Anwendungs- und Datenebene orientiert sich an der Struktur des Unternehmens, das grob nach den folgenden Geschäftsprozessen ausgerichtet ist: Produktionsbereich, Kundenbereich und Verwaltungsbereich. Damit entsteht für die Anwendungs- und Datenebene ein geschäftsprozessorientierter Schnitt. Die drei Bereiche bilden auch auf dieser Ebene eigene Strukturen. Technisch werden diese Strukturen durch Integrationssysteme voneinander abgegrenzt, um das Prinzip  divide et impera einzuhalten.

Mithilfe dieser Karte lässt sich die IT-Landschaft mit den wichtigsten Anwendungen und Datenflüssen im Unternehmen abbilden. Sie bietet einen Überblick über das große Ganze und dient als Ausgangspunkt, um tiefer in die technischen Strukturen des Unternehmens einzutauchen. Auf dem Bild sind die großen Anwendungen zu sehen, die jeweils dem Produktions-, Kunden- oder Verwaltungsbereich zugeordnet sind. Auch Anwendungen, die entsprechend den aktuellen  Unternehmenszielen neu hinzukommen oder sich verändern, sind in der Anwendungslandschaft gekennzeichnet. In einer solchen strategischen Anwendungslandkarte müssen nicht alle Anwendungen des Unternehmens einzeln aufgeführt sein. Es können auch mehrere Anwendungen zusammengefasst werden, wie im Beispiel bei den technischen Verwaltungssystemen, oder sie können ganz weggelassen werden, wenn sie strategisch unbedeutend sind. Diese Sichtweise soll einen strategischen Überblick verschaffen und als Ausgangspunkt für weitere Planungen, beispielsweise für Migrationsprojekte, dienen. Um sich in alle Details der IT-Landschaft einzuarbeiten, nutzt man  das Repository (siehe unten).

Weiterhin sind die wesentlichen Integrationssysteme auf Ebene der  Enterprise-Integration (“Unternehmensintegration”) zu sehen. Diese sind im Beispiel:

• Das Produktions-/Kundenintegrationssystem, über welches die Warenbestände aus Lager und Logistik an den Online-Shop und das lokale Kassensystem gemeldet werden. In die andere Richtung fließen die Bestellungen der Kunden zurück in den Produktionsbereich. Diese Kundenbestellungen werden an das Logistikketten-Management zur Abwicklung übergeben. Ebenfalls in diese Richtung fließen die Verkäufe aus dem lokalen Café. Diese müssen in der Lagerverwaltung erfasst werden. Beide Informationen werden in der Produktionsplanung und -steuerung verwendet, um den Bedarf an Kaffeebohnen zu ermitteln, die produziert werden müssen.
• Das Produktions-/Verwaltungsintegrationssystem, liefert die Kundenbestellungen nach erfolgreicher Bearbeitung in der Logistik an das Buchhaltungssystem. Gleichzeitig werden darüber auch die Lieferantenrechnungen an das Buchhaltungssystem übermittelt.
• Das Kunden-/Verwaltungsintegrationssystem überträgt die Verkäufe aus dem lokalen Kassensystem an das Buchhaltungssystem.
• Die Technische Integration dient dazu, Backups der Daten in lokale Speicher (als Teil der technischen Verwaltungssysteme) zu übertragen.

Neben den bereits genannten Zwecken kann diese Ansicht auch als Ausgangspunkt für strategische Diskussionen dienen. So kommen in dieser Architektur beispielsweise drei Integrationssysteme für die Übertragung von Geschäftssystemen zum Einsatz. Bei Anwendungslandschaften mit wenigen zentralen Datenobjekten und niedriger Last bestünde auch die Möglichkeit, diese drei Systeme durch ein einzelnes abzulösen.

Für die Anwendungen in den verschiedenen Bereichen können unterschiedliche Strategien zur Auswahl und zum Betrieb angewendet werden:

• Der Produktionsbereich umfasst Daten und Anwendungen, die das Kerngeschäft des Unternehmens abbilden. Die Produktivität ist daher oberste Prämisse. Die Maschinen sollten optimal ausgelastet sein und auch bei Störungen der Internetanbindung funktionieren. Daher sollte die Produktionsplanung und -steuerung entweder lokal erfolgen oder ein lokales Cold-Standby nutzen, falls Cloudsysteme ausfallen.
• Im Kundenbereich ist die Usability oberstes Gebot. Die Daten stammen von den Kunden und die Anwendungen stehen in direktem Kontakt mit den Kunden. Der lokale Verkauf sollte im Notfall auch ohne permanente Internetanbindung stattfinden können. Der Verkauf im Online-Shop aber natürlich nicht. An dieser Stelle bieten sich Cloudsysteme an.
• Die Daten und Anwendungen des Verwaltungsbereichs sind zwar für den Betrieb des Unternehmens essentiell, tragen aber nicht zum Umsatz bei. Daher muss der Verwaltungsbereich auf maximale Effizienz getrimmt werden.

Reine Anwendungsebene

Für die technische Bebauungsplanung hat die Sicht einer reinen Anwendungsebene keine allzu große Bedeutung, da sich in der IT-Architektur fast alles um die Beziehungen zwischen Entitäten dreht. Diese Beziehungen in Form von Datenflüssen kommen in einer reinen Anwendungssicht jedoch nicht vor. Allerdings kann diese Perspektive für andere Anwendungsfälle eine hilfreiche Grundlage sein. So könnte beispielsweise eine Heatmap über die Kosten von Anwendungen erstellt werden oder das Alter der jeweiligen Anwendungen könnte gekennzeichnet werden, um den Renovierungsbedarf in der IT-Landschaft zu ermitteln.

Abbildungen auf die Business-Ebene

Um ein rundes Bild der Bebauungsplanung zu erhalten, muss die Anwendungsebene mit der Business-Ebene verbunden werden. Hierfür gibt es zwei Arten von Abbildungen. Einerseits gibt es die Abbildung der Geschäftsprozesse auf die Anwendungslandkarte. Da wir uns für einen geschäftsprozessorientierten Schnitt entschieden haben, funktioniert diese Abbildung ziemlich gut.

Andererseits können die Anwendungen auch auf die Business Capabilities abgebildet werden. Aufgrund des geschäftsprozessorientierten Schnitts der Anwendungslandschaft ergibt sich dabei jedoch kein ganz so harmonisches Bild:

Es ist nicht ungewöhnlich, dass Anwendungen und Geschäftsfähigkeiten in n:m-Verhältnissen zueinander stehen. Im obigen Bild wird die Anwendung Logistikketten-Management beispielsweise von den Fähigkeiten in der Beschaffung, der Produktion und dem Customer-Relationship-Management benötigt. Umgekehrt benötigen die Fähigkeiten Röstung, Personalmanagement und IT-Betrieb jeweils mehr als eine Anwendung. Das ist konzeptionell völlig in Ordnung und Teil des Business-Capabilities-Konzepts. Allerdings sollte man nicht versuchen, eine Anwendungslandschaft anhand von Business Capabilities zu segmentieren. Aufgrund der m:n-Zuordnungen kann das nur chaotisch werden.

Datenebene

Auf der Datenebene wird die Segmentierung der darüber liegenden Anwendungsebene durch Integrationssysteme abgebildet. Sind diese Segmentierungen auf dieser Ebene nicht zu sehen, liegt das Problem der  nicht überlappenden Ebenen vor. In diesem Fall sollten schnellstmöglich Restrukturierungsprojekte gestartet werden.

Neben den genannten Integrationssystemen zeigt diese Ansicht auch weitere Datenflüsse ohne Segmentgrenzenüberschreitung an, beispielsweise die Materialbestände, die von der Lagerverwaltung zur Produktionsplanung und -steuerung fließen. Im Gegensatz zur strategischen Anwendungs- und Datenarchitektur sind auf der Datenebene hier schon mehr Details zu sehen. Besonders wichtig sind die Datenflüsse von und zu den Anwendungen - nicht nur zu den Segmenten, wie es in der rein strategischen Sicht der Fall ist. Für diese Sicht eignen sich die Datenflüsse der  Ecosystem Integration, der  Enterprise Integration und, begrenzt auf die wesentlichen Datenobjekte, der  Inter Application Integration. Von dieser Ebene aus kann tiefer in die Technik, zum Beispiel in die  Integrationsmuster, eingestiegen werden.

Technologieebene

Die Technologieebene in der Bebauungsplanung ist sehr tief. Allerdings ist sie nicht mehr das alleinige Spielfeld von Enterprise Architekten. Zu dieser Ebene zählen Netzwerkdiagramme ebenso wie Softwarearchitekturen, die in UML beschrieben werden, sowie weitere technische Diagramme. Der Übergang von der Anwendungs- auf die Technologieebene kann beispielsweise wie folgt aussehen:

Dieses Diagramm ist für die Bebauungsplanung strategisch relevant, da es aufzeigt, auf welchen Plattformen welche Anwendungen laufen oder aus welchen Kernkomponenten sie bestehen. Darüber hinaus zeigt es anschaulich, welche Systeme in der Cloud und welche lokal vor Ort laufen. Diese Informationen sind für die Erstellung und Umsetzung einer Technologie- und Cloud-Strategie von großer Bedeutung.

Taucht man tiefer in die Technologieebene ein, trifft man auf technischere Diagramme, die beispielsweise den Aufbau einer Anwendung zeigen. Diese Diagramme sind strategisch weniger relevant, für die konkrete Umsetzung einer Anwendung jedoch umso wichtiger.

Das obige Diagramm zeigt den Aufbau eines Authentifizierungs- und Autorisierungsdienstes gemäß GAIA-X. Die Kaffeerösterei könnte diesen Dienst über ihren Cloud-Provider nutzen, ohne sich Gedanken über technische Details machen zu müssen.

Das Repository

Die gezeigten Sichten der Bebauungsplanung sind im Unternehmen lediglich die Spitze des Eisbergs. Sie sind für strategische Planungen und die Steuerung von Projekten notwendig. Um diese Sichten zu erstellen und nachhaltig zu pflegen und zu aktualisieren, sind Repositories erforderlich, in denen alle Entitäten und Zusammenhänge verwaltet werden. Je nach Reifegrad einer EA-Organisation gibt es dafür verschiedene Möglichkeiten.

Am Anfang kann man ganz hemdsärmelig mit Excel-Tabellen beginnen und die wichtigsten Fähigkeiten, Prozesse, Anwendungen und Datenobjekte inventarisieren. Wenn das Unternehmen wächst und die Enterprise Architektur professioneller wird, darf  Der Excel-Absprungpunkt nicht verpasst werden.

Weiter fortgeschrittene EA-Organisationen pflegen ihre Anwendungs-Repositories in Systemen wie  LeanIX oder der  Sparx-Plattform. Zusätzlich kommen Prozessmanagement-Tools wie  Signavio oder  ARIS zum Einsatz. Wenn die Datenebene im Unternehmen von großer Bedeutung ist, werden zusätzlich Datenkataloge wie die von  Alation oder  Alex Solutions genutzt.

All diese Werkzeuge können in gewissem Umfang visualisieren, aber keine strategischen Sichten automatisch generieren. Diese Sichten sind in ihrer Aussagekraft und ihrem Nutzen zu individuell. Die Tools können hierfür lediglich Vorstufen oder Detailansichten bereitstellen.

Wenn man versucht, ein ganzes Repository auf einmal zu visualisieren, entsteht in der Regel ein Bild wie das obige: der „Ball of Mud”. Das ist keine Schwäche der Tools - die automatische Visualisierung weiß schlichtweg nicht, was zu einem gegebenen Zeitpunkt im Unternehmen von Bedeutung ist. Das kann nur ein Enterprise Architekt im Dialog mit seinen Stakeholdern entscheiden.

Typische Fehler bei der Bebauungsplanung

Dieses Beispiel war so gewählt, dass es die zu verdeutlichenden Punkte gut veranschaulicht hat. In der Realität ist die Bebauungsplanung jedoch wesentlich komplexer. Kompromisse sind beispielsweise dann erforderlich, wenn sich Anwendungen nicht eindeutig Geschäftsprozessen oder Geschäftsfähigkeiten zuordnen lassen. Oder wenn die Strukturen im Unternehmen mit der Zeit gewachsen sind und sich manche Integrationssysteme nur noch als historisch gewachsen erklären lassen. An dieser Stelle muss sich eine IT-Leitung jedoch die strategische Frage stellen, ob es nicht an der Zeit ist, aufzuräumen, um sich Luft für die Zukunft zu verschaffen. Es wäre ein großer Fehler, dies zu ignorieren und die Bebauungsplanung an der Realität vorbeizutreiben.

Weitere Fehler treten häufig bei der Durchführung von Bebauungsplanungen in Unternehmen auf. Einige habe ich selbst schon gemacht, andere nur beobachtet. Auf die drei häufigsten möchte ich hier gezielt hinweisen, damit Sie sie vermeiden können!

Ebenen überlappen nicht

In der Bebauungsplanung schaffen die verschiedenen Gruppierungen auf den unterschiedlichen Ebenen jeweils eigene Strukturen. Im Prozessmodell sind die Gruppierungen in Kernprozesse, Managementprozesse und Unterstützungsprozesse auf jeden Fall angelegt. Im Capability-Modell werden Geschäftsfähigkeiten gruppiert (z.B. Beschaffung, Produktion, Enterprise Support etc.). In der Anwendungs-, Daten- und Technologielandschaft entstehen durch Gruppen von zusammengehörigen Anwendungen, ihre Schnittstellen und Integrationssysteme harte technische Abgrenzungen. Zudem gibt die Hierarchie der Unternehmensorganisation eine Struktur vor. Wenn sich diese verschiedenen Strukturen nur minimal oder gar nicht überschneiden, führt das zu komplexen Problemen.

Bei minimaler Überlappung könnten sich Prozess- und Capability-Modell strukturell widersprechen. Im obigen Beispiel der Rösterei ist die Beschaffung beispielsweise eine Gruppe von Fähigkeiten auf der obersten Ebene des Capability-Modells. Im Prozessmodell sind dagegen Einkauf und Logistik die primären Elemente und ein Prozess namens Beschaffung existiert nicht. Auf der Anwendungsebene könnten Lagerverwaltung und Online-Verkauf in derselben Anwendung durchgeführt werden, die von einem Team namens Kundenkontakte verantwortet wird, das in Zukunft auch das Customer Relationship Management übernehmen wird.

Ein solches Szenario führt zu andauernden Konflikten im Unternehmen bezüglich der Zuständigkeiten, lähmt neue Projekte und macht den Betrieb der Anwendungen unsicher. Stattdessen sollte bei der Bebauungsplanung darauf geachtet werden, dass sich die Strukturen der verschiedenen Ebenen weitgehend decken, die Organisation im Unternehmen darauf ausgerichtet ist und alle Ebenen die gleichen Begriffe verwenden.

Standing und Ownership

Eine Bebauungsplanung ist ein komplexer Vorgang, bei dem zahlreiche Parameter berücksichtigt und der Dialog mit vielen Stakeholdern geführt werden muss. Es werden viele Gespräche geführt, in denen sich die Vorstellungen unterschiedlicher Abteilungen mitunter widersprechen. Als Enterprise Architekt mit der Verantwortung für die Bebauungsplanung versucht man natürlich, alle Interessen zu berücksichtigen. Doch selbst bei nicht widersprechenden Anforderungen ist das nicht immer möglich. So kann es leicht passieren, dass ein Architekt zwischen die Fronten gerät. In solchen Situationen ist es wichtig, dem Sturm standzuhalten und auf Basis von nachvollziehbaren Fakten eine eigene, begründbare Position zu beziehen. Die Enterprise Architektur ist für die Bebauungsplanung verantwortlich. Das darf sie zwar nicht im Elfenbeinturm - losgelöst von allen anderen - tun. Aber sie darf sich auch nicht wie ein Fähnchen im Wind drehen. Eine Enterprise Architektur muss im Unternehmen ein eigenes Standing aufbauen. Mit der Zeit lösen sich dann auch die Konflikte auf.

Details und Kernaussagen

Die manuell erstellten strategischen Diagramme der Bebauungsplanung dürfen nicht zu viele Details enthalten. In einem solchen Diagramm ist es beispielsweise unwichtig, ob ein System eine Schnittstelle per REST, JSON-RPC oder GraphQL anspricht. Architekten sollten der Versuchung widerstehen, alles Mögliche in ein einziges Diagramm packen zu wollen. Dabei entsteht normalerweise etwas wie  Das Umzugstransporter-Diagramm.

Bevor ein Architekt ein Diagramm fertigstellt, sollte er sich folgende Frage stellen: Was will ich damit aussagen? Es kann in Ordnung sein, mit einem Diagramm mehrere Aussagen zu treffen. Die Kernaussage sollte jedoch klar erkennbar und nicht unter einem Berg von Details vergraben sein.

Konsequenzen der Bebauungsplanung

Eine gut und regelmäßig durchgeführte Bebauungsplanung ist die Grundlage für eine effiziente, kostengünstige, sichere und langlebige IT-Landschaft, die das Unternehmen bestmöglich unterstützt. Dies ist daran erkennbar, dass die Laufzeiten für neue IT-Projekte relativ zum Branchendurchschnitt kurz sind. Ein weiteres Merkmal ist die schnelle Adaption neuer Technologien, sofern diese technisch und wirtschaftlich sinnvoll ist. Und nicht zuletzt sieht man es daran, dass ein Unternehmen mit guter IT-Unterstützung schnell in neue Märkte oder Geschäftsfelder vorstoßen kann.

Was aber, wenn die Bebauungsplanung nicht gut gemacht wird? Das merkt man daran, dass Projekte gefühlt ewig bis zur Fertigstellung brauchen. Oder daran, dass Entwicklungsteams absurde Zeiten schätzen, die sie für eine Realisierung benötigen - was darauf zurückzuführen ist, dass sie die Umgebung nicht kennen oder mit massiven Altlasten rechnen. Beides sind Probleme, die darauf schließen lassen, dass keine gute Bebauungsplanung vorliegt. Schließlich kann man eine schlechte Bebauungsplanung auch daran erkennen, dass Enterprise Architekten sich in einen Elfenbeinturm zurückziehen und ihre Modelle um ihrer selbst willen entwickeln. Ihre Wortwahl und ihre Architekturen haben sich vom Vokabular des restlichen Unternehmens entfernt.

Wie kann man also dafür sorgen, dass die Bebauungsplanung gut gemacht wird? Achten Sie darauf, dass sich die Strukturen in den Ebenen der Enterprise Architektur bestmöglich überlappen. Man wird niemals 100 % erreichen, aber ein Großteil der Strukturen sollte kongruent sein. Achten Sie außerdem darauf, dass die Architekten, die die Bebauungsplanung durchführen, sich viel im Unternehmen bewegen und mit möglichst vielen Fachbereichen sprechen. Außerdem sollten sie hin und wieder auch die Verantwortung für die konkrete Umsetzung strategischer Projekte übernehmen, um die Implikationen ihrer Bebauungsplanung aus erster Hand zu spüren.

Wer planen kann, muss auch bauen können!

Fazit

Eine gute Bebauungsplanung für ein Unternehmen ist keine leichte Aufgabe und kann nicht innerhalb weniger Tage umgesetzt werden. Es ist nicht schwer, bunte Diagramme zu erstellen, aber es ist aufwändig, die benötigten Informationen von der Geschäftsleitung, der IT-Leitung und weiteren Stakeholdern einzuholen. Bei einem  agilen Vorgehen können erste Ergebnisse nach ca. drei Monaten erwartet werden. Danach sollte die Bebauungsplanung regelmäßig alle sechs bis zwölf Monate aktualisiert werden - je nachdem, wie schnell sich das Unternehmen verändert oder strategische Projekte voranschreiten.

Bei all der Komplexität darf jedoch nicht vergessen werden, dass eine Bebauungsplanung niemals zum Selbstzweck durchgeführt werden sollte. Sie hat einen Sinn und ein klares Ziel - das kostet meistens auch Geld. Vor Beginn einer Bebauungsplanung sollte man sich deshalb auch Gedanken darüber machen, welche Mittel ein Unternehmen für die herbeigeführte Veränderung aufbringen möchte. Bei einer schlechten Bebauungsplanung ist das Geld verloren. Bei einer guten Planung hingegen stößt das Unternehmen in neue Märkte vor und vervielfacht so seine Investition.