Metamodelle für die Enterprise Architektur

Wofür ein Metamodell?

Gleichwohl es nicht einer gewissen Komik entbehrt, in jedem Projekt- oder Architekturmeeting erneut zu erörtern wofür die Kästchen, Kreise und Linien stehen, ist es doch langfristig wesentlich effizienter, sich in einem Unternehmen auf ein Metamodell für die Architektur zu einigen.

Ein Metamodell im Rahmen einer Enterprise Architektur dient dem Zweck, im Unternehmen eine einheitliche Sprache zu sprechen. Meta bedeutet, dass es ein Modell ist, auf dessen Basis weitere Modelle gebaut werden. Das Metamodell beschreibt die Bausteine, die verwendet werden, um konkrete Modelle zu bauen. Diese konkreten Modelle können beispielsweise Zielarchitekturen, Bebauungspläne, Big Pictures oder Kontextsichten sein. Architekturdiagramme auf Basis eines solchen Metamodells stellen auch den Absprungpunkt dar, um tiefer in verschiedene Sichten, wie BPMN- oder UML-Diagramme einzutauchen. Sie liefern einen Rosettastein (eine Übersetzung) zwischen Geschäftsstrategien, Business Anforderungen und technischen Realisierungen.

Gleichzeitig dient das Metamodell der Kommunikation von Enterprise Architekten mit anderen Einheiten. So spricht man zum Beispiel mit dem Produktmanagement über Produkte, setzt diese in Beziehung zu Anwendungen und damit zu IT Komponenten. Auf Basis eines solchen Modell kann man dann direkt sagen, welche Produkte nicht mehr verkauft werden können, weil beispielsweise log4j kaputt ist.

Ein gemeinsames Verständnis der Begriffe im Unternehmen ist wichtig, damit man von den gleichen Dingen spricht. Wenn man ein zeitkritisches Projekt umsetzen muss, ist nichts lästiger als in jeder Besprechung von vorne zu klären, was man genau unter einem “System”, einer “Komponente” und einer “Anwendung” versteht. Besonders das Wort “System” sollte im Unternehmen soweit wie möglich vermieden werden. Falls es unvermeidbar ist, ist es als typisches Bindestrichwort nur mit einem vorangestellten Bindestrich und einer Spezifizierung zu verwenden. Zum Beispiel: “Server-System”, “Informations-System”, “Speicher-System”.

Existierende Metamodelle

Bei der Wahl eines Metamodells für das eigene Unternehmen muss das Rad nicht neu erfunden werden. Es existieren bereits einige dieser Modelle. Zwei davon möchte ich hervorheben:

• Die Archimate Specification ist eine sehr umfangreiche Spezifikation eines Metamodells für eine Enterprise Architektur. Der grundsätzliche Aufbau des Modells ist sehr strukturiert und durchdacht. Im praktischen Einsatz im Unternehmen ist Archimate jedoch vor allem ein Werkzeug für Experten. Archimate-Modelle sind sehr präzise, dafür für Laien schwer verständlich. Um über ein eigenes Metamodell nachzudenken, empfehle ich, sich den Archimate Standard anzusehen und entsprechend den eigenen Bedürfnissen anzupassen. Da der Standard recht weit verbreitet ist, sollte das eigene Metamodell nicht im Widerspruch zu Archimate stehen.
• Das abstrakte Datenmodell der EAM-Software LeanIX ist ebenfalls ein guter Anfang für ein eigenes Metamodell. Es bietet sich natürlich vor allem dann an, wenn man plant, diese Software im Unternehmen einzusetzen. Aber auch unabhängig davon, liefert das Modell eine gute Vorlage.

Kriterien

Ein Metamodell ist ein ziemlich abstraktes Ding. Es liegt in der Natur der Sache, dass so etwas schwer zu verstehen ist. Aber gerade deswegen muss es aus meiner Sicht folgenden Kriterien genügen:

• Es muss so einfach wie möglich sein - jeder Mensch in einem Unternehmen, der schonmal mit IT-Projekten zu tun hatte, sollte es verstehen können
• Es muss zum Unternehmen passen - Die verwendeten Begriffe des Modells müssen zum Wording im Unternehmen passen
• Es muss wiedererkennbar sein - das heißt, alle Modelle, die auf dem Metamodell basieren, müssen gleiche Farben und Formen für die definierten Entitäten verwenden

Vorschlag für ein Metamodell

Wie ein Metamodell aussehen kann, soll folgendes Beispiel verdeutlichen:

Die Abbildung zeigt ein exemplarisches Metamodell, das als Ausgangspunkt für eigene Überlegungen genutzt werden kann. Keinesfalls ist dieses Modell die letztendliche Wahrheit und für jeden Zweck geeignet. Aber es ist eine gute Vorlage, um ein Modell für das eigene Unternehmen zu entwickeln.

Elemente der Business Ebene

Die Elemente der Business Ebene färbe ich grundsätzlich in gelb/orangen Farben ein.

Geschäftsfähigkeit (Business Capability)

Eine Geschäftsfähigkeit ist die Möglichkeit eines Unternehmens, etwas wertschöpfendes zu tun um ein Geschäftsziel zu erreichen. Typische Geschäftsfähigkeiten sind: “Artikel verkaufen”, “IT bereitstellen”, “Rohstoffe einkaufen”, etc. Die Geschäftsfähigkeiten geben dem Unternehmen seinen Sinn. Daher muss alles was im Unternehmen stattfindet einer Geschäftsfähigkeit zugeordnet werden können. Die Geschäftsfähigkeiten sollten nicht zu feingranular gewählt werden: 100 Geschäftsfähigkeiten pro Unternehmen sind ein guter Richtwert um die korrekte abstrakte Flugebene zu erreichen. Über den Geschäftsfähigkeiten - außerhalb des Metamodells - stehen Ziele und Strategien des Unternehmens.

Geschäftsprozess (Business Process)

Ein Geschäftsprozess beschreibt eine Kette von wertschöpfenden Vorgängen im Unternehmen. Er muss immer einer Geschäftsfähigkeit zugeordnet werden können. Wichtig ist dabei, dass es sich nicht notwendigerweise um technisch implementierte Prozesse handelt. Das manuelle Ausfüllen eines Formulars für eine Rückerstattung kann auch ein Geschäftsprozess sein. Beispiele können sein: Der “Offer-to-Order-Prozess”, der den Weg von einem Angebot zu einer Bestellung beschreibt oder der “Order-to-Fullfilment-Prozess”, der eine Bestellung bis zur Auslieferung modelliert. Rein technische Prozesse, wie beispielsweise das Ablegen von Dateien in einem Cloud Speicher sind keine Geschäftsprozesse.

Produkt (Business Product)

Ein Produkt ist ein wertschöpfendes Erzeugnis eines Unternehmens. Es besteht auf jeden Fall aus einem Geschäftsprozess und kann durch eine Anwendung implementiert werden. Die Anwendung steht zum Produkt nur in einer Kann-Beziehung, weil die Anwendung nur bei digitalen Produkten gebraucht wird. Also zum Beispiel bei einem Cloud Speicher als Produkt. Rein physikalische Produkte, wie beispielsweise eine Schraube, werden zwar durch einen Geschäftsprozess erzeugt, benötigen aber für ihre Realisierung keine Anwendung. Nicht jedes Unternehmen hat Produkte - ein einfacher Händler, der nur Ware einkauft und verkauft, produziert nichts - und hat somit keine Produkte in seinem Metamodell.

Elemente der Anwendungsebene

Für die Anwendungsebene verwende ich normalerweise blaue Farbtöne.

Anwendung (Application)

Eine Anwendung ist eine Gruppe von IT Komponenten, die gemeinsam einer Geschäftsfähigkeit dienen. Eine Anwendung ist in ihrer Größe weder nach oben noch nach unten beschränkt. Bei einer Suchmaschine, die hunderte Server und Speichernetzwerke benötigt, kann es sich genauso um eine Anwendung handeln, wie bei einer kleinen Excel-Tabelle, die eine Angebotskalkulation durchführt. Wichtig ist dabei, den Namen einer Anwendung gut zu wählen. “Das SAP” ist genauso ein schlechter Name wie “Die Quickwin-Tabelle”. Der Name einer Anwendung sollte idealerweise etwas über ihren Zweck aussagen: “Das Acme-Kundendatenmanagement”. Im Rahmen des Aufbaus einer Enterprise Architektur werden einer Anwendung verschiedene Attribute zugeordnet, wie Eignung für eine Aufgabe, Lebenszyklus, etc. Eines der wesentlichsten Attribute ist der/die Verantwortliche. Nur wenn eine Anwendung eine/n Verantwortliche hat, kümmert man sich um sie.

Der Charakter einer Anwendung verändert sich mit fortschreitender Digitalisierung. Während in der Stufe der Inselsysteme und der Vernetzten Systeme eine Anwendung an einen Host gebunden ist, hat sie sich in der Stufe der Digitalen Ökosysteme daraus befreit. Da ein Host eine IT Komponente ist, existiert die Verbindung im Metamodell von IT Komponente zu Anwendung. Unternehmen, die sich rein auf der Stufe der Digitalen Ökosysteme befinden, haben diese Verbindung nicht.

Es wird immer Grenzfälle geben, in denen man sich dafür oder dagegen entscheiden kann, eine Gruppe von IT Komponenten als eine Anwendung zu bezeichnen. Letztendlich kommt es darauf an, wie die Geschäftsfähigkeiten aussehen. Ein Kubernetes Cluster kann für einen Cloud-Provider eine Anwendung sein, weil sein Geschäft darin besteht, Cloud Leistungen zu verkaufen. Im Gegenteil hierzu ist der Kubernetes Cluster bei einem Werkzeughersteller nur eine IT Komponente, weil dieser Kubernetes Cluster lediglich für den Betrieb anderer Anwendungen benötigt wird. Ein Fall bei dem ich mich selbst oft auf dieser Grenze bewege, sind Integrationssysteme. Streng genommen verkaufen nur die wenigsten Unternehmen Integration. Doch ich modelliere sie dennoch gerne als Anwendungen, weil sich dadurch erstens Datenflüsse zwischen Anwendungen sehr gut darstellen lassen. Und zweitens sind die Integrationssysteme die Basis für die Digitalen Ökosysteme und sie haben damit eine herausragende Bedeutung. Um die Semantik einzuhalten definiere ich die Geschäftsfähigkeit Digitalisierung: Die Fähigkeit des Unternehmens, seine Geschäftsprozesse zu digitalisieren um dadurch effizienter, flexibler und zukunftssicherer zu werden.

Elemente der Datenebene

Die Datenebene muss nicht notwendigerweise separat von der Anwendungsebene modelliert werden - wenn sie es wird, dann aber in lila Farbtönen. Ob man die Datenebene in die Anwendungsebene integriert, kommt darauf an, welche Rolle datenzentrierte Prozesse im Unternehmen spielen. Sind sie besonders wichtig, würde ich die Datenebene separat modellieren. Spielen sie keine große Rolle, würde ich diese Ebene mit der Anwendungsebene zusammenfassen.

Datenobjekt (Data Object)

Ein Datenobjekt ist ein Satz von Daten, die geschäftsmäßig im Unternehmen verarbeitet werden. Ein solches Objekt kann zum Beispiel eine Kundenadresse oder ein Lieferantenauftrag sein. Dabei müssen die Bestandteile des Objekts nicht notwendigerweise zusammen gespeichert werden. Ein umfangreiches Datenobjekt namens Kunde könnte aus der Kundenadresse, die in der Adressverwaltung gespeichert ist, sowie der Kundenkommunikation, die in einer CRM-Anwendung gespeichert ist, bestehen. Rein technische Daten, wie zum Beispiel die Konfiguration eines Servers, sind keine Datenobjekte.

Elemente der Technologieebene

Während die darüber liegenden Ebenen vor allem abstrakte Konzepte und Entitäten umfassen, die eine Steuerung des Unternehmens möglich machen, befinden sich auf der Technologieebene konkrete technische IT Komponenten. Die Elemente der Technologieebene haben bei mir grundsätzlich grüne Farbtöne.

IT Komponente (IT Component)

Eine IT Komponente ist ein technischer Baustein, der alleine oder zusammen mit anderen eine Anwendung formt. Es handelt sich hierbei vor allem um Software Komponenten (Bibliotheken, Microservices, etc.), Hardware Komponenten ((virtuelle) Server, Infrastrukturkomponenten, etc.) oder um Service Komponenten im Sinne von Cloud Diensten wie Object Storage Services oder Computing Services. In frühen Stufen der Digitalisierung (Inselsysteme und Vernetzte Systeme) sind auch Hosts vertreten, die eine Ausführungsumgebung für Anwendungen bieten. In einem moderneren Kontext spricht man auch gerne von Anwendungsplattformen - die sich heute aber nicht mehr auf einzelne Hosts beschränken, sondern selbst kleine Ökosysteme sind. Unabhängig von ihrer Größe und dem Wort “Anwendung” im Namen, ist eine Anwendungsplattform aber doch nur eine IT Komponente.

Die Enterprise Architektur ist weder ein Asset Management noch eine CMDB, somit werden in einem Enterprise Architektur Modell keine einzelnen Instanzen einer Software oder Hardware inventarisiert, sondern nur der Typ. Die EA beachtet also nicht den Server Nr. 225, sondern nur den Typ HP Proliant Server.

Als Symbol für die IT Komponente verwende ich generisch das Komponentensymbol aus der UML. Um in einem tieferen Detailgrad mehr Übersichtlichkeit zu erzeugen, ersetze ich das eigentliche Komponentensymbol rechts oben im Rechteck aber auch gelegentlich durch z.B. ein Schnittstellensymbol oder ein Datenbanksymbol - wenn es sich um eine IT Komponente des jeweiligen Typs handelt.

Elemente der Cross-Funktionalen Säule

Die Cross-Funktionale Säule vereinigt Elemente, die Auswirkungen auf alle Ebenen haben, aber nicht in untrennbarer Beziehung zu den Kernentitäten stehen.

Nutzergruppe (User Group)

In einigen Anwendungsfällen ist es interessant zu wissen, welche Nutzergruppen welche Geschäftsfähigkeit ausfüllen, in welche Geschäftsprozesse sie involviert sind oder welche Anwendungen sie benutzen. Aus diesem Grund kann eine entsprechende Entität in der Cross-funktionalen Säule modelliert und mit den Kernentitäten verknüpft werden.

Projekt (Project)

Projekte werden gestartet, um Veränderungen in eine bestehende Unternehmenslandschaft zu bringen. Daher können Projekte Auswirkungen auf alle Elemente im Metamodell haben, zum Beispiel:

• Das Unternehmen implementiert eine neue Fähigkeit wie Lieferkettenmanagement
• Eine bestehende on-premise Anwendung wird durch eine neue SaaS-Anwendung ersetzt
• In der Komponente Datenbank‚ wird MySQL durch PostgreSQL ersetzt

Aspekt (Aspect)

Aspekte sind nonfunktionale Anforderungen, die ebenfalls auf mehrere Entitäten im Modell Auswirkungen haben und somit cross-funktional modelliert werden sollten. Ein bekanntes Beispiel hierfür ist die Verfügbarkeit. Die Verfügbarkeit eines Geschäftsprozesses (“Artikel verkaufen”) ist etwas anderes als die Verfügbarkeit einer Anwendung (“Billing Application”) und wieder was anderes als die Verfügbarkeit der MySQL-Datenbank der Billing Application.

Anforderungen (Requirement)

Anforderungen sind detaillierte Beschreibungen einzelner Entitäten. Diese Entität kann in bestimmten Szenarien eine Rolle spielen - zum Beispiel, bei einer Modernisierung der IT-Landschaft. Bei einem solchen Vorhaben ist es sehr nützlich, die Anforderungen an die einzelnen Entitäten auf einem hohen Level explizit zu benennen.

Fazit

Ein Metamodell für eine Architektur im Unternehmen ist essentiell. Zu der Sprint-Aufgabe es zu definieren, kommt allerdings die Marathon-Aufgabe, es zu leben und zu kommunizieren. Da ein solches Modell erfolgreicher ist, je weiter es verbreitet ist, sollte es nicht allzu komplex sein. Enterprise Architekten sollten in der Lage sein, ein Metamodell auch Fachfremden zu erklären. Für die Wiedererkennung des Modells bietet es sich an, für die Elemente immer die gleichen Farben und Symbole zu verwenden. Letztendlich kommt es gar nicht so sehr darauf an, jede hier genannte Entität in seinem eigenen Metamodell zu haben - der Konsens im Unternehmen über das Modell als ganzes ist wesentlich!