Posts mit dem Label Definition werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Definition werden angezeigt. Alle Posts anzeigen

Donnerstag, 14. Mai 2015

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.

Donnerstag, 2. Januar 2014

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.

Montag, 16. Dezember 2013

Aktivitäten in BPMN 2.0

Eine Aktivität („Activity“ oder auch „Task“) stellt eine Arbeitseinheit eines Prozesses dar. Sie kann selbst Aktivitäten beinhalten; dann wird sie als Teilprozess („Sub-Process“) bezeichnet. Eine Aktivität wird immer als ein Rechteck mit abgerundeten Ecken dargestellt und kann in vielen Ausprägungen vorkommen. Aktivitäten werden durch gerichtete Kanten miteinander verbunden, die Sequenzflüsse („Sequence flows“) genannt werden.
Aktivitätsarten in der BPMN 2.0

Aktivitätstypen

Optional kann ein kleines Symbol in der linken oberen Ecke Auskunft über den Aktivitätstyp (z.B. „Human Task“ oder „Service Task“) geben. In der BPMN wird zwischen verschiedenen Aktivitätstypen unterschieden, die jeweils den Charakter einer Aktivität beschreiben.
Diese Aktivitätstypen sind mit Ausnahme des Typs „Manuell“ für die Abläufe innerhalb der Process Engine konzipiert. Eine „Benutzer“-Aktivität ist demzufolge als eine Aufgabe zu verstehen, welche die Process Engine an eine menschliche Rolle richtet.
Aktivitätstypen in der BPMN 2.0

Typmarkierung

Die Typmarkierung von Aktivitäten ermöglicht u.a. eine einfache Übersicht über Zugriffe auf andere technische Systeme bzw. deren Schnittstellen. Da ein Teilprozess mehrere (unterschiedliche) Aktivitäten repräsentiert, können Teilprozesse und Aufrufteilprozesse keine Typmarkierungen erhalten.

Freitag, 13. Dezember 2013

Was ist Business Process Management (BPM)?

Begriffsdefinition von Business Process Management

Die Meinungen über die exakte Definition von Geschäftsprozessmanagement, auch Business
Process Management (BPM) genannt, ist in fast jeder Fachlektüre eine andere. Nach der European Association of BPM (EABPM), lautet die Definition von BPM wie folgt:
"Business Process Management ist ein systematischer Ansatz, um sowohl automatisierte als auch nicht-automatisierte Prozesse zu erfassen, zu gestalten, auszuführen, zu dokumentieren, zu messen, zu überwachen und zu steuern und damit auch nachhaltig die mit der Unternehmensstrategie abgestimmten Ziele zu erreichen. BPM umfasst die bewusste und zunehmend IT-gestützte Bestimmung, Verbesserung, Innovation und Erhaltung von End-to-end-Prozessen." [1] 
BPM ist ein wichtiger Baustein in der Unternehmensplanung und -optimierung.

Aspekte von BPM

Mark Treat stellt in seinem Artikel über die Definition von BPM zusammenfassend fest, dass BPM gleichzeitig folgendes darstellt [2]:
  • ein Prozess zur Verwaltung der Geschäftsprozesse
  • eine Management-Disziplin
  • eine Technologie oder ein Set von Technologien
  • ein Framework zur schnellen Entwicklung von Anwendungen

Der Prozessbegriff

Dabei wird unter einem solchen Geschäftsprozess
"die inhaltlich abgeschlossene, zeitlich-sachologische Abfolge der Funktionen verstanden, die zur Bearbeitung eines betriebswirtschaftlichen Objekts notwendig sind." [3]
Prozesse werden mit Hilfe von BPM beschrieben, gesteuert, modelliert, überwacht und optimiert. Dies geschieht durch den Einsatz eines BPMS (Business Process Management System).
Ein Geschäftsprozess realisiert ein unternehmerisches Ziel.

Prozessautomatisierung per Software

Mit Hilfe eines solchen BPMS können manuelle Prozesse elimiert und das Routen von Anfragen zwischen Abteilungen und Anwendungen automatisiert werden. [4] Die Vorteile sind eine erhöhte Sichtbarkeit, identifizierte Flaschenhälse, Optimierung der Ressourcennutzung, Reduktion der Durchlaufzeiten und eine Redefinition von Rollen und Pflichten. [5]

BPM ist nicht gleich BPM

Die Abkürzung "BPM" steht gleichzeitig für "Business Process Management" als auch für "Business Process Modelling" (Geschäftsprozessmodellierung). Während Geschäftsprozessmanagement wie bereits beschrieben die Verwaltung und Verbesserung von Geschäftsprozessen umfasst, so beinhaltet die Geschäftsprozessmodellierung ausschließlich wissenschaftliche Repräsentationsformulismen zur Beschreibung von
"Praktiken oder Maßnahmen, ... um alle Aspekte eines Geschäftsprozesses darstellen oder beschreiben zu können. Dazu gehören der Ablauf, Kontroll- und Entscheidungspunkte, Trigger und Bedingungen für den Aufruf von Aktivitäten, der Kontext, in dem eine Aktivität stattfindet und die dazugehörigen Ressourcen." [6]
Ein Prozessmodell stellt eine grafische Repräsentation eines Prozesses dar.

Dieser Blog befasst sich sowohl mit der Modellierung als auch der Planung und Ausführung von Geschäftsprozessen.

Quellen:

[1] European Association of BPM: BPM Common Body of Knowledge
[2] Mark Treat: What is BPM anyway?, Dezember 2006.
[3] Tobias Rieke: Theoretische Grundlagen der Prozessmodellierung. Westfälische Wilhelms-Universität Münster, Dezember 2003.
[4] OMG: Business Process Model and Notation (BPMN), Januar 2011
[5] Stephen Tillemans: An Introduction to Business Process Management, University of Stellenbosch Business School, August 2010
[6] Nicolai Josuttis: SOA in der Praxis. dpunkt.verlag GmbH, 2009.