Enterprise Architektur Schnittkanten

Inhalt

Das Prinzip Divide & Conquer

Eines der wichtigsten Prinzipien in der gesamten Informatik ist Divide & Conquer - zu Deutsch: Teilen und Herrschen: Immer dann, wenn Probleme zu komplex werden, um sie vollständig zu überblicken, teilt man sie auf. Die Komplexität der Teile ist geringer als die des Ganzen und damit leichter beherrschbar. Dieses Grundprinzip findet sich in vielen Entwurfsmustern und abgeleiteten Prinzipien wieder (z.B. Schichtenmodelle,  MVC,  EVA, usw.). Für das  Enterprise Architektur Management bedeutet dies, dass eine  Enterprise Architektur in verschiedene Teile zerlegt werden sollte und diese Teile dann weitgehend unabhängig voneinander betrachtet werden können. Durch die Zerlegung in Teile wird die Komplexität des Gesamtsystems reduziert. Der Artikel  Kohäsion, Kopplung, Komplexität beschreibt die Details der Komplexität und die Vorteile, die man erhält, wenn man sie reduziert.

Eine Gefahr in der IT- und Unternehmensarchitektur ist immer das konzeptionelle Divide & Conquer, also virtuelle Schnittkanten ohne Konsequenzen, die nur auf dem Papier und in schönen Architekturdarstellungen existieren. Damit das Prinzip seine Wirkung entfalten kann, müssen die Schnittkanten der Enterprise Architektur durch reale Abgrenzungen gelebt werden.

Enterprise Architektur Schnittkanten auf verschiedenen Ebenen

Die Unternehmensarchitektur kann auf verschiedenen Ebenen aufgeteilt werden. Es kommt darauf an, was man genau erreichen will: Will man das Management einer IT-Landschaft vereinfachen? Dann ist ein Schnitt auf der  Business Ebene richtig. Soll die Integration von Anwendungen entflochten werden, dann schneidet man auf  Anwendungs-- und  Datenebene. Soll die Technologie effizienter genutzt werden, ist ein Schnitt auf der  Technologieebene richtig. Es ist auch üblich, mehrere dieser Schnitte durchzuführen - man sollte aber immer darauf achten, dass die Schnitte kompatibel bleiben und sich nicht gegenseitig ad absurdum führen.

Schnittkanten auf der Business Ebene

Auf der Business Ebene gibt es zwei verschiedene Varianten des Zuschnitts. Welcher Schnitt der richtige ist, hängt davon ab, worauf sich das Unternehmen fokussieren will. Wenn im täglichen Sprachgebrauch der Mitarbeitenden und des Managements vor allem  Geschäftsprozesse vorkommen, dann bietet es sich an, sich an einer Prozesslandkarte zu orientieren und die Geschäftsebene auf der obersten Ebene in die Prozessarten Kernprozesse, Managementprozesse und Unterstützungsprozesse zu unterteilen. Die Prozesslandkarte wird dann zum führenden Artefakt für die Organisation der Geschäftsebene.

Prozessarten als Schnittkanten auf der Prozesslandkarte
Prozessarten als Schnittkanten auf der Prozesslandkarte

Wenn das Unternehmen weniger über Prozesse und das Management mehr über  (Geschäfts-)Fähigkeiten spricht, dann fasst man eben diese Fähigkeiten in  Domänen zusammen und nutzt diese als obersten Ordnungsrahmen auf der Business Ebene.

Domänen als Schnittkanten in der Business Capability Map
Domänen als Schnittkanten in der Business Capability Map

Zum Ziel führen beide Varianten. Es wird jedoch empfohlen, nicht nach beiden Varianten gleichzeitig zu schneiden. Denn das Ziel eines Schnitts auf Business Ebene ist die Vereinfachung des IT-Managements im Unternehmen. Durch die gleichzeitige Verwendung beider Varianten schafft man aber vor allem Abstimmungsaufwand und endlose Diskussionen darüber, was genau ein Prozess und was eine Fähigkeit ist. Das macht das IT-Management später alles andere als einfacher.

Schnittkanten auf der Anwendungs- und Datenebene

Ob eine Anwendungslandschaft in verschiedene  Sektoren unterteilt werden muss, hängt von ihrer  Komplexität ab. Ein kleines Unternehmen braucht seine Anwendungslandschaft nicht zu unterteilen. Wenn die Anwendungslandschaft größer wird, ist eine Unterteilung sehr empfehlenswert, um den Überblick zu behalten. Wieviele Anwendungen in einen Sektor kommen, ist hochindividuell. Als Faustregel kann man sagen: Soviele, dass es überschaubar bleibt. Wie eingangs erwähnt, ist das Ziel auf dieser Ebene, die Komplexität der Anwendungslandschaft beherrschbar zu halten. Dazu ist es unerlässlich, die konzipierten Schnittstellen technisch umzusetzen. Beispielsweise durch die Verwendung von APIs, Fassaden oder Netzwerksegmenten.

Für den Schnitt auf dieser Ebene gibt es zahlreiche Varianten. Alle sind zielführend - wenn man aber auch auf Business- oder Technologieebene schneidet, sollte man kompatible Schnittkanten wählen. Anwendungen und Geschäftsprozesse bzw. Geschäftsfähigkeiten stehen zwar in einer m:n-Beziehung, d.h. mehrere Anwendungen können mehrere Geschäftsfähigkeiten unterstützen und umgekehrt. Man macht sich aber das Leben leichter, wenn man auf allen Ebenen annähernd ähnliche Schnittkanten wählt.

  • Geschäftsprozessorientierter Schnitt: Sofern die Anwendungen relativ eindeutig den Geschäftsprozessen zugeordnet werden können, kann dieser Schnitt auch für die Anwendungslandschaft übernommen werden. Dasselbe gilt für den domänenorientierten Schnitt.

  • Nutzerorientierter Schnitt: Die Anwendungslandschaft kann nutzerorientiert geschnitten werden, sofern nur wenige Anwendungen von 2 Nutzergruppen gleichzeitig genutzt werden. Beispielsweise können Sektoren für Mitarbeiter in der Zentrale eines Unternehmens und in dessen Filialen eingerichtet werden. Ergänzt werden diese durch Sektoren für Kunden in Europa und für Kunden in Asien.

  • Datenorientierter Schnitt: Die Sektoren können auch nach der Art der von den Anwendungen verarbeiteten Daten unterteilt werden. Dies könnten z.B. sein: Kundendaten, Mitarbeiterdaten, Geschäftspartnerdaten, IoT-Daten und Analysedaten.

  • Datenverarbeitungsorientierter Schnitt: Die Anwendungen werden in Sektoren eingeteilt, die jeweils primär  transaktionale,  analytische oder  translytische Datenverarbeitung betreiben.

  • Pace Layered Architecture: Die in der  Pace Layered Architecture verwendeten Systemtypen können ebenfalls Schnittkanten einer Anwendungslandschaft bilden. Hier wird unterschieden zwischen: Systems of Record (weitgehend standardisierte Systeme im Unternehmen), Systems of Differentiation (die die Kernprozesse eines Unternehmens abbilden, mit denen es sich von Wettbewerbern unterscheidet) und Systems of Innovation (in denen Neues ausprobiert wird).

  • CAP-Theorem: Das  CAP-Theorem klassifiziert Anwendungen in verteilten Systemen nach Konsistenz (Consistency), Verfügbarkeit (Availability) und Ausfalltoleranz (Partition Tolerance). Ein System kann niemals 2 dieser Eigenschaften gleichzeitig erfüllen. Daraus ergeben sich die Anwendungsklassen CA, CP und AP, welche als Schnittkanten in einer Anwendungslandschaft genutzt werden können.

  • Lastorientierter Schnitt: Ein Unternehmen kann Anwendungen mit unterschiedlichen Lastanforderungen haben. Auf einem Buchhaltungssystem kann in einem kleinen Unternehmen beispielsweise wenig Last sein. Auf dem Online-Shop desselben Unternehmens dagegen eine sehr hohe Last. Dementsprechend kann die Anwendungs- und Datenebene in Hochlast-, Mittellast- und Niedriglast-Sektoren eingeteilt werden.

  • Sicherheitsorientierter Schnitt: Mit besonderem Fokus auf die Daten können auch Sektoren eingerichtet werden, die Anwendungen unterscheiden, welche jeweils geheime, vertrauliche, sensible oder öffentliche Daten verarbeiten.

Schnittkanten in einer Anwendungslandschaft
Schnittkanten in einer Anwendungslandschaft

Eine Kombination der hier genannten Varianten ist weniger kritisch als auf der Business Ebene. Bei Bedarf können daher auch auf der Anwendungsebene mehrere Schnittmengen gebildet werden. Man sollte es aber auch hier nicht übertreiben und für jede Anwendung einen eigenen Sektor entwerfen.

Schnittkanten auf der Technologieebene

Die gesamte Technologieebene setzt sich aus kleineren Elementen zusammen, die zu größeren zusammengefasst und gegeneinander abgegrenzt werden. Das Spiel der  Kohäsion und Kopplung findet im Großen wie im Kleinen statt: Klassen werden zu Softwarekomponenten kombiniert und durch Schnittstellen voneinander abgegrenzt usw. In diesem Abschnitt geht es aber um die Schnittkanten, die es ermöglichen, die Architektur in einem ganzen Unternehmen zu strukturieren. Dafür sind Klassen zu klein. Die kleinste technische Entität auf der Ebene der Enterprise Architektur ist die  IT-Komponente. Für eine Strukturierung auf Technologieebene sollten IT-Komponenten zu  IT-Plattformen zusammengefasst werden. Gibt es für diese IT-Plattformen dedizierte Verantwortliche, haben sie einen eigenen Lebenszyklus und werden sie als  IT-Produkte weiterentwickelt, dann bilden sie die optimalen Schnittkanten auf der Technologieebene.

Schnittkanten evolvieren mit der Zeit

Evolviert die IT-Landschaft im Unternehmen ganz oder teilweise zum Beispiel von einem  Vernetzten System auf ein  digitales Ökosystem, dann wird sie naturgemäß komplexer als zuvor. Eine Anwendung besteht dann aus einer Gruppe von Micro, Mini oder Macro Services, die orchestriert werden müssen. Gleichzeitig wird die Anzahl der Anwendungen zunehmen, denn die Anwendungen werden sich in Richtung kleinerer Apps entwickeln und weniger multifunktionale Suiten sein. Das wird dann ungefähr so aussehen:

Komplexität der Kommunikation einer IT Landschaft in einem vernetzten, monolithischen System (links) und einem Digitalen Ökosystem (rechts)
Komplexität der Kommunikation einer IT Landschaft in einem vernetzten, monolithischen System (links) und einem Digitalen Ökosystem (rechts)

Die Anwendungen links sind an ihre Hosts gebunden. Die Kommunikation über das Netzwerk findet nur zwischen den drei dargestellten Monolithen statt. Auf diese Weise bilden die Hosts einen natürlichen Rahmen um die Anwendungen, der die Komplexität der Anwendungslandschaft unter Kontrolle hält. Leider schränkt dieser Rahmen auch die Skalierbarkeit, Integrationsfähigkeit und Flexibilität ein. In einem digitalen Ökosystem (rechts im Bild) fällt dieser natürliche Rahmen weg und die Anwendungen kommunizieren direkt miteinander. Das erhöht schlagartig die Skalierbarkeit, Integrationsfähigkeit und Flexibilität der Gesamtlandschaft. Leider auch die Komplexität. Aus diesem Grund müssen innerhalb eines digitalen Ökosystems Maßnahmen in Form von Schnittstellen auf Anwendungsebene getroffen werden, um die Komplexität wieder zu reduzieren. Denn die Zahl der Anwendungen wird in Zukunft weiter steigen und damit auch die Komplexität. Ähnliches geschieht auf der Business- und Technologieebene, wenn neue Geschäftsfelder hinzukommen oder sich Technologien weiterentwickeln, z.B. in Richtung  Cloud.