In den letzten Jahren ist ein Trend hin zu offenen BPM-Frameworks wie Camunda BPM zu beobachten, die einen sogenannten „Developer-Friendly“-Ansatz verfolgen. Vorteile entstehen vor allem daraus, auf weitverbreitete Standards und Programmiersprachen statt auf proprietäre Lösungen zu setzen, um die Hürde von technischen Anpassungen durch Softwareentwickler so gering wie möglich zu halten.
Dennoch unterscheiden sich Prozessautomatisierungsprojekte mit Camunda BPM von gewöhnlichen Softwareentwicklungsprojekten in wesentlichen Punkten:
- Das BPMN 2.0 Prozessmodell ist Teil des Quellcodes und unterliegt somit ähnlich hohen Qualitätsanforderungen wie herkömmlicher Quellcode, es gibt aber wenig Werkzeug-Unterstützung die auf beide Aspekte blickt.
- Ein besonderer Fokus liegt auf der Kommunikation mit existierenden IT-Systemen, die oft heterogene Schnittstellen aufweisen.
- BPM-Plattformen bieten viel Raum für Flexibilität in der konkreten Umsetzung, z. B. können Process Engines als zentrale Serverinstanz oder eingebettet in Softwarekomponenten betrieben werden.
Um Aspekte und Entscheidungen von architektonischer Bedeutung für Prozessautomatisierungsprojekte mit Camunda BPM anhand von Expertenmeinungen zu evaluieren, hat die viadee in Zusammenarbeit mit dem Institut für Wirtschaftsinformatik der Westfälischen Wilhelms-Universität Münster (Prof. Dr. Herbert Kuchen) eine Befragung im Rahmen einer Masterarbeit durchgeführt. Mit der Befragung sollen folgende Fragen beantwortet werden:
- Gibt es einen Konsens für sinnvolle Gestaltungsentscheidungen?
- Wie werden solche Entscheidungen geprüft und eingefordert?
Ergebnisse der Studie
An der Delphi-Studie haben insgesamt elf Personen teilgenommen, hauptsächlich Software-Architekten in Camunda BPM-Projekten. Gegenstand der Studie ist die Evaluation von Architekturentscheidungen auf zwei Ebenen: Auf der ersten Ebene sind Entscheidungen in fünf verschiedene Kategorien eingeteilt und werden hinsichtlich ihrer Wichtigkeit und derzeitigen Berücksichtigung bewertet. Auf einer weiteren Ebene werden Architekturentscheidungen Ränge bezüglich ihrer Wichtigkeit zugeordnet und es wird erfasst, inwieweit sie durch die Teilnehmer bereits adressiert wurden. Ergänzend dazu findet eine Erhebung statt, wie jeweils Architekturentscheidungen getroffen werden. Die wesentlichen Ergebnisse sind zusammengefasst wie folgt:- Architekturentscheidungen in Prozessautomatisierungsprojekten werden mehrheitlich bereits explizit getroffen und von allen Teilnehmern als wichtig empfunden. Zudem sind Teilnehmer im Allgemeinen zufrieden mit der derzeitigen Berücksichtigung von Architekturentscheidungen in BPM-Projekten.
- Entscheidungen zur Prozessmodellierung werden im Vergleich zu den anderen Entscheidungskategorien am wichtigsten eingeschätzt (s. Tabelle). Ein Grund dafür ist, dass die betreffenden Entscheidungen speziell für Prozessanwendungen relevant sind und sich somit stärker von Architekturentscheidungen in anderen Softwareprojekten unterscheiden. Zudem sind das Prozessmodell betreffende Entscheidungen ein zentrales Element, um ein Alignment zwischen Fachabteilung und IT-Abteilung herzustellen – also gelten hier besondere Qualitätsansprüche.
- Die Kategorie zum Testen von Prozessanwendungen ist im Verhältnis zu den anderen Entscheidungskategorien weniger wichtig, allerdings sind Teilnehmer auch am wenigsten zufrieden mit der derzeitigen Berücksichtigung dieser Kategorie. Ein Grund besteht in der Herausforderung, den Automatisierungsgrad der Tests zu erhöhen (mit vertretbarem Aufwand).
- Der Kategorie „Governance von Prozessanwendungen“ gehören mehrere, durch Teilnehmer ergänzte Architekturentscheidungen an, die bisher aber noch nicht zufriedenstellend gelöst werden konnten – z. B. der Umgang mit Abhängigkeiten zwischen Prozessanwendungen.
- Viele der genannten Architekturentscheidungen können unter dem Thema „Prozessdaten und deren Austausch mit anderen Systemen“ zusammengefasst werden. Beispiele dafür sind die Berücksichtigung der neuen DSGVO, der Umgang mit extern definierten Datenstrukturen und das Modellieren von Datenflüssen in Prozessanwendungen. Hier gibt es Diskussionsbedarf und wenig Werkzeugunterstützung.
- Architekturentscheidungen mit einer Überschneidung zu fachlichen Entscheidungen werden auch als wesentlich für Projekterfolge eingeschätzt. Insbesondere die Umsetzung von Geschäftsregeln (Business-Rules) wird mehrheitlich als wichtig bewertet und ist ein Anliegen, mit dem sich Software-Architekten regelmäßig auseinandersetzen.
- Architekturentscheidungen werden auf unterschiedliche Weisen getroffen. Allerdings ist ein Trend zu erkennen, dass Architekturentscheidungen aufgrund ihres projektübergreifenden Charakters zentral formuliert werden, Entwicklungsteams jedoch selbst für deren Einhaltung verantwortlich sind. Das deutet darauf hin, dass Prozessanwendungen tendenziell in autonomen bzw. selbstverantwortlichen Teams entwickelt werden.
- Betrachtet man das Verständnis der Teilnehmer über die Rolle eines Architekten, fällt auf, dass dieser hauptsächlich einen unterstützenden Charakter mit dem Ziel der projektübergreifenden Koordination aufweist. Ebenso sind die meistgenutzten Maßnahmen zur Umsetzung von Architekturentscheidungen normativer Natur. Für beide Aspekte ist beispielsweise die Dokumentation von Richtlinien die meistgenannte Aktivität/Maßnahme, gefolgt von Schulungen für Entwicklungsteams.
- Zwar hat sich gezeigt, dass befragte Experten insgesamt zufrieden mit der derzeitigen Berücksichtigung von Architekturentscheidungen sind, zur Unterstützung für die Umsetzung allerdings nur Standard-Software für Modell-Richtlinien oder gar keine Tools einsetzen. Dies wird dem Komplexitätsgrad der verwendeten Komponenten (Java-Code, verteilte Dienste, Skripte, Spring-Konfigurationen oder Regeln) nicht gerecht.
Diese Ergebnisse sind als eine Bestandsaufnahme zu aktuellen, architektonischen Herausforderungen in Prozessautomatisierungsprojekten zu sehen. Sie dienen als Startpunkt für weitere Arbeiten in diesem Bereich.
Weiterentwicklung des vPAV-Tools
Ein weiteres Ziel der Delphi-Studie ist, die Ergebnisse in das OpenSource-Projekt viadee Process Application Validator (vPAV) einfließen zu lassen und Architekten somit in ihren Aufgaben zu unterstützen, insbesondere durch eine kontinuierliche Prüfung der Einhaltung von Architekturentscheidungen. Die Prüfung erfolgt durch automatisierte Softwaretests, in denen Prozessmodell und Quellcode gegen zuvor definierte Regeln validiert werden. Technisch erfolgt dieses in Form von JUnit-Tests und generierten Prüfberichten.Eine wesentliche Erkenntnis aus der Studie ist, dass wichtige Architekturentscheidungen zu Prozessdaten noch keine entsprechende Berücksichtigung finden und keine Unterstützung durch Tools vorhanden ist. In diesem Zusammenhang erfolgte die Weiterentwicklung des vPAV-Tools in zwei sich ergänzenden Komponenten: eine Visualisierung des Datenflusses integriert in das Prozessmodell und eine domänenspezifische Sprache, die Data Flow Validation Language (DFVL), zur Validierung von Datenflussregeln.
Rekonstruktion des Datenflusses von Prozessanwendungen
Der Datenfluss einer Prozessanwendung wird als die Summe der Operationen auf Prozessvariablen verstanden. Das derzeitige Problem besteht darin, dass Variablenoperationen über das gesamte Projekt verteilt sind. Sowohl in referenzierten Code-Dateien als auch im Modell selbst oder in Skripten können Prozessvariablen gelesen und manipuliert werden. Dadurch ist es schwer, einen Überblick zu gewinnen, auf welche Daten überhaupt zugegriffen wird und wo genau diese Zugriffe auftreten.Das vPAV-Tool beinhaltet bereits eine statische Code-Analyse, die unter anderem Variablenoperationen an möglichen Stellen in Prozessmodell und referenziertem Code erkennt und ausliest. Auf Basis dieser Information wird der generierte Output um eine weitere, interaktive Sicht auf das Prozessmodell ergänzt. In der Visualisierung erhält jedes Modellelement, an dem Operationen an Prozessvariablen entdeckt werden, eine Annotation. Die drei Zahlen repräsentieren die Anzahl der lesenden, schreibenden und löschenden Zugriffe. Ein Klick auf das Element öffnet ein Fenster, in dem mehr Details zu den einzelnen Operationen angezeigt werden, z. B. welche Variable manipuliert wird. Mithilfe dieser Erweiterung ist es nun möglich, sich einen Überblick über Datenflüsse in Prozessanwendungen in einem Bruchteil der sonst üblichen Zeit zu verschaffen.
DFVL zur Beschreibung von Datenflussregeln
Die zweite Weiterentwicklung des vPAV-Tools umfasst die DFVL, mit der es möglich ist, Regeln zur automatisierten Validierung von Datenflüssen zu formulieren. Diese Regeln repräsentieren Richtlinien und Konventionen, die eine konsistente und leicht verständliche Implementierung von Datenflüssen sicherstellen. Es handelt sich dabei jedoch um keine komplette oder starre Strukturvorgabe, sondern um Leitfäden, die von Entwicklern selbst beachtet und unter Umständen auch selbst definiert werden sollen – ähnlich einer Java-Annotation.Die automatisierte Validierung basiert ebenfalls auf der statischen Code-Analyse des vPAV-Tools und kann entweder in separaten Unit-Tests oder integriert in den allgemeinen Validierungsprozess des vPAV-Tools ausgeführt werden.
Das Beispiel zeigt die Definition einer Regel zum Verhindern mehrfacher Manipulationen von Variablen, die externe Daten repräsentieren. Dies kann analog zum final-keyword bei Java-Methodenparametern verstanden werden.
Eine Regel besteht im Allgemeinen aus einem Constraint, um die Menge der Prozessvariablen eingrenzen zu können, und einer Condition, die von allen Variablen erfüllt werden müssen, damit Regeln eingehalten werden.
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
