Strategie-Schicht in ArchiMate 3.0

Jetzt wird es strategisch: der Architecture Layer in ArchiMate 3.0 verbindet Geschäftsfähigkeiten mit Handlungen und Ressourcen.

Das Metamodell für die Strategieschicht in ArchiMate 3.0

Die Strategieschicht von ArchiMate 3.0 dient dazu, die Geschäftsfähigkeiten einer Organisation zu modellieren. Es wird dargestellt, wie diese verändert werden (müssen), um das gewünschte Geschäftsergebnis zu erzielen. [1, S. 63]

Im oben abgebildeten Metamodell befinden sich vier verschiedene Elemente: Handlung, Geschäftsfähigkeit, Ressource und Ergebnis.

Handlung (engl.: Course of Action)

• Eine Handlung kann strategisch oder taktisch sein.
• Eine Handlung kann eine andere Handlung initiieren, Informationen für diese bereit stellen oder dieser dienen.
• Eine Handlung beeinflusst ein Ergebnis (positiv oder negativ).
• Eine Handlung wird durch eine Geschäftsfähigkeit realisiert oder von einer solchen unterstützt.

Ergebnis (engl.: Outcome)

• Das Ergebnis wird von mindestens einer Handlung beeinflusst.
• Das Ergebnis stammt aus der Motivationsschicht und wird hier deshalb thematisch nur angerissen.

Geschäftsfähigkeit (engl.: Capability)

• Eine Geschäftsfähigkeit kann eine andere Geschäftsfähigkeit initiieren, Informationen für diese bereit stellen oder dieser dienen.
• Eine Geschäftsfähigkeit realisiert eine Handlung oder dient dieser.
• Eine Geschäftsfähigkeit kann einer aktiven Struktur zugeordnet sein.
• Eine Geschäftsfähigkeit wird von einer aktiven Struktur realisiert.
• Eine Geschäftsfähigkeit kann Ressourcen zugewiesen bekommen.

Ressource (engl.: Resource)

• Eine Ressource ist einer Geschäftsfähigkeit zugewiesen.

Da eine Ressource ein eher abstrakter Begriff ist, kann diese gedanklich in mehrere Gruppen unterteilt werden (siehe separates Metamodell).

Metamodell für Ressourcen in der Strategieschicht von ArchiMate 3.0

Sachanlagen (Tangible Assets)

• Physikalische Vermögenswerte wie z.B. ein Kraftwerk, Ausrüstung oder Grund
• Finanzielle Vermögenswerte wie z.B. Bargeld, Sicherheiten, Kreditfähigkeit

Immaterielle Werte (Intangible Assets)

• Technologien wie z.B. Patente, Urheberrechte, Handelsgeheimnisse
• Kultur
• Reputation wie z.B. Markenbild, Handelsbeziehungen

Menschliches Kapital (Human Assets)

• Fähigkeiten
• Wissen
• Kapazitäten

Praxisbeispiel

Praxisbeispiel für die strategische Schicht bei ArchiMate 3.0

In diesem Beispiel eines Online-Händlers gibt es die Handlungen Ausbleibende Zahlungen verfolgen und Betrugsfälle verhindern.
Die Handlung Ausbleibende Zahlungen verfolgen beeinflusst positiv (verstärkt) das Ergebnis Zahlungsausfälle reduziert. Die Handlung Betrugsfälle verhindern beeinflusst positiv das Ergebnis Betrugsfälle reduziert, welches widerum das Ergebnis Zahlungsausfälle reduziert positiv beeinflusst.

Die Geschäftsfähigkeiten Inkassobeauftragung, Mahnwesen und Lastschriftsperre dienen der Handlung Ausbleibende Zahlungen verfolgen, wobei der Geschäftsfähigkeit Inkassobeauftragung die Ressource Inkassobüro zugewiesen ist.
Die Geschäftsfähigkeiten Lastschriftsperre und Betrugsprävention dienen der Handlung Betrugsfälle verhindern. Die Geschäftsfähigkeit Lastschriftsperre dient auch der Geschäftsfähigkeit Mahnwesen.
Der Geschäftsfähigkeit Betrugsprävention ist die Ressource Scoring-Patent zugewiesen.

Quellen

[1] Andrew Josey et al.: ArchiMate 3.0 - A Pocket Guide. The Open Group. The Open Group Series; Van Haren Publishing, 2016.

Hier kommt ArchiMate 3.0

Seit Juni 2016 existiert die Version 3.0 des ArchiMate Standards der Open Group. Ich habe mir den Standard angeschaut und bin so sehr davon begeistert, dass ich es nicht für mich behalten möchte.

Kurzvorstellung

Bei ArchiMate handelt es sich um eine Modellierungssprache, die speziell zur Modellierung von Unternehmensarchitekturen entwickelt wurde.
Die Sprache erlaubt die Definition von Strukturen und Betriebsabläufen von Geschäftsprozessen, Organisationsstrukturen, Informationsflüssen, IT-Systemen und technischer Infrastuktur. [1]
Bemerkenswert ist hierbei vor allem, dass die verschiedenen Architektursichten auf die rein fachliche Welt, die Anwendungen und die Technologie darunter miteinander vereint werden können.
Mit entsprechenden Modellierungswerkzeugen kann so eine ganzheitliche Dokumentation eines Unternehmens erzeugt werden; vor allem dann, wenn die Geschäftsprozesselemente mit den ausmodellierten BPMN-Elementen verknüpft werden.

Konzept und Schichtenmodell

Um eine klare Sicht auf die unterschiedlichen Architekturaspekte eines Unternehmens zu erhalten, gibt es bei ArchiMate seit Beginn der Einführung ein übergreifendes Modell, welches die Elemente in Dimensionen nach Zweck und Art einteilt.

Das vollständige ArchiMate 3.0 Framework mit Erweiterungen [2]

Im abgebildeten Modell bilden die Spalten die Aspekte und die Zeilen die Schichten ab. Die dargestellten Farben werden tatsächlich von den meisten Modellierungswerkzeugen so übernommen. Das erleichtert den schnellen Einstieg und die Übersicht in neuen Modelle.

Aspekte klassifizieren das Objekt

Es wird zwischen drei Aspekten unterschieden: Aktive Strukturen, Verhalten und Passive Strukturen. Diese können mit dem Satzbau in der natürlichen Sprache verglichen werden.

Die aktiven Strukturen sind das Nomen (Mensch/System/Software), das Verhalten repräsentiert das Verb (dienen, realisieren, kapseln, verknüpft sein mit) und die passiven Strukturen das Objekt (Dokument, Datenbanktabelle). [3, S. 27]
Die Elemente (Struktur und Verhalten) sind in ArchiMate durch Beziehungen miteinander verknüpft. Eine Beziehung kann gerichtet (Darstellung mit Pfeil oder Diamant) oder ungerichtet (einfache Linie) sein. Sie gibt Auskunft darüber, in welchem Verhältnis die Elemente zueinander stehen.

Strukturen, Verhalten und Beziehungen in ArchiMate 3.0

Schichten klassifizieren das Umfeld/den Einsatzzweck

Motivationsschicht (Motivation). In dieser Schicht wird schichtenübergreifend modelliert, warum etwas getan wird. Diese Schicht kann auf jeder anderen Ebene referenziert und verknüpft werden.

Strategieschicht (Strategy). Die Strategieschicht legt dar, welche Geschäftsziele mit welchem Maßnahmen umgesetzt werden sollen.

Fachliche Schicht (Business). Die fachliche Schicht bildet ab, mit welchen Prozessen und Geschäftsfunktionalitäten die in der Strategieschicht definierten Maßnahmen umgesetzt werden.

Anwendungsschicht (Application). Die Anwendungsschicht unterstützt durch Softwarekomponenten, Schnittstellen und Services die fachliche Schicht bei der Umsetzung.

Technische Schicht (Technology). Die technische Schicht stellt die IT-Systeme und Gerätschaften bereit, mit denen den Anwendungen der tägliche Betrieb ermöglicht wird.

Physische Schicht (Physical). Hier werden die untergelagerten technischen Prozesse wie z.B. eine Produktionsstätte sowie die Verwendung von Materialien abgebildet.

Implementierung & Migration (Implementation and Migration). Mit dieser Schicht lässt sich abbilden, welche markanten Software-Entwicklungsziele es gibt und mit welchen Arbeitspaketen daran gearbeitet wird.

Im Rahmen der nächsten Beiträge werde ich die einzelnen Schichten sowie die darin enthaltenen Elemente genauer beschreiben und mit konkreten Beispielen besser greifbar machen.

Quellen:

[1] ArchiMate - Wikipedia, https://en.wikipedia.org/wiki/ArchiMate

[2] ArchiMate 3.0 Speficication - The Open Group. http://pubs.opengroup.org/architecture/archimate3-doc/chap03.html

[3] Andrew Josey et al.: ArchiMate 3.0 - A Pocket Guide. The Open Group. The Open Group Series; Van Haren Publishing, 2016.

BPM Architektur: Übersicht der Bestandteile

Wie alle Systeme hat auch ein BPM System eine Architektur inne. Diese variiert in ihrer Komplexität je nach Zweck und Integrationstiefe des BPM-Systems und muss dem jeweiligen Kontext angepasst werden.

Die in diesem Blog vorgestellte BPM Architektur stellt einen allgemeine Architekturansatz dar, der sich in vielen Aspekten an die Auffassung von Gartner[1] anlehnt. Jede der nachfolgend genannten Schichten (inklusiver ihrer Komponenten) wird in zukünftigen Beiträgen näher beschrieben.

Die Schichten einer allgemeinen BPM-Architektur.

Benutzerinteraktion

Die menschliche Integration in den Ablauf der automatisierten Prozesse mit Hilfe von Benutzerschnittstellen. Die Prozessteilnehmer müssen mit UI-Komponenten interagieren und Informationen einholen oder bereitstellen, die zur Lösung der Ihnen gestellten Aufgaben dienen und den Prozess vorantreiben.

Die Benutzerinteraktionskomponenten sind die Mechanismen, mit denen alle Prozess-Stakeholder - inklusive Prozessteilnehmer, Prozess-Owner, Prozessanalysten oder IT-Abteilung - interagieren.

Design-Time

Die Design-Time Komponenten unterstützen die Dokumentation und die Analyse der Geschäftsprozesse. Die Prozesstreibenden benötigen eine Infrastruktur, welche sie beim Design oder der Modellierung von Prozessen und dem Erschaffen von Prozessautomatisierungsmaßnahmen unterstützt. Dies umfasst u.a.:

■ Prozess-Design

■ Regeldefinition

■ Benutzerinteraktions-Design

■ Simulations-Design

■ KPI Definition

■ Solution Development

Plattform-Persistenz

Die Plattformpersistenzkomponenten werden benötigt, um die Zustände und aufgetretenen Ereignisse von Prozessschritten und davon abhängige Aktionen zu persistieren. Dies ermöglicht auch eine retrospektive Analyse der Prozessinstanzen und Governance-Maßnahmen.

Laufzeit (Runtime Hosting)

Die Laufzeitkomponente ermöglicht den Betrieb der Prozess-Engine und bietet zudem eine unterstützende Umgebung in Form von vermittelnden Systemen, Middleware und Monitoring-Möglichkeiten. 

Sicherheit

Die Sicherheitskomponenten unterstützen die Integration sicherheitsrelevanter Features wie z.B. SSO (Single-Sign-On) und Berechtigungssysteme.

Enterprise Service Bus

Der Enterprise Service Bus stellt im Rahmen einer SOA-Architektur den zentralen Zugriffspunkt für Dienste und Datenmodelle dar. Er ist protokollunabhängige Middleware für unterschiedliche

Plattformen und Technologien. Zudem übernimmt er wiederkehrende Aufgaben, wie z. B. das Wandeln von Protokollen, das Filtern und das Routen von Nachrichten.

Datenquellen/Enterprise Systeme

Die Datenquellen und Enterprise-Systeme bilden die unternehmensweite Datenbasis, in welcher die Datenobjekte persistiert werden.

Übersicht der Schichten und Komponenten eines BPM-Systems.

Quellen

[1] Gartner: "Business Process Management Infrastructure"; Richard Watson & Anne Thomas Manes; 2012.

Rollen im Business Process Management

Im Rahmen von BPM gibt es verschiedene Rollen, deren Aufgaben und Ziele individuell betrachtet werden müssen. Die eingesetzten und vorhandenen Rollen variieren je nach Unternehmensgröße, Führungsmethodik und Kultur.

Die nachfolgend vorgestellten Rollen müssen also nicht zwingend in jedem Unternehmen vollständig vertreten sein. Ebenso können auch je nach Komplexität des Unternehmens und der eingesetzten Prozesse noch andere Rollen beteiligt sein.

Beziehungen der Rollen im BPM-Umfeld

Chief Process Officer - Oberes Management

Der Chief Process Officer (CPO) oder auch „Leiter des Prozessmanagements“ steht hierarchisch gesehen an oberster Stelle und »etabliert eine nachhaltige Prozessorientierung im Unternehmen als zentrale[n] Erfolgsfaktor der wert- und kundengebundenen Ausrichtung.« [1] Er ist hauptsächlich für die Gestaltung des Change-Prozesses zuständig und kümmert sich im Allgemeinen um den Aufbau der prozessorientierten Organisation.

Der Chief Process Officer (CPO)

Process Owner - Strategische Prozessverantwortung & Controlling

Der Process Owner oder auch „Prozessverantwortliche/Prozesseigner“ befindet sich meist
im oberen Management und besitzt die strategische Verantwortung für einen Prozess.
Der Process Owner verwaltet das Budget und entscheidet über die Genehmigung von Optimierungsanträgen.
Er wählt die Kennzahlen zur Erfolgsmessung der Prozessleistung aus und kümmert sich
um den Aufbau und die Ausführung eines Prozesscontrollings.

Der Process Owner

Process Manager - Operative Verantwortung

Der Process Manager oder auch „Prozessmanager“ ist häufig im operativen Management tätig und trägt die operative Verantwortung des Prozesses. Er berichtet dem Process Owner und äußert diesem gegenüber Verbesserungswünsche.
Der Process Manager ist neben der Planung und Ausführung der operativen Prozessleistung auch mit der Koordination von mit seinem Prozess verbundenen Prozessen betraut.

Der Process Manager

Process Participant - Prozessdurchführung

Der Process Participant oder auch „Prozessbeteiligte“ ist derjenige, der im Prozess selbst arbeitet und durch den Einsatz der definierten Prozessmethoden und -dokumente die eigentliche Wertschöpfung (die Umsetzung der Kundenanforderungen) erbringt. Optimalerweise ist der Process Participant auch an der Mitgestaltung von Soll-Prozessen beteiligt.

Der Process Participant

Process Management Consultant - Analyse und Konzeption

Der Process Management Consultant oder auch „Prozessmanagement-Berater“ unterstützt den CPO bei der »Analyse und Konzeption von unternehmensweiten und prozessspezifischen Prozessmanagementmethoden« [BPM] und tritt beratend bei der allgemeinen BPM-Projektplanung in Aktion.

Process Controller - Führungsprozesse entwickeln

Der Process Controller ist Berater der Führungsrollen und unterstützt diese bei der Entwicklung der Führungsprozesse des Prozessmanagements und der effizienten Durchführung der Konzepte.
Er modelliert zudem die Führungsprozesse, nimmt eine erste grobe Prozessplanung vor und führt ein effizientes Prozessreporting ein.

Der Process Controller

Process Management IT-Coordinator - technische Architektur

Der PM IT-Coordinator ist für die technische Architektur und Ausführung der Prozesse verantwortlich. Er wendet die Prinzipien von Service Oriented Architecture (SOA)3 und BPM an und koordiniert die IT-Landschaft mit den Anforderungen aus den Fachabteilungen.

Der PM IT-Controller

Process Engineer - technische Entwicklung

Der Process Engineer oder auch „Prozessentwickler“ ist für die technische Umsetzung der Prozesse verantwortlich, die meist mit Hilfe einer Workflow-Engine erfolgt.

Der Process Engineer

Process Analyst - Schnittstelle zwischen Fachbereich und IT

Der Process Analyst oder auch „Prozessanalyst“ bildet die zentrale Schnittstelle zwischen der fachlichen und der technischen Abteilung. Seine Aufgabe besteht in dem Erreichen eines gemeinsamen Verständnisses für das Geschäfts- und Prozesswesen.
»Innerhalb des Unternehmens ist der Process Analyst meistens entweder in einem Kompetenzbereich
für BPM angesiedelt, z. B. der Betriebsorganisation, oder er gehört zur IT-Abteilung.« [2] Dennoch liegt sein Fokus klar auf der Analyse und er ist eher selten an der Implementierung beteiligt.
Er arbeitet eng mit dem PM IT-Coordinator zusammen, um die Anforderungen aus den verschiedenen Fachabteilungen und deren Hierarchien bewerten und einordnen zu können.
Gerade in etwas kleineren mittelständischen Unternehmen übernimmt der Business Analyst oft zusätzlich die beratenden Rollen „PM Consultant“ und „Process Controller“ ein.

Der Process Analyst

Quellen

[1] BPM-Akademie GmbH: Rollen im Prozessmanagement. http://www.bpm-akademie.de/akademie/opencms/de/know_how/rollen_im_prozessmanagement
[2]

Ereignisse in BPMN 2.0

Grundlagen der Ereignisse

Ereignisse („Events“) können eintreten oder ausgelöst werden und werden durch einen Kreis dargestellt. Das Auslösen kann aus dem Prozess heraus oder durch eine Nachricht von außen geschehen.
Es gibt Start-, Zwischen- („Intermediate-“) und Endereignisse. Ereignisse können auch an Aktivitäten angeheftet sein (so genannte „Boundary Events“) und so u.a. auftretende Sonderfälle abdecken.
Ereignisse können beim Eintreten den umgebenden Prozess unterbrechen (durchgezogene Umrandung) oder nicht unterbrechen (gestrichelte Umrandung). Eine Übersicht aller Ereignisarten kann der nachfolgenden Abbildung entnommen werden.

Ereignisarten in BPMN 2.0

Einsatz von Ereignissen

Ein Ereignis leitet einen Prozess ein und anderes beendet diesen. Dazwischen kann der Prozess auf definierte Ereignisse warten oder diese erzeugen.
Da Ereignisse keine Aktivitäten darstellen, dürfen sie keine komplexen Abläufe beinhalten. Auch der Name sollte kein aktives Verb, sondern eine Beschreibung des Zustands widerspiegeln (z.B. "Party gefeiert" statt "Party beenden").
Im nachfolgenden Beispiel beginnt der Prozess dann, wenn es einen Grund zum Feiern gibt. Nachdem die Einladungen verschickt worden sind, wartet der Prozess so lange, bis der geplante Tag eintritt. Nachdem die Party gefeiert wurde, hat dieser Prozess den Status "Party gefeiert".

Einfacher Gebrauch von Ereignissen

Ereignis-Gateways

Es kann vorkommen, dass eines von mehreren möglichen Ereignissen den weiteren verlauf des Prozesses bestimmt. In diesem Zusammenhang werden Ereignis-Gateways (engl.: "Event-Gateways") wichtig (eine Übersicht der Gateways gibt in diesem Beitrag).
Im nachfolgenden Beispiel wartet der Prozess darauf, dass entweder eine Antwort erhalten wurde oder 12 Tage verstrichen sind.

Einsatz des exklusiven Ereignis-Gateways

Angeheftete Ereignisse

Es kann sein, dass Aktivitäten durch eintretende Ereignisse beeinflusst werden oder dass diese Aktivitäten selbst während der Durchführung Ereignisse eintreten lassen. Daher können Ereignisse an Aktivitäten oder aufgeklappte Teilprozesse angeheftet werden.
Ob ein Ereignis die Tätigkeit am angehefteten Objekt unterbricht kann an der Umrandung des Ereignisses abgelesen werden: ist die Linie durchgezogen, dann unterbricht das Ereignis den internen Fluss. Ist die Linie gestrichelt, dann wird das Ereignis parallel zum internen Fluss bearbeitet.
Im nachfolgenden Beispiel stehen die Aufräumarbeiten der zuvor gefeierten Party an. Während die Aktivität "Wohnung aufräumen" ausgeführt wird, kann es passieren, dass der Akteur feststellt, dass er wegen eines Aufräum-Solos nicht die notwendige Motivation aufbringt. Die Aktivität wird also unterbrochen und der Prozess wird an einer anderen Stelle fortgesetzt. In diesem Fall endet der Prozess in einem Abbruch-Ereignis, was den hier dargestellten Teilprozess beendet.
Alternativ dazu kann es sein, dass während der Ausführung der Aktivität eine nicht-unterbrechende Nachricht von einem Freund erhalten wird. Der interne Fluss der Aktivität wird nicht unterbrochen. Egal ob der Freund angerufen hat oder nicht: wenn die Aktivität "Wohnung aufräumen" abgeschlossen wurde, wird anschließend noch einmal eine Putzparty gefeiert.

Einsatz von angehefteten Ereignissen an Tasks

Gateways in BPMN 2.0

In einem Prozess müssen häufig Entscheidungen getroffen werden. Wenn diese einfacher Natur sind (und nicht etwa einem komplexen Regelwerk zugrunde liegen), so können sie mit Hilfe von Gateways ausgedrückt werden.
In BPMN 2.0 werden alle Verzweigungen oder Zusammenführungen als Gateways bezeichnet und durch eine kleine Raute dargestellt. Ein Gateway kann z.B. eine bedingte oder eine parallele Ausführung eines Prozesspfades zur Folge haben.

Gatewayarten in BPMN 2.0

Verwendung von Gateways

Gateways sind keine Aktivitäten
Wichtig ist, dass ein Gateway keine Tätigkeit ausführt. Ein Gateway verändert nicht den Zustand eines Objekts oder beinhaltet eine prüfende Aktivität. Gateways arbeiten nur mit bereits vorhandenen Daten. Für Entscheidungspunkte werden XOR-Gateways verwendet; die Synchronisierung kann direkt an einer Aktivität erfolgen.

Antipattern: Gateways dürfen nicht als Aktivität fungieren.

Korrekt: Die Aktivität zur Entscheidungsfindung ist vorgeschaltet, das Gateway wertet nur aus.

Standardpfad
Wenn angedeutet werden soll, dass einer der Pfade dem Standardfall entspricht, so kann dies mit einem kleinen Querstrich am Sequenzfluss kenntlich gemacht werden.

Standardverwendung von Gateways

Antipattern: Inkonsistenter Gebrauch von Gateways

In der BPMN können Bedingungen auch mit bedingten Sequenzflüssen realisiert werden. Dabei werden die Sequenzflüsse mit einer leeren Raute und einer Bedingung versehen. Wie in der nachfolgenden Abbildung dargestellt, kann so eine etwas kompaktere Darstellung bewirkt werden.

Ersetzung eines Gateways durch bedingte Sequenzflüsse

Da nun aber in einer Aktivität mehrere Sequenzflüsse ein- und ausgehen können, wird die Lesbarkeit beeinträchtigt und somit die Interpretierbarkeit erschwert.

Antipattern: Schlechte Synchronisierung mit Teilprozessen

Wenn Teilprozesse mehrere Endereignisse besitzen, kann es zu Synchronisierungsproblemen mit nachgelagerten Gateways kommen, wenn diese eine falsche Fragestellung aufweisen.
In der nachfolgenden Abbildung ist dargestellt, wie ein XOR-Gateway mit einer Entscheidungsfrage das Ergebnis eines Teilprozesses abfragt.

Antipattern: Entscheidungsfragen nach einem Teilprozess erhöhen das Risiko von Synchronisierungsproblemen.

Sollte der Teilprozess später mehr als nur zwei Endereignisse definiert haben, so kann es bei der Ausführung zu einer Fehlermeldung kommen, wenn das nicht abgefangene Endereignis eintritt.
Wenn das Gateway nicht mit einer Entscheidungsfrage versehen wird, lassen sich relativ unkompliziert weitere, voneinander unabhängige Zustände ergänzen und das Matching von Endereignis und Gateway fällt deutlich leichter.

Korrekt: Das Gateway besitzt keine Entscheidungsfrage und kann mehrere Endereignisse verarbeiten.

Bei vielen zu differenzierenden Ereignissen kann die Verwendung von Boundary Events hilfreich sein.

Lose Kopplung durch SOA

Ein wesentlicher Bestandteil des Software-Paradigmas SOA - "Service Oriented Architecture" ist die lose Kopplung. Diese dient der Reduzierung von Abhängigkeiten zwischen Systemen.

Ziel der losen Kopplung

Das Ziel von loser Kopplung ist die Erreichung einer größtmöglichen Unabhängigkeit, sodass im Falle eines Systemausfalls oder einer signifikanten Änderung nicht alle weiteren Systeme negativ davon betroffen werden.

Eine lose Kopplung reduziert Abhängigkeiten zwischen Systemen.

Begriff der Kopplung

Der Begriff der "Kopplung" stammt aus dem Software-Engineering und entspringt dem Gedanken eines modularen Software-Designs. Ein modulares Design hat das Ziel, eine maximal hohe Kohäsion bei minimaler Kopplung zu erreichen. Alle Informationen sollen demnach in modularer Programmierung verborgen werden.

Wann ist etwas lose gekoppelt?

Stellen wir uns dazu vor, dass A eine Komponente mit einer Abhängigkeit zu einer Komponente B sei. A ist nach [1] dann mit B lose gekoppelt, wenn die folgenden Aussagen zutreffen:

Wissen

• A hat minimale Kenntnis von B. Das kann bedeuten, dass A und B nicht denselben Datenspeicher verwenden. Weiterhin kennt A nicht die Technologie der Implementierung (z.B. Programmiersprache, Datenbanksystem usw.) von B.

Abhängigkeit von Verfügbarkeit

• A kann auch dann arbeiten, wenn B (oder die Verbindung zu B) temporär nicht verfügbar ist. Während B im Normallfall synchron aufgerufen wird, kann es im Falle einer Störung als "ausstehend" markiert werden. B wird nun asynchron aufgerufen, sodass die erforderlichen Tätigkeiten durchgeführt werden, sobald B wieder verfügbar ist.

Vertrauen

• B vertraut nicht darauf, dass A alle Vorbedingungen erfüllt. B prüft alle Eingangsdaten von A auf Fehler.
• A vertraut nicht darauf, dass B alle Nachbedingungen erfüllt. A prüft alle Ergebnisdaten von B auf Fehler.

Regeln für eine lose Kopplung

• Lose gekoppelte Systeme benutzen keine gemeinsame Datenbank.
• Lose gekoppelte Systeme kommunizieren asynchron (aus Geschäftssicht).
• Lose gekoppelte Systeme laufen nicht in einem gemeinsamen transaktionalen Kontext.

Getrenntes Transaktions-Management

Getrennte Datenbanken

Asynchrone Kommunikation

Kompensationen

Die letzte Regel dürfte einige Fragen aufwerfen: Wie kann die Datenkonsistenz gewährleistet werden, wenn es keinen gemeinsamen Transaktionskontext gibt?
Die Antwort lautet: Durch Kompensationen. Es muss für jeden Vorgang ein Kompensationsvorgang vorhanden sein. Wenn ein Abbruch stattfindet, werden die zugehörigen Kompensationsvorgänge aufgerufen. Dabei ist ein solcher Abbruch kein einfaches technisches Rollback, sondern ein Geschäftsvorgang; bei diesem können zum Beispiel Gebühren für eine Geschäftsstornierung auftreten.

Tentative Operations

Wenn damit zu rechnen ist, dass es häufig zu einem Abbruch kommt, werden "tentative operations" (ausstehende Vorgänge) eingesetzt: im Falle einer Reisebuchung wird nicht eine verbindliche Buchung, sondern eine Reservierung implementiert. Die eigentliche Buchung wird erst dann gültig, wenn die Bestätigung erfolgt ist.

Umsetzung und technische Aspekte

Realisiert wird die lose Kopplung u.a. dadurch, dass Dienste beim Benutzer nicht fest mit einer (IP-)Adresse hinterlegt werden. Stattdessen veröffentlicht der Dienstanbieter seinen Dienst in einem Dienstverzeichnis. Bei der Verwendung des Dienstes wird dieser nur über seinen Domänennamen aufgerufen.
Weitere technische Aspekte von loser Kopplung sind u.a. eine Unabhängigkeit der Benutzeroberflächen- und Prozesssteuerung, ein asynchroner Kommunikationsstil und eine ereignisgesteuerte Prozesssteuerung. [2]

Nachteile

Leider ist die Berücksichtigung von loser Kopplung (die übrigens nur schwerlich mit Metriken gemessen werden kann) in einer Architektur auch mit einer größeren Komplexität verbunden, da auf diese Weise umgesetzte Systeme schwerer zu entwerfen, zu realisieren und zu pflegen sind. [3]
Dem entgegen zu setzen ist der Umstand, dass ohne eine SOA und lose Kopplung die Komplexität der IT-Landschaft ein viel größeres Ausmaß annehmen würde und somit langfristig betrachtet gar nicht mehr beherrschbar wäre.

Glossar

Kohäsion = Die Fähigkeit einer Programmeinheit, eine logische Aufgabe oder Einheit abzubilden. In einem System mit starker Kohäsion ist jede Programmeinheit (eine Methode, eine Klasse oder ein Modul) verantwortlich für genau eine wohldefinierte Aufgabe oder Einheit. [4]

Quellen

[1] Gregor Engels, Andreas Hess, Bernhard Humm, Oliver Juwig, Marc Lohmann, Jan-Peter Richter, Markus Voß, Johannes Willkomm: Quasar Enterprise – Anwendungslandschaften serviceorientiert gestalten. dpunkt.verlag GmbH, 2008.

[2] Hajo Normann, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg: Lose Kopplung - Warum das Loslassen verbindet. In: SOA Spezial Vol. 1, 2009.
[3] Nicolai Josuttis: SOA in der Praxis. dpunkt.verlag GmbH, 2009.
[4]  Wikipedia: Kohäsion (Informatik) — Wikipedia, Die freie Enzyklopädie. Version: 1 2013.

Vision von SOA und BPM

Um im Zeitalter der Globalisierung als Unternehmen auf dem Weltmarkt bestehen zu können, wird eine solide Infrastruktur benötigt, die es ermöglicht, die global angebotenen Dienste in Anspruch zu nehmen oder die eigenen Dienstleistungen an den Markt zu bringen.
Während die Globalisierung auf der einen Seite die Beschreitung neuer Märkte und Akquise neuer Kundenfelder ermöglicht, erhöht sich gleichzeitig massiv der Konkurrenzdruck. Um nicht in der grauen Masse zu verschwinden, sind Marktanteile ein wichtiges Gut. Deswegen liefern sich die Unternehmen regelrechte Wettrennen, wenn es darum geht, einem Produkt ein neues Feature zu verpassen. Wer zu spät einsteigt, riskiert Teile des Kundenstamms einzubüßen.

Die Globalisierung erfordert eine schnelle Reaktionsfähigkeit am Markt.

Daher fordern Manager neben einer möglichst effizienten Produktion vor allem schnellere Wege von der Idee zur Umsetzung (engl. „Time To Market“). Das ist aber nur möglich, wenn die Abteilungen eines Unternehmens enger zusammen arbeiten und Geschäftsprozesse nicht durch eine zähe Eigenbürokratie gebremst werden.

Verteilte Systeme

Um diese engere Verzahnung der Abteilungen ermöglichen zu können, werden verteilte Systeme geschaffen, die miteinander kommunizieren können und eine Wertschöpfungskette ohne Medienbruch ermöglichen. Um die Kommunikation kontrolliert ablaufen lassen und das Routing elektronischer Dokumente steuern zu können werden zur Abbildung eines Geschäftsprozesses die Geschäftsregeln und Entscheidungspfade in das neue System implementiert.

Vorteile der Prozessvirtualisierung

Dabei soll die Rechnerunterstützung

„die Minimierung der für die Wertschöpfung unproduktiven Transport- und Liegezeiten ermöglichen und den Beteiligten Transparenz über den aktuellen Zustand und die Arbeitsfortschritte verschaffen. Durch die Vorgabe von festen Regeln kann der Ablauf von wiederkehrenden, stark strukturierten Prozessen in einer vom Betrieb gewünschten Art und Weise erzwungen werden.“ [1]

Mit Hilfe elektronischer Geschäftsregeln fällt die Vereinheitlichung und Anpassung von Prozessen leichter.

Qualitätssicherung und Image 

Doch die so standardisierten Geschäftsprozesse spielen nicht nur im Bereich der Qualitätssicherung
eine wichtige Rolle – auch das Image des Unternehmens soll vereinheitlicht werden. Bei einem Stamm von 500 Mitarbeitern und mehr ist es aber sehr aufwändig, diese alle auf einem aktuellen Wissensstand zu halten. So ist es für Sachbearbeiter ohne eine strikte Unterstützung der IT nahezu unmöglich, die jeweils neuesten Geschäftsregeln und Kommunikationspfade zu kennen und sich dem Kunden gegenüber immer gleich
(fair) zu verhalten.

Prozesstransparenz 

Damit ein Unternehmen erfolgreich gesteuert werden kann, muss das Management seinen „Kurs“ kennen und zügig über auftretende Probleme oder Chancen informiert werden.
Wurden erst einmal alle Geschäftsprozesse virtualisiert, so können mit Hilfe von an entscheidenden Knotenpunkten gemessenen KPIs* und dem Einsatz von BAM* auftretende Probleme schneller identifiziert und entsprechende Gegenmaßnahmen eingeleitet werden.

Gerade in den Zeiten einer Weltwirtschaftskrise muss man darauf gefasst sein, dass selbst langjährige Handelspartnerbeziehungen aufgegeben werden müssen. Damit das Unternehmen keine unnötigen Verzögerungen erfährt oder gar einen Produktionsstillstand erleidet, müssen die Geschäftsprozesse sich leicht an neue Handelspartner anpassen können.

Altsystem müssen ersetzt oder so erweitert werden, dass sie moderne Kommunikationsschnittstellen bedienen können.

Erwartungen

Mit Hilfe von SOA und BPM hofft die Industrie, Unternehmensstrukturen erschaffen zu können, die sich mit minimalem Zeit- und Ressourcenverbrauch auf neue Geschäftsprozesse einstellen können, um sich somit einen entscheidenden Vorteil gegenüber der Konkurrenz zu verschaffen. Mitunter gibt es auch die Wunschvorstellung, dass neue Geschäftsprozesse einfach vom Management selbst zusammengeklickt werden können, ohne dass dabei die Einbindung der IT-Abteilung notwendig ist.

Glossar

KPI = Key Performance Indicator – Kennzahl für den direkten Unternehmenserfolg.
BAM = Business Activity Monitoring – Verfahren zur direkten Überwachung des Geschäftswesens
ohne die Zeitverzögerung durch ein DataWareHouse.

Quellen

[1] Hansen, Hans R. ; Neumann, Gustaf: Wirtschaftsinformatik 1 - Grundlagen und Anwendungen. F. X. Bea, B. Friedl, M. Schweitzer, 2005.

Historische Entwicklung von BPM

Auf der Suche nach Möglichkeiten, sich das Leben bequemer zu gestalten und mit immer weniger Arbeitsaufwand größere Erträge zu erzielen, begann der Mensch, Werkzeuge zur Erleichterung von monotonen Arbeiten zu entwickeln. Bereits im Altertum verwendete der Mensch Windräder, um Maschinen anzutreiben. Damit diese Windräder mit der maximal möglichen Effizienz funktionierten, wurde 1745 ein zusätzliches Getriebe entwickelt, welches das Windrad veranlasste, sich eigenständig in den Wind zu drehen:
der Automatismus war geboren. [1]

Windmühlen waren die ersten vollautomatischen Maschinen.

„Wenn jedes Werkzeug auf Geheiß, oder auch vorausahnend, das ihm zukommende Werk verrichten könnte, . . . so bedürfe es weder für den Werkmeister der Gehilfen noch für die Herren der Sklaven.“

Aristoteles

Bald darauf folgten vor allem im Kontext der industriellen Revolution viele Erfindungen, die einen menschlichen oder tierischen Krafteinsatz mehr und mehr überflüssig machten. Der Einzug der Elektrizität ermöglichte die verteilte Produktion per Fließbandfertigung und die Entwicklung von integrierten Schaltkreisen (sog. „ICs – Integrated Circuits“) wurde eingesetzt, um in den Werkzeugen erstmals Logik zu implementieren.

Die Automatisierung macht den Krafteinsatz des Menschen oft überflüssig.

Taylorismus

Während technische Innovationen immer effizientere Verfahren zur Erhöhung der Produktivität ermöglichten, fand sich die damalige Gesellschaft mit neuen Problemen konfrontiert. Der Taylorismus – der erfolgreiche Versuch, die Produktion vollständig zu rationalisieren und Menschen als Maschinen zu betrachten – führte zu allgemeiner Unzufriedenheit, zunehmender Arbeitslosigkeit, Arbeitsentfremdung und nicht zuletzt auch vermehrt zu physischen und psychischen Gesundheitsstörungen der Arbeiter. [2]

Wandel der Arbeit

Durch den Einsatz der Computertechnologie und der Software-Entwicklung wurde das Verwaltungswesen grundlegend verändert und die Arbeit der Menschen verlagerte sich zunehmend auf Tätigkeiten wie Administration, Planung, Kontrolle und Dienstleistungen. Die Globalisierung erforderte ein koordiniertes Zusammenarbeiten weit voneinander entfernter Filialen und Geschäftspartner. Die zunehmende Virtualisierung der Arbeit brachte viele Systeme zur Verwaltung von Kunden, Verträgen, Lieferketten, usw. hervor.

Der Wandel der Arbeit macht den Menschen zum Verwalter der Dinge.

Insellösungen 

Da diese Anwendungen „in sich abgeschlossen“ sind und für jeweils eine bestimmte Abteilung entwickelt wurden (sog. „Insellösungen“), ist es aufwändig, einen Geschäftsprozess vollständig durch alle Ebenen im Unternehmen zu verfolgen und zu bewerten. Eine Konsequenz dieser Insellösungen waren auch Medienbrüche (z.B. das Ausdrucken von Daten und die erneute Eingabe in das Folgesystem) und damit einher gehende Fehlerraten und Verzögerungen im Business-Zyklus.

Verteilte Architekturen

Bald entstanden Software-Architekturen und Technologien wie z.B. CORBA*, die ein Zusammenarbeiten von heterogenen Systemen ermöglichten. Schließlich ging auch der Architekturtyp „SOA“ – die dienstorientierte Architektur – aus dieser Entwicklung hervor und ermöglichte so die Nutzung der vorher in den Systemen verschlossenen Funktionalitäten als im gesamten Unternehmen angebotene Dienste.

Wie bei einem Speichensystem hält eine SOA die Dienste an einer zentralen Stelle verfügbar.

Diese Dienste können im Rahmen des Geschäftsprozessmanagements (BPM) mit Hilfe von sog. Workflow-Management-Systemen miteinander so verknüpft werden, dass selbst die komplexesten Prozesse, Entscheidungspfade und Geschäftsregeln abgebildet werden können. Der Mitarbeiter wird somit zugunsten der Produktivität zunehmend nicht nur von körperlicher sondern auch von geistiger Arbeit befreit.

Glossar

CORBA = Common Object Request Broker Architecture – eine Middleware mit plattformübergreifenden

Protokollen und Diensten zur vereinfachten Erstellung verteilter Anwendungen in heterogenen

Umgebungen.
SOA = Service-Oriented-Architectue. Ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird.

Quellen:

[1]  Wikipedia: Automatisierung — Wikipedia, Die freie Enzyklopädie. Version: 11 2009.
[2]  Wikipedia: Taylorismus — Wikipedia, Die freie Enzyklopädie. Version: 11 2009.

Datenobjekte in BPMN 2.0

Auch wenn die BPMN keine Datenmodellierung abdeckt, so können dennoch Datenobjekte („Data Objects“) oder Artefakte in die Geschäftsprozessmodelle aufgenommen werden. Datenobjekte werden durch ein Dokumentsymbol gekennzeichnet.

Datenobjekte in der BPMN 2.0

Datenmodell und Artefakte

In einem Prozess gibt es meist einen definierten Input und/oder Output. Dieser kann bspw. in Form eines Dokuments, eines Datensatzes oder einer E-Mail vorliegen und ist oft so wichtig, dass er im Prozessmodell nicht fehlen darf.

Fehlende Datenmodellierung

Die BPMN erlaubt zwar die Platzierung von Datenobjekten, aber sie enthält keine Möglichkeiten zur technischen Definition. Dafür gibt es bereits sehr gute Sprachen wie z.B. die UML, welche u. a. mit Klassendiagrammen eine Datenstruktur beschreiben kann.
In der nachfolgenden Abbildung werden exemplarisch ein Data Store (vergleichbar mit einer global verfügbaren Datenbank) und diverse Data Objects (nur verfügbar innerhalb der jeweiligen Prozessinstanz) eingesetzt.

Verwendung von Datenobjekten