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.

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.

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

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.

BPMN - Eine Notation revolutioniert Fachmodelle

BPMN steht für "Business Process Model and Notation" und ist ein relativ neuer Standard zur Modellierung von Geschäftsprozessen und Prozessumgebungen. Die BPMN wird von der Object Management Group (OMG) vorangetrieben und stellt mittlerweile eine Grundvoraussetzung für das Geschäftsprozessmanagement dar. [1]

Die BPMN wurde speziell so entwickelt, dass sie einfach zu verstehen ist und dennoch komplexe Geschäftsprozesse abbilden kann. Der Informationsfluss eines Geschäftsprozesses wird durch eine Folge von Aktivitäten und ausgetauschten Nachrichten zwischen verschiedenen Rollen modelliert. [1][2]

Beispiel eines BPMN-Kollaborationsdiagramms.

Ziel von BPMN

Die OMG definiert, dass das primäre Ziel von BPMN darin liegt,

"eine Notation zu schaffen, die sehr einfach zu verstehen ist: sowohl von der Fachabteilung, vom Business-Analysten (der die ersten Entwürfe des Prozesses erstellt), vom technischen Entwickler (der für die Technologieimplementierung zur Abarbeitung des Prozesses verantwortlich ist, als auch für das Management, welches die Prozesse verwaltet und beobachtet.
Somit stellt die BPMN eine standardisierte Brücke für die Lücke zwischen dem Geschäftsprozessdesign und der Prozessimplementierung dar.
Ein weiteres, nicht weniger wichtiges Ziel besteht darin, sicherzustellen, dass XML-Sprachen, die für die Ausführung von Geschäftsprozessen gedacht sind (wie bspw. WS-BPEL), mit einer geschäftsorientierten Notation visualisiert werden können." [3]

BPMN als Brücke zwischen Design und Implementierung

Abgrenzung

BPMN ist nicht zur Modellierung von organisatorischen Strukturen, funktionalen Dekompositionen, Statusübergängen oder Datenmodellen geeignet. [3] Weiterhin handelt es sich nicht um eine Repräsentation im Sinne eines Datenflussdiagramms, obwohl es auch Teile des Datenflusses zeigt und Datenartefakte mit Aktivitäten assoziiert. [4]

Etwas Geschichtsunterricht: Die Historie von BPMN

Die Entwicklung der BPMN begann 2001 als Projekt von Stephen White unter dem Namen "Business Process Modeling Notation" und wurde im Mai 2004 im Namen der Business Process Management Initiative (BPMI) als Version 1.0 veröffentlicht.
Im Jahr 2005 ging die BPMI in der OMG auf, welche im Januar 2008 die Version 1.1 veröffentlichte. Die Änderung der Version 1.1 führte hauptsächlich "catching" und "throwing" Events ein. Im Januar wurde die Version 1.2 veröffentlicht, die vorwiegend aus kleineren Korrekturen bestand. [4]

Die im Januar 2011 veröffentlichte Version 2.0 enthält viele Neuerungen: neue Diagramme, Diagrammelemente und Prozessarten. Dabei wurde auch der Name von BPMN auf "Business Process Model and Notation" geändert, um auf das neue "formale Metamodell" hinzuweisen. [5]

Versionshistorie von BPMN 2.0

Wichtige Neuerungen in der Version 2.0

Die BPMN wurde bei der Version 2.0 vor allem in Hinblick auf Austauschbarkeit, Ausführbarkeit und Erweiterbarkeit optimiert. Vereinfacht beschrieben, beinhalten die Neuerungen folgendes:

Austauschbarkeit: Es wurde das offizielle Format "Business Process Definition Metamodel (BPDM) festgelegt, mit welchem der Transfer von BPMN-Modellen zwischen verschiedenen Modellierungswerkzeugen mit Gewährleistung einer gleichbleibenden Semantik möglich ist. [4]

Ausführbarkeit: BPMN entwickelt sich dahingehend, dass es direkt ausführbar ist und somit keine zusätzlichen Transformationen in Prozessausführungssprachen wie BPEL oder XPDL notwendig sind. [6]

Erweiterbarkeit: Mit Hilfe eines Erweiterungsmechanismus zur Serialisierung von BPMN und XML-Schemata können sowohl das Prozessmodell als auch die grafische Repräsentation erweitert werden. Somit können auch menschliche Prozesse besser definiert werden. [3]

Verschiedene Sichten: Die Darstellung und der Austausch von verschiedenen Perspektiven desselben Modells, sodass ein Nutzer sich auf sein spezielles Aufgabengebiet konzentrieren kann. [3]

Neue Diagramme: Mit den neuen Diagrammtypen können Orchestrierungen und Choreographien einzeln oder in andere Diagrammtypen integriert dargestellt werden. [4]

Quellen

[1] Martin Owen und Jog Raj: BPMN and Business Process Management. Popkin Software, September 2003
[2] Object Management Group: Business Process Model and Notation
[3] Object Management Group: Business Process Model and Notation 2.0 (BPMN), Januar 2011
[4] Wikipedia: Business Process Model and Notation — Wikipedia, The Free Encyclopedia, März 2012
[5] Jakob Freund und Bernd Rücker: Praxishandbuch BPMN 2.0. Carl Hanser Verlag München Wien, 3. Auflage Auflage, März 2012.
[6] Sebastian Klein und Erik Hagen: Adopting BPMN with ARIS. Whitepaper, Software AG, Oktober 2010.