Seit Beginn der Industrialisierung vor mehr als 150 Jahren ist der Maschinenbau Vorbild für gelungene Standardisierung. Das Deutsche Institut für Normung e.V. (DIN) schätzt den gesamtwirtschaftlichen Nutzen von Normen alleine für Deutschland auf 17. Mrd. Euro pro Jahr. Normen schaffen eine Plattform zur Kommunikation und versetzen ihre Anwender in die Lage, Wissen in einer verbindlichen Sprache zu teilen. Leider ist es bis heute nicht gelungen, das erfolgreiche Konzept der Maschinenbauer zur standardisierten Dokumentation in die Welt der Enterprise-Architektur zu übertragen.

Eine zentrale Ursache dafür ist die Schnelllebigkeit der IT-Branche. Der permanente Wandel führt dazu, dass IT-Projekte gerne an einer nachhaltigen Dokumentation der Basisinformationen, die zur "Konstruktion" einer Lösung beigetragen oder diese fundamental beeinflusst haben, sparen. Leider nur eine vermeintliche Ersparnis, denn bei dem Blick über den Tellerrand des einzelnen IT-Projektes sehen wir immer wieder, dass ein fehlendes Dokumentationsfundament langfristig zu erhöhten Kosten führt. Der Trend zu agilen Entwicklungsmustern verschärft diese Situation.

Mancher mag jetzt denken, dass hier jemand zum alten Wasserfallmodell zurück möchte. Darum geht es aber nicht. Unabhängig davon ob sequenzielle, evolutionäre oder agile Vorgehensmodelle eingesetzt werden, in keinem Fall sollte auf eine ordentliche Beschreibung der Basis des zu "konstruierenden" Systems verzichtet werden. Das gilt durchgehend von den ersten Entwurfsschritten bis zur fertigen Lösung. Wer das nicht glaubt, kann gerne versuchen ein Haus ohne technische Zeichnungen, Statik-Dokumentation, Leitungspläne usw. zu bauen. IT-Projekte, die mitunter deutlich teurer sind als ein Einfamilienhaus, werden aber immer noch zu oft ohne langfristig nutzbare und valide Dokumentation der "Umwelt", in welche die neue Lösung "passen" muss, gestartet. Das ist brandgefährlich, egal welches Vorgehensmodell oder Entwicklungsparadigma verfolgt wird.

Lesetipp: Agil versus Wasserfall

Enterprise Architecture: Mehr als Dokumentation

Doch nur das jeweilige System zu beschreiben reicht nicht aus. In einer Organisation sind immer unterschiedliche Projekte zu synchronisieren. Beispiele dafür können sein:

• die Einführung von SAP S/4HANA, mit der sich die IT-Abteilung gerade beschäftigt,

• die Reorganisation des Konstruktionsbereiches, initiiert durch die Geschäftsleitung oder

• die Umstellung der Logistik, die mehrere Abteilungen gleichzeitig betrifft, weil ein neues Zentrallager gebaut wurde.

Tauschen Sie gerne die genannten Beispiele gegen die in Ihrem Unternehmen vorliegenden Projekte aus. Allgemein gilt: Alle Projekte haben einen Informations- und Dokumentationsbedarf, der sich in vielen Bereichen überschneidet und voneinander abhängt. Wenn dieser Informationsbedarf nicht einheitlich befriedigt wird, entstehen im besten Fall "nur" projektindividuell redundante Dokumentationen und vermeidbarer Aufwand.

Im schlimmsten - und leider häufigeren - Fall führen Projektarbeiten, die auf nicht abgestimmten Informationen beruhen zu Inkonsistenzen und Projektproblemen, die um ein Vielfaches teurer ausfallen können als "nur" eine doppelte Dokumentation. Genau an dieser Stelle setzt eine Enterprise Architecture an: Sie liefert mit einer integrierten Dokumentation das Fundament dafür, größere (IT-)Projekte unter Nutzung architektonischer Regeln miteinander zu synchronisieren. Ähnlich wie bei der Erstellung eines Gebäudes der Innenausbau mit den Arbeiten an der Elektrik, der Wasserversorgung und der Heizung abgestimmt werden muss. Wenn die Verantwortlichen dabei unterschiedliche Pläne verwenden, ist das Chaos vorprogrammiert.

Das zu verhindern, erfordert eine verbindliche und für alle verständliche "Grunddokumentation" des betroffenen Objektes. In unserem Fall ist es kein Gebäude, sondern eine Organisation in der z.B. ein IT-Projekt umgesetzt werden soll, eine Abteilung neu strukturiert wird und logistische Abläufe zu justieren sind. Eine Enterprise Architecture liefert mit einer übergreifend nutzbaren und einheitlichen Informationsbasis das Fundament auf dem Projekte individuelle Planungen aufbauen können.

Lesetipp: IT-Projekt der Finanzverwaltung gerät zum Desaster

Enterprise Architecture Management: Sprachprobleme

Im Bereich der Enterprise-Architekturen hat sich aber bis heute kein allgemeinverbindlicher Standard durchgesetzt. Die ISO/IEEE Normen 42010 und 42020 bieten zwar eine Reihe von allgemeinen Beschreibungen zum Management von Architekturen, aber auch nicht mehr. Um eine integrierte Enterprise-Architektur für ein Unternehmen aufzubauen ist es erforderlich, selber die benötigte Struktur zur Informationsdokumentation festzulegen. Erfolgt dies nicht, ist auch die gemeinsame Nutzung von Inhalten in verschiedenen Projektkontexten erschwert. Die Situation ist vergleichbar mit einer Gruppe von Menschen die jeweils andere Sprachen sprechen. Damit eine Kommunikation stattfinden kann, ist immer eine Übersetzung erforderlich. Da wäre es doch einfacher, wenn alle nur eine Sprache verwenden.

In der Welt einer integrierten Enterprise Architecture ist es leider ein wenig komplizierter. Es gibt nicht die eine Sprache, mit der alle relevanten Informationen dokumentiert werden können. Es ist aber möglich, für bestimmte Teilbereiche der Enterprise-Architektur geeignete Notationen zu definieren, die Schnittstellen der Notation aufeinander abzustimmen und gleichzeitig die Summe der Notationen zu minimieren. Basis für die Definition eines solchen Sets an Notationen ist die im Artikel "Rahmen für den Bau einer Enterprise-Architektur" entwickelte Ontologie. Unterschieden werden dabei zwei Dimensionen die eine Matrix bilden. Die horizontale Achse der Matrix gliedert Spalten nach den zu dokumentierenden Inhaltstypen. Betrachtet werden

• Leistungen,

• Domänen,

• Systeme,

• Geschäftsprozesse,

• Organisationsstrukturen und

• Informationen.

Auf der vertikalen Achse erfolgt eine hierarchische Gliederung in fachliche Ebenen, eine Mapping Ebene und technische Ebenen (s. Abbildung 1).

Die Spalten und Zeilen ergeben eine Matrix aus 36 Feldern. Jedes Feld definiert einen wichtigen Inhaltstyp zur Beschreibung einer Enterprise-Architektur. Dabei ist zu beachten, dass nicht jede Zelle zwingend mit Inhalten zu füllen ist. In Enterprise-Architecture-Projekten muss individuell bestimmt werden, welche Inhalte relevant sind und als Fundament für die Dokumentation des betrachteten Unternehmens zu erfassen sind. Um eine schlanke Dokumentation zu gewährleisten, ist darauf zu achten, nur wenige Notationen und Artefakt-Typen zu definieren. Dann verwendet jede Zelle eine einheitliche "Sprache", so dass verschiedene Projekte Inhalte einheitlich erstellen, lesen und wenn erforderlich auch anpassen können. Der Aufwand für das Enterprise Architecture Management sinkt damit deutlich.

Lesetipp: So retten Sie gefährdete IT-Projekte

Lean Enterprise: Zwei Wege - ein Ziel

Die Erfassung fachlicher und technischer Inhalte sowie die Verbindung zwischen diesen kann grundsätzlich auf zwei verschiedenen Wegen erfolgen. Entweder wird ein "One-size fits all" oder ein "Best of Breed" Ansatz verfolgt. Der "One-size fits all" Ansatz versucht eine möglichst breite Abdeckung der Matrix mit einer oder einer kleinen Gruppe von Notationen herzustellen. Häufig wird dieser Weg von Standardisierungsorganisationen empfohlen, die für die Entwicklung und Pflege einer Notation verantwortlich sind. Zum Beispiel ist aus Sicht der Object Management Group (OMG) - als verantwortliche Organisation für die Business Process Model and Notation (BPMN) - BPMN sowohl für die Dokumentation von fachlichen Ende-zu-Ende-Prozessen bis zur technischen Prozessautomatisierung geeignet. Auch wenn keine Standardisierungsorganisation die Hybris besitzt eine Notation als für alle Felder der Matrix geeignet zu benennen, so wird in der praktischen Anwendung doch deutlich, dass gelegentlich die Grenzen der Einsetzbarkeit der eigenen Notation überspannt werden.

Demgegenüber steht mit dem "Best of Breed"-Ansatz die klare Fokussierung einer Notation auf einen eng umrissenen Bereich der Matrix, meistens nur auf eine einzelne Zelle. Durch diese Spezialisierung wächst die Anzahl der eingesetzten Notationen und der Aufwand zur Integration über die Felder der Matrix. Die praktische Erfahrung zeigt, dass eine praktikable Lösung für den Aufbau einer integrierten Enterprise-Architektur in der Kombination verschiedener Notationen liegt. Der Schwerpunkt sollte aber immer im Bereich des Best-of-Breed-Ansatzes verortet sein. Im Zweifel ist es besser, eine für die Dokumentation der Inhalte nur einer Zelle der Enterprise Architecture geeignete Notation zu verwenden und ggf. einen erhöhten Integrationsaufwand zu anderen Feldern der Matrix zu akzeptieren. Dem gegenüber steht: Durch die Verwendung einer mehrere Felder übergreifenden Notation eine vereinfachte Integration zu erreichen, die aber zum Verlust der inhaltlichen Genauigkeit führt. Diese Heuristik in Kombination mit einer reduzierten Selektion von Artefakten verschiedener Notationen liefert das Fundament einer Lean-Enterprise-Architektur.

Abbildung 2 zeigt eine Auswahl der Artefakte und Notationen die zum Aufbau einer Lean-Enterprise-Architektur geeignet sind und gleichzeitig einen vertretbaren Integrationsaufwand besitzen (die Zeile "Implementierung" der Matrix repräsentiert reale Artefakte, weshalb für diese Ebene keine Notationen angegeben werden). Wichtig ist, dass nicht alle Artefakte einer Notation für das Fundament der Enterprise Architektur benötigt werden. Vielmehr ist es Ziel, eine begrenzte Auswahl an Artefakten zu verwenden und einen Kompromiss zwischen dem Aufwand zur Erstellung und dem Nutzen des Modells in verschiedenen Anwendungsfällen zu erreichen. Weiterhin ist wichtig zu erwähnen, dass die aufgeführten Artefakte und Notationen unabhängig von Modellierungswerkzeugen zu betrachten sind. Der vorgestellte Notationsmix kann mit verschiedenen Modellierungswerkzeugen abgebildet werden. Die folgende Auflistung erläutert die jeweils ausgewählten Artefakte der verschiedenen Notationen zum Aufbau einer Lean-Enterprise-Architektur:

ArchiMate

ArchiMate ist eine visuelle Modellierungssprache mit einer Reihe von Standardsymbolen zur Beschreibung, Analyse und Kommunikation von Enterprise-Architekturen. Sie definiert eine Reihe von Artefakten und deren Beziehungen zur Darstellung von Architekturbeschreibungen.

• Produkte stellen eine zusammenhängende Sammlung von Dienstleistungen oder physischen Produkten dar, die internen oder externen Kunden angeboten werden.

• Applikationsservices repräsentieren definierte Dienste, die bestimmte - meist betriebswirtschaftliche - Leistungen erzeugen oder bearbeiten.

• Technologieservices repräsentieren definierte Dienste, die bestimmte - meist technische - Leistungen erzeugen oder bearbeiten.

• Applikationskomponenten beschreiben gekapselte Anwendungsfunktionalitäten, die modular und austauschbar sind. Sie stellen Applikationsservices über Schnittstellen zur Verfügung.

• Applikationsfunktionen beschreiben ein automatisiertes Verhalten, das von Applikationskomponenten ausgeführt wird.

• Applikationsschnittstellen beschreiben Zugangspunkte an dem einem Benutzer, andere Anwendungskomponenten oder Knoten-Applikationsservices zur Verfügung gestellt werden.

• Knoten stellen physische Ressourcen dar, die andere physische Ressourcen hosten, manipulieren oder mit ihnen interagieren.

• Geräte beschreiben physische IT-Ressourcen, auf denen Systemsoftware gespeichert oder zur Ausführung bereitgestellt wird.

• Systemsoftware beschreibt Software, die eine Umgebung zum Speichern, Ausführen und Verwenden von Applikationskomponenten bereitstellt oder als Voraussetzung für deren Nutzung erforderlich ist.

ARIS

die Architektur integrierter Informationssysteme (ARIS) bietet einen umfassenden Rahmen an Konzepten zur systematischen Dokumentation betrieblicher und informationstechnologischer Zusammenhänge.

• Funktionen beschreiben fachliche Aufgaben oder Tätigkeiten, die zur Umsetzung oder Unterstützung eines - meist betriebswirtschaftlichen - Ziels ausgeführt werden. Es hat sich als sinnvoll erwiesen, Funktionen nur zur Dokumentation übergeordneter Prozessstrukturen und Aktivitäten (s.u.) zu deren Detailbeschreibung zu nutzen (in manchen Modellierungswerkzeugen werden beide Artefakt-Typen aber nicht eindeutig abgegrenzt).

• Geschäftsobjekte beschreiben physische oder virtuelle Gegenstände die zur Leistungserstellung in einem Geschäftsprozess benötigt oder bearbeitet werden.

• Dokumente beschreiben physisch vorhandene Informationen, die zur Leistungserstellung in einem Geschäftsprozess benötigt oder bearbeitet werden.

• Organisationseinheiten beschreiben Gruppen, die zur Erzielung von betriebswirtschaftlichen Zielen erforderliche Funktionen (Tätigkeiten) bündeln.

• Stellen beschreiben die kleinsten identifizierbaren Organisationseinheiten innerhalb eines Unternehmens. Stellen werden Mitarbeitern (Personen) zugeordnet.

• Rollen typisieren einzelne Personen mit gleichen Eigenschaften oder gleichen Rechten.

• Lokationen (Standorte) beschreiben geographische Strukturen in denen eine Organisation aktiv ist bzw. die zur geographischen Strukturierung der betriebswirtschaftlichen Tätigkeiten von Organisationen erforderlich sind.

• Personen sind Mitarbeiter einer Organisation. Sie können den Organisationseinheiten, denen sie angehören, und den Funktionen, die sie ausführen oder für die sie verantwortlich sind zugeordnet werden.

BPMN

die BPMN (Business Process Model and Notation) erlaubt es, fachliche und technische Prozesse in einer einheitlichen Notation zu beschreiben. Damit schafft BPMN eine standardisierte Brücke zwischen dem Geschäftsprozessdesign und der Prozessimplementierung in IT-Systemen. Sie bietet in den unten aufgeführten Artefakt-Kategorien eine Vielzahl von Sub-Typen (um die Darstellung an dieser Stelle übersichtlich zu halten wird auf deren detaillierte Darstellung verzichtet). Für weitergehende Informationen zu den Sub-Typen wird auf das Referenzdokument der OMG verwiesen.

• Aktivitäten beschreiben (Detail-)Tätigkeiten, die eine Organisation in Prozessen durchführt. Aktivitäten können atomar oder nicht-atomar (zusammengesetzt) sein. Im Kontext der Lean-Enterprise-Architektur sind Aktivitäten und Funktionen abzugrenzen. Es hat sich als sinnvoll erwiesen, Funktionen (s.o.) nur zur Dokumentation übergeordneter Prozessstrukturen und Aktivitäten zur Detailbeschreibung zu nutzen. In manchen Modellierungswerkzeugen werden beide Artefakt-Typen aber nicht eindeutig abgegrenzt.

• Ereignisse treten im Verlauf der Bearbeitung von Prozessen auf. Sie beeinflussen den Ablauf von Prozessen und haben in der Regel eine Ursache (Trigger) oder eine Auswirkung (Ergebnis).

• Gateways werden verwendet, um die Divergenz und Konvergenz von Prozesssequenzen zu beschreiben bzw. zu steuern. Sie bestimmen, wie einzelne Pfade in Prozessen verzweigen, zusammengeführt und verbunden werden.

• Datenobjekte liefern Informationen, die zur Ausführung von Aktivitäten erforderlich sind bzw. von diesen erzeugt werden. Datenobjekte können einzelne Objekte oder eine Sammlung von Objekten darstellen.

UML

die Unified Modeling Language (UML) ist eine Entwurfsmethodik und graphische Visualisierungssprache für den objektorientierten Entwurf von Softwaresystemen. Sie fokussiert auf die Beschreibung von Inhalten im Rahmen der Analyse und dem Design objektorientierter Anwendungen.

• Klassen repräsentieren Mengen von Objekten mit ähnlichen Verhalten, Fähigkeiten oder Verantwortlichkeiten.

• Attribute beschreiben Datendefinition einer Klasse.

• Komponenten beschreiben den physischen Teil von Systemen.

• Pakete definieren Namesräume, die verwendet werden um Elemente zu gruppieren, die semantisch verwandt sind und sich gemeinsam ändern können. Es ist ein universeller Mechanismus, um Elemente in Gruppen zu organisieren.

• Artefakte (Notationsobjekt der UML Notation) beschreiben physische Einheiten, die durch einen Softwareentwicklungsprozess oder durch Bereitstellung und Betrieb eines Systems erzeugt werden.

Die genannten Notationen können in Modellierungswerkzeugen verschiedener Hersteller abgebildet werden. Bei der Auswahl der Notationen und Artefakt-Typen für die Lean- Enterprise-Architektur wurde besonderer Wert darauf gelegt, einen Kompromiss zwischen inhaltlicher Tiefe und einer einfachen Gesamtstruktur des entstehenden Modells zu erhalten. Es ist immer zu berücksichtigen, dass die Enterprise-Architektur nur das Fundament liefert, um den Informationsbedarf einer Organisation ohne Redundanzen und Inkonsistenzen zu erfüllen. Es geht nicht darum, für jedes Projekt detaillierte Inhalte vorzugeben. Es muss aber gewährleistet werden, dass die individuellen Projekte auf dem definierten (Informations-)Fundament einer Lean-Enterprise-Architektur durch die Erstellung individueller Erweiterungen aufbauen können. (bw)