8. Schritt: Anwendungsarchitektur und Technologiearchitektur

© BMI DV

Das Bild stellt die Modellierungsfunktionalität der IT-Lösung dar, die von der Maßnahme PMT eingeführt wird. In beiden Ebenen sind Funktionen zu sehen: Oben in Gelb die bereits bekannten (Geschäfts-)Funktionen, die für intern benötigte Prozesspakete stehen. In diesem Fall sind das die Bereiche Software-Dokumentation, Anforderungsmanagement, Prozessmodellierung, Organisationsdokumentation, Architekturmanagement und Risikomanagement. Jeder dieser Funktionen versammelt eine Anzahl von Prozessen unter ihrem Dach, die hier jedoch nicht dargestellt werden.

Stattdessen finden wir in der unteren Ebene wieder Funktionen, dieses Mal aber sind die Kästchen Blau gefüllt.

„Eine Anwendungsfunktion (Application Function) ist eine automatisiere Aktivität (behavior), die von einer Anwendungskomponente durchgeführt werden kann. Die Funktion ist ausschließlich intern, im Gegensatz zu einem Anwendungsdienst (Application Service).“

Die Anwendungsfunktionen, die von der IT-Lösung Prozessmanagement angeboten werden, sind in Bezug auf die Modellierung ArchiMate, BPMN, CMMN, DMN, UML und WKD. Als Verbindung zwischen Anwendungsfunktion und (Geschäfts-)Funktion habe ich die Realisierungsverbindung gewählt.

„Die Realisierungsverbindung (Realization Relationship) sagt aus, dass ein Element eine kritische Rolle in der Erzeugung, Erreichung, Unterhaltung oder der Umsetzung eines abstrakteren Elements spielt.“

Das ist eine starke Aussage, denn sie besagt, dass die Anwendungsfunktion die Geschäftsfunktion realisiert, d. h. dass die Geschäftsfunktion ohne die Anwendungsfunktion nicht denkbar ist.

© BMI DV

Dieses Bild zeigt im Prinzip dasselbe, allerdings wird hier die „schwächere“ Unterstützungsverbindung zur Modellierung verwendet. Der Berichtsgenerator unterstützt alle bereits benannten Funktionen, und zusätzlich die Funktion Prozess-Controlling. Letztere wird ebenso vom Prozesssimulator unterstützt. Die Unterstützungsverbindung macht deutlich, dass die (Geschäfts-)Funktionen prinzipiell auch ohne diese Anwendungsfunktionen funktionieren würde, aber davon profitieren. Das ist insbesondere z. B. für ein Notfallmanagement eine wichtige Unterscheidung.

© BMI DV

Dieses Bild vereint wieder die bekannten Anwendungsfunktionen und fasst sie innerhalb der Anwendungskomponente „Prozessmanagementwerkzeug“ zusammen.

„Die Anwendungskomponente (Application Component) stellt eine Klammer um Applikationsfunktionalitäten dar, die zu einer Implementierungsstruktur zusammengefasst wird. Die Struktur soll modular sein und und für Ersetzbarkeit sorgen. Die Anwendungskomponente ist eine eigenständig Einheit und als solche unabhängig betreibbar, wiederverwendbar und ersetzbar. Eine Anwendungskomponente verrichtet eine oder mehrere Anwendungsfunktionen. Die Bereitstellung nach außen erfolgt über eine Anwendungsschnittstelle.“

Was im Bild nicht sichtbar wird, ist der Verbindungstyp: Es handelt sich um eine Realisierungsverbindung von der Anwendungskomponente zur Anwendungsfunktion.

Die Anwendungskomponente ist ebenfalls mit einer Realisierungsverbindung in einen Anwendungsdienst eingeschlossen, wobei die Richtung der Verbindung von der Komponente zum Dienst zeigt.

„Ein Anwendungsdienst (Application Service) stellt Funktionalität von Komponenten für deren Umgebung bereit. Die Funktionalität wird durch ein oder mehrere Anwendungsschnittstellen bereitgestellt. Ein Anwendungsdienst sollte Aktivitäten für seine Nutzer bereistellen, die einen Mehrwert beinhalten. Er hat einen Zweck, der den Nutzen für seine Umgebung erläutert.“

Zweimal wurde die Anwendungsschnittstelle bereits erwählt, d. h. offensichtlich fehlt etwas in dem Bild.

© BMI DV

Dieses Mal ist die Grafik vollständig. Auch eine Nutzeroberfläche ist eine Schnittstelle. Man hätte sie statt „Prozessmanagement-Nutzeroberfläche“ auch einfach „Prozessplattform“ oder „Prozessportal“ nennen können, aber seis drum.

„Eine Anwendungsschnittstelle (Application Interface) stellt einen Zugangspunkt dar, an dem Anwendungsdienste für den Nutzer zugänglich gemacht werden. Sie definiert, wie die Funktionalität von anderen Elementen erreicht werden kann. Sie kann Teil einer Anwendungskomponente sein, oder einem Anwendungsdienst zugewiesen werden.“

Dennoch enthält die Grafik noch einen Fehler. Sehen Sie ihn?

Der Pfeil der Unterstützungsverbindung geht vom Anwendungsdienst zur Rolle. Korrekterweise müsste er von der Anwendungsschnittstelle zur Rolle führen.

Auf der linken Seite ist der Dienst der niederschwelligen Prozessmodellierung etwas vereinfacht (z. B. Ohne Anwendungsschnittstelle) visualisiert. Er besteht aus zwei Komponenten, dem Web-Modeller oder der Digitalisierungs-App. Letztere benötigt als Material den Koffer mit Karten. Dieser Dienst unterstützt die Fachabteilungen darin, einen Informationsfluss an die Rolle Modellierer zu übertragen. Ich habe hier für die Fachabteilung einen Akteur statt einer gewählt, weil ich deutlich machen wollte, dass hier keine „feste Rolle“ Fachabteilung existiert, sondern diese aus unterschiedlichen Organisationseinheiten besteht.

Das Material ist an dieser Stelle eine Notlösung. Eigentlich wird es eher für Verbrauchsmaterial benutzt, und an der grünen Farbe ist zu erkennen, dass es nicht aus der Anwendungsarchitektur, sondern aus der Technologiearchitekturebene stammt. Manchmal kommt man eben auch mit ArchiMate an Grenzen.

Software-Architekturen

Bisher hat sich der Artikel auf die Aspekte beschränkt, die für die Zusammenarbeit zwischen Software-Architekten und Prozessmodellierern relevant sind. Damit lassen sich bereits jetzt Synergien zwischen den beiden Bereichen schaffen, die weit über das Computersymbol in BPMN hinausgehen. Insbesondere wird deutlich, warum Prozessmanagement und Architekturmanagement in einem einzigen System abgebildet werden, und dass die häufig zu beobachtende Isolation der Bereiche voneinander wenig sinnvoll ist.

Im nachfolgenden Teil tauchen wir nun etwas tiefer in die Welt der Software-Architektur ein. Für reine Proezssmodellierende mag das nicht mehr interessant sein, aber wer seinen Horizont erweitern möchte, kann gerne weiterlesen.

Die Ursprünge von ArchiMate

Ursprünglich wurde ArchiMate aus UML entwickelt, um eine Beschreibung von Software-Architekturen zu ermöglichen. Die anfängliche Ausdrucksfähigkeit beschränkte sich daher im Wesentlichen auf die folgenden Elemente:

© BMI DV

Leistungen (engl. Business Services) werden von Prozessen durch Rollen über Geschäftsschnittstellen (Kommunikationskanäle) erbracht. Die Realisierung erfolgt durch Anwendungs-Services, die wiederum aus Anwendungsfunktionen bestanden, die von Anwendungskomponenten über Anwendungsschnittstellen bereitgestellt werden. Die Anwendung läuft auf einem technischen Service, der von einer System-Software erbracht wird und auf einem Gerät läuft, welches eine Infrastrukturschnittstelle bereitstellt. Das Gerät ist mit einem Netzwerk verbunden, und in der Systemsoftware entstehen Datenartefakte.

Das klingt furchtbar abstrakt, und normalerweise wird nicht der gesamte Stapel abgebildet, sondern nur Teile davon. Den oberen (gelben) Teil haben wir uns ja in den vorangegangenen Schritten in einigen Facetten beleuchtet. Den grünen Infrastrukturbereich benötigt man eigentlich nur dann, wenn man ein Rechenzentrum betreibt. Der mittlere blaue Anwendungsteil verdient jedoch eine nähere Betrachtung. Starten wir mit einem extra komplexen Diagramm, das so in der Praxis wohl niemand modellieren wird.

© BMI DV

Bevor Sie zu viel Zeit mit dem Versuch unternehmen, die Grafik, zu verstehen: Mir war es erst einmal wichtig zu zeigen, dass ArchiMate es erlaubt, mehr als eine Verbindung zwischen zwei Elementen anzulegen, und dass auch die Richtung der Verbindungen unterschiedlich sein darf. Zum einen habe ich die bereits bekannte Flussverbindung verwendet, zum anderen die auslösende Verbindung. Doch eins nach dem Anderen:

© BMI DV

Diese Sicht vereinfacht die Grafik weiter oben: Zum einen sind einige Objekte entfernt worden, zum anderen die Flussverbindungen. Im Zentrum steht oben die (interne) Werkzeugschnittstelle. Diese wird von dem Produkt bereitgestellt, das die Maßnahme PMT ausgeschrieben hat. Um die Kommunikation mit dem Produkt zu standardisieren, wird mittels sogenannter Fassaden-Services eine Abstraktionsschicht zwischen die Werkzeugschnittstelle und die Außenwelt gelegt. Das wird durch die Import- und Export-Schnittstellen realisiert.

Diese werden von außen angesprochen und greifen nach innen auf die Werkzeugschnittstelle zu. Diese Richtung der Initiierung wird als Auslöser-Verbindung dargestellt und hier mit dem Wort „Zugriff“ beschrieben.

„Die Auslöser-Verbindung (Triggering Relationship) beschreibt eine zeitliche oder ursächliche Rangfolge von Aktivitäten in einem Prozess. Das Ausgangselement der Verbindung sollte abgeschlossen sein, bevor das Zielelement gestartet wird. Das muss nicht zwingend einen Auslöser bedeuten, ähnlich wie eine grüne Ampel zwar auslöst, dass die Autos über die Kreuzung fahren, diese aber nicht startet.“

Die Auslöseverbindung wird mittels eines Pfeils mit durchgezogener Linie und kleiner ausgefülltem Dreieck an der Spitze dargestellt.

In diesem Fall signalisiert die Verbindung in Zusammenhang mit der Benennung, dass der Zugriff immer von außen nach innen erfolgt, und niemals von innen nach außen. Das ist wichtig, um die Sicherheitsvorgaben für Anwendungen einzuhalten.

Der erste Auslöser für jeden Zugriff ist in diesem Fall eine Applikationsinteraktion.

„Eine Applikationsinteraktion (Application Interaction) beschreibt die gemeinsamen Aktionen, die von den Komponenten durchgeführt wird, die an einer Applikationskollaboration teilnehmen. Sie kann aber auch die von außen wahrnehmbare Aktion darstellen, die benötigt wird, um einen Anwendungs-Service zu realisieren.“

In der aktuellen Darstellung wird die zweite Variante verwendet: Die Applikationsinteraktionen, die durch eine von einer Lücke getrennte Halbkreise dargestellt werden, realisieren die Adapter-Services, die für verschiedene Zwecke realisiert werden.

© BMI DV

In der obigen Sicht werden dieselben Elemente gezeigt, dieses Mal werden aber nur die Flusspfeile dargestellt. Diese repräsentieren die Flussrichtung der Daten - bei einem Export von innen nach außen, bei einem Import von außen nach innen. Zudem werden an die Applikationsinteraktionen auch die Datenobjekte assoziiert, die dabei fließen.

„Ein Datenobjekt (Data Object) ist eine unabhängige Information mit einer klaren Bedeutung für die Geschäftsebene, nicht nur auf der Applikationsebene. Es kann mittels Interaktionen kommuniziert werden, und wird von Applikations-Services benutzt oder produziert.“

Das Datenobjekt sieht - abgesehen von der blauen Farbe - genauso aus wie ein Geschäftsobjekt und kann dieses spezialisieren. Somit lassen sich die eher abstrakten Geschäftsobjekte Ebene für Ebene genauer beschreiben.

Nach diesem langen Ausflug in die blaue Ebene der Applikationen, mit der gezeigt wird, wie die gemeinsame Darstellung von Ablauf- und Aufbauorganisation auch über Zuständigkeitsgrenzen hinweg geschehen kann, sollte nicht nur deutlich geworden sein, wie vielfältig ArchiMate verwendet werden kann, sondern auch, wie Geschäftsprozessmodellierung und Architektur miteinander interagieren und voneinander profitieren können.