Model-Based Business Engineering, Blog by Dr. Juergen Pitschke, +49 351 30935193 Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!g

Komplex vs. Kompliziert - Teil II

1     Komplex oder Kompliziert – Grundprinzipien der Modellierung einer Architektur - Einführung

In meinem letzten Post habe ich argumentiert, dass Komplexität eine notwendige Eigenschaft einer Architektur ist, um Stabilität, „Agilität“ zu sichern. Komplexe Modelle benötigen komplexe Modelle und Lösungen.  Gleichzeitig will kein Anwender komplizierte, nicht pflegbare Modelle haben.

Wichtige Grundprinzipien, die notwendige Komplexität zu erreichen und gleichzeitig Kompliziertheit zu vermeiden und Pflegbarkeit zu sichern ist das Prinzip „Separation of Concerns“ und die Einführung definierter Abstraktionsstufen. Das will ich in der Folge betrachten.

2     Separation of Concerns und Architektur-Frameworks

Im Markt existieren mehrere Architektur-Frameworks, die uns helfen unsere Modelle zu organisieren und das Prinzip „Separation of Concerns“ umzusetzen.

Die m.E. wichtigsten Frameworks für mich sind das Zachman-Framework (https://www.zachman.com/about-the-zachman-framework) und das Archimate-Framework (siehe z.B. https://en.wikipedia.org/wiki/ArchiMate). Beide können uns helfen, welche Modellelemente notwendig sind und wie diese zusammengehören. Beide können aufeinander abgebildet werden.

Ich selbst bin ein Zachman-Fan, da es vielfältiger ist und gleichzeitig im Gegensatz zu Archimate methodenneutral ist und mit allen Methoden eigesetzt werden kann, natürlich auch mit Archimate oder TOGAF.

Es teil „die Welt“ in verschiedene Abstraktionen ein, das „Was“, das „Wie“, das „Wo“, das “Wer“, das „Wann“ und das „Warum“. Ein gutes Modell in einer der Kategorien adressiert genau eine Abstraktion, verschiedene Abstraktionen sind miteinander verbunden. Dadurch wird das interessierende Subjekt umfassend beschrieben, ohne dass die verschiedenen Aspekte vermischt und schlecht pflegbar werden. So werden Prozesse in einer Abstraktion beschrieben werden (das Wie), benutzte Konzepte in einer Anderen (dem Was).

3     Welche Abstraktionen sollen wir wählen?

Eine Frage, die sich daraus in der Praxis ergibt, ist, welche Abstraktionen wir benötigen, wie wir diese Inhalte darstellen und wie diese verknüpft sind? Wollen wir Geschäftsprozesse darstellen, sprechen wir sicher über die Abstraktion „Wie?“, sprechen wir über die verwendeten Konzepte über das „Was?“ Wie verhält es sich aber mit Geschäftsregeln und Geschäftsentscheidungen? Eine Argumentation ist, dass es sich bei diesen Artefakten um zusammengesetzte Objekte handelt, die insbesondere dazu dienen verschiedene Abstraktionen miteinander zu verbinden. Andererseits stellt sich die Frage, was wir mit dem jeweiligen Inhalt bezwecken. Hauptzwecke eines Entscheidungsmodells ist es meist Anleitung zu geben, wir würden ein solches Modell daher der Abstraktion „Wie?“ zuordnen.

4     Mehrere Modelle in einer Abstraktion

Das heißt, in einer Abstraktion finden wir mehrere Modelle, die miteinander verbunden sind. Ein Beispiel sind Prozessmodelle und Entscheidungsmodelle. Das wir beide Aspekte trennen sollten und die Beschreibung der Prozesse nicht mit der Beschreibung der Entscheidungen vermischen sollten, ist bekannt. Prozesse benötigen die Beschreibung von Entscheidungen, beide sind miteinander verbunden.

5     Abstraktions-Niveaus

Eine Problematik der Zuordnung von Modellen zu Abstraktionen ist die Frage der Betrachtung von Abstraktionsstufen. Oft wird versucht zu viele Abstraktionsstufen zu definieren, Inhalte werden unklar und zu detailliert beschrieben. John Zachman betonte bei der Beschreibung des originalen Frameworks zu detailliert beschrieben. Anwender fragen oft nach Hilfe bei der Bestimmung der Abstraktionsstufen. Ich glaube, die magische Zahl dabei ist DREI. Das lässt cih einmal aus der Zahl der Elemente ableiten (man überlege nur, wie viele Elemente je nach Komplexität der Abstraktionsstufen entstehen). Verschiedene Theorien bezeichnen die Abstraktionsstufen rein numerisch, Level 1, Level 2. Level 3, usw. Davon halte ich nicht viel. Besser ist es die Niveaus nach Zweck zu benennen. Dann ist es auch einfacher, zu entscheiden, ob wir das jeweilige Detaillevel benötigen oder nicht.

Für die grundsätzlichen Niveaus Business Concepts und System Logic (siehe www.zachman.com) verwende ich z.B. folgende Abstraktionsstufen:

 Abstraktionstufen 3 

Zur Erinnerung: Auch hier handelt es sich um ein Framework, nicht um ein Dogma.

Betrachten wir Geschäftsprozessoptimierung allgemein, benötigen wir vielleicht alle Abstraktionsstufen in „Business Concepts“. Aktuell laufen viele Projekte zur Einführung der GDPR-Richtlinie. Dabei liegt der Schwerpunkt auf dem Operator View (mit den „Procedures of Operation) und der Verbindung zu „System View“ in „System View“ und vielleicht anderen Sichten. 

6     Werkzeugunterstützung

Wir benötigen auch Unterstützung durch die verwendeten Werkzeuge. Wir benötigen Funktionen, um Modelle und Modellelemente zu verfeinern (wir bleiben im selben Typ von Modell; z.B. verfeinern wir einen Subprozess wieder in eine Prozessbeschreibung) oder Modelle und Modellelemente zu verknüpfen (wir wechseln den Modelltyp, um andere Sichten darzustellen; z.B. wir verknüpfen ein Geschäftsprozessmodell mit einem Entscheidungs-modell). Gute Werkzeuge unterstützen diese Arten von Verknüpfung. Qualiware oder Visual Paradigm unterstützen das zum Beispiel.

Tags: Business Architecture, Agilität