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.

Aufteilung

Das Metamodell ist in 4 Ebenen und eine Säule unterteilt. Diese Aufteilung ermöglicht es, die Architektur aus verschiedenen Blickwinkeln zu betrachten - der Business-Sicht, der Anwendungssicht, der Datensicht und der Technologiesicht. Natürlich stehen die Ebenen nicht für sich allein, sondern sind mit den Entitäten der anderen Ebenen verbunden.

Neben den Entitäten auf den einzelnen Ebenen gibt es auch Gruppen von Entitäten. Auf der Business-Ebene gibt es eine weiche Gruppierung namens  Domäne, die eine Klammer um Geschäftsfähigkeiten, Geschäftsprozesse und IT-Produkte bildet. Weiche Gruppierung bedeutet hier, dass es durchaus n:m Zuordnungen geben kann: Ein Geschäftsprozess kann sich z.B. über mehrere Domänen erstrecken und eine Geschäftsfähigkeit kann in mehr als einer Domäne eine Rolle spielen.

Auf der Anwendungs- und Datenebene spreche ich dagegen von  Sektoren. Dies ist eine harte Gruppierung und bedeutet, dass eine solche Gruppe von Anwendungen technisch von anderen Anwendungen abgegrenzt werden sollte. Zum Beispiel durch API-Gateways etc. Eine Anwendung sollte tatsächlich nur in einem Sektor vorkommen und ein Datenobjekt sollte nur in einem Sektor beheimatet sein.

Auf der technologischen Ebene gibt es Gruppen von IT-Komponenten, die als  IT-Plattformen zusammengefasst werden können. Auch diese Gruppe hat eine technische Realität. Eine IT-Plattform kann jedoch problemlos als Basis für verschiedene Anwendungen in der Ebene darüber verwendet werden.

Entitäten

Business Ebene

Diese Ebene befasst sich mit den geschäftlichen Aspekten einer Organisation. Mehr Informationen zu der Ebene selbst befinden sich im Artikel  Enterprise Architektur

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.

Mehr über die  Business Capability

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.

Mehr über den  Geschäftsprozess

IT-Produkt (IT Product)

Ein IT-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 IT-Produkte: Ist die IT im Unternehmen rein Demand-orientiert, gibt es keine IT-Produkte.

Mehr über das  IT-Produkt

Anwendungsebene

Diese Ebene führt die Geschäftsaspekte mit den technologischen Aspekten zusammen. Eine ausführliche Beschreibung der Anwendungsebene befindet sich im Artikel  Enterprise Architektur

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-Plattform 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.

Mehr über die  Anwendung.

Datenebene

Die Datenebene muss nicht notwendigerweise getrennt von der Anwendungsebene modelliert werden. Ob man die Datenebene in die Anwendungsebene integriert, hängt davon ab, welche Rolle die datenzentrierten Prozesse im Unternehmen spielen. Sind sie sehr wichtig, sollte die Datenebene separat modelliert werden. Wenn sie keine große Rolle spielen, sollte diese Ebene mit der Anwendungsebene zusammengefasst werden. Mehr Informationen zur Datenebene im Artikel  Enterprise Architektur

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.

Mehr über das  Datenobjekt

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. Mehr Informationen zur Technologieebene im Artikel  Enterprise Architektur

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  IT-Plattformen - die sich heute aber nicht mehr auf einzelne Hosts beschränken, sondern selbst kleine Ökosysteme sind. Zwischen den IT Komponenten bestehen sehr viele wechselseitige Beziehungen und je nach Unternehmen kann man einzelne Varianten davon als eigene Entitäten ausprägen (z.B. Services, Software Bibliotheken, etc.)

Enterprise Architektur Management ist kein Asset Management. 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. Die IT Komponenten stellen jedoch den Übergangspunkt zu einem möglichen Asset Management in einem Unternehmen dar.

Mehr über die  IT-Komponente

Cross-Funktionale Säule

Die Cross-Funktionale Säule vereinigt Entitäten, 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 benötigen, 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 Entitäten 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 Unternehmensarchitektur ist unerlässlich. Zu der Sprint-Aufgabe, es zu definieren, kommt jedoch die Marathon-Aufgabe, es zu leben und zu kommunizieren. Da ein solches Modell umso erfolgreicher ist, je weiter es verbreitet ist, sollte es nicht zu komplex sein. Unternehmensarchitekten sollten in der Lage sein, ein Metamodell auch fachfremden Personen zu erklären. Um den Wiedererkennungswert des Modells zu erhöhen, ist es sinnvoll, immer die gleichen Farben und Symbole für die Entitäten zu verwenden. Letztlich ist es nicht so wichtig, jede hier aufgeführte Entität in einem eigenen Metamodell zu haben - der Konsens im Unternehmen über das Modell als Ganzes ist entscheidend!