Amtsschimmel, ade - Teil 1

Architekturen für die Digitalisierung: Workflowautomation und Microservices

Stephan Kaps

© Shutterstock / Sweet Art

Fällt das Wort Digitalisierung, denken viele an Projekte im Umfeld des Internet of Things oder an spektakuläre Blockchains. Immer häufiger wird Digitalisierung in einem Atemzug mit künstlicher Intelligenz genannt, oder es werden neue Megaprojekte wie eine europäische Cloud ausgerufen. Dass es bei Digitalisierung jedoch zu großen Teilen darum geht, Prozesse digital zu unterstützen, die aktuell entweder mit manuellem Aufwand wie beispielsweise persönlichem Erscheinen verbunden sind oder lediglich schriftlich erledigt werden können, wird stark vernachlässigt. Nicht so in diesem Artikel.

Es gibt noch hunderte von Verfahren, vor allem im Behördenumfeld, die für den Bürger einfacher werden, wenn sie digitalisiert sind. Ein solches Antragsverfahren sehen wir uns näher an. Mit Hilfe eines Überblicks über die Architektur, die Infrastruktur und die organisatorischen Aspekte soll verdeutlicht werden, dass moderne Technologien und Methoden für jede Art von Organisation Mehrwerte bringen und Aussagen wie „Wir sind doch nicht Netflix“ keine tragfähigen Argumente sind.

Artikelserie

Teil 1: Architekturen für die Digitalisierung mit Workflowautomation und Microservices

Teil 2: Infrastrukturen und Organisation

Um was es geht – die Domäne

Das hier vorgestellte behördliche Antragsverfahren wird von mehr als 20 000 Bürgern pro Jahr genutzt. Die Fachlichkeit ist relativ komplex und würde daher den Rahmen dieses Artikels sprengen – sie ist im Detail aber auch nicht entscheidend. Zur Veranschaulichung wird in Abbildung 1 ein mit Hilfe von Domain Storytelling (Kasten: „Domain Storytelling“) modellierter Prozess dargestellt. In diesem Fall handelt es sich um eine stark vereinfachte Abbildung des gesamten Antragsverfahrens.

Abb. 1: Domain Story des Onlineantrags

Abb. 1: Domain Story des Onlineantrags

In diesem Modell ist zu sehen, dass ein Antragsteller seine Antragsdaten in einem Onlineformular erfasst, woraufhin diese Daten nach dem Abschicken in eine Fachanwendung übertragen werden. Die Fach anwendung wiederum erzeugt in einem Dokumentenmanagementsystem (DMS) eine Akte und fordert, wenn notwendig, automatisiert weitere Informationen beim Antragsteller nach. Der Antragsteller übermittelt diese Informationen in Form von Anlagen per Upload über eine Art Onlineportal. Diese Dokumente werden in das DMS importiert und der entsprechenden Akte hinzugefügt. Die Fachanwendung verteilt den Fall an einen Sachbearbeiter und erzeugt im besten Fall bereits einen Bescheidentwurf. Details zu Berechnungen, Sonderfällen sowie den verschiedenen Arten von möglichen Bescheiden werden nicht näher betrachtet.

Der soeben erzeugte Bescheidentwurf wird vom ermittelten Sachbearbeiter geprüft und bestätigt, wodurch er dem jeweiligen Vorgesetzten zur Mitzeichnung (Freigabe) vorgelegt wird. Ist diese erfolgt, löst die Fachanwendung im positiven Fall eine Auszahlung über das Zahlungssystem aus und der Fall ist beendet.

DDD Camp
Matthias Bohlen

Jetzt auch als Online-Seminar

Das Intensivtraining für Domain-driven Design mit Matthias Bolen

Domain Storytelling

Domain Storytelling ist ähnlich wie Event Storming eine Technik, um die Fachlichkeit verstehen zu lernen. Es hilft, eine gemeinsame Sprache mit den Fachexperten zu entwickeln. Ein Domänenexperte wird zu Beginn gebeten, die einzelnen Schritte innerhalb eines Arbeitsablaufs anhand einer Geschichte zu erzählen. Die Aufzeichnung der einzelnen Arbeitsschritte erfolgt in Form einfacher Piktogramme.

Diese Piktogramme verwenden eine Symbolsprache, um einen Workflow zu erklären. Diese Symbolsprache nennt sogenannte Actors (beispielsweise Benutzer oder Systeme), die eine Activity mit Hilfe sogenannter Work Objects (beispielsweise Dokumente, Formulare oder Datensätze) durchführen. Durch ein Lesen der Diagramme in der notierten Reihenfolge in Richtung der Pfeile erzählen sie die Geschichte der Domänenexperten nach. Dabei stammen die Bezeichnungen in den Piktogrammen aus der Domänensprache und bilden damit einen Anhaltspunkt für eine Ubiquitous Language. Im Gegensatz zu anderen Prozessmodellierungsnotationen wird dabei aber nur eine einzelne, beispielhafte Interaktion (etwa nur ein „Happy Case“) mit dem System formuliert und nicht alle möglichen Interaktionen mit allen möglichen Fehlerfällen. [1]

Folgende Ziele werden mit dem hier betrachteten Projekt verfolgt:

  • Bereitstellung eines einfachen (Online-)Antragsverfahrens für den Bürger, mit der Möglichkeit, Anlagen hochzuladen und sich über den aktuellen Bearbeitungsstatus online zu informieren

  • Schnelle Durchlaufzeiten; Standardfälle werden nach der Erfassung vom System berechnet und beschieden oder es wird, im Fall einer Unvollständigkeit, automatisch ein Nachforderungsschreiben versandt und auf den oder die Eingänge gewartet

  • Entlastung der Sachbearbeiter durch den Wegfall manueller Tätigkeiten, beispielsweise der Erstellung von Eingangsbestätigungen, Nachforderungsschreiben, Erinnerungsschreiben, Bescheiden u. v. m.

  • Automatisierte (einheitliche) Erstellung von Schreiben mit Hilfe von konfigurierbaren Textbausteinen und Ablage sämtlicher Dokumente in der E-Akte

  • Automatisierte Meldung der ausgezahlten Leistungen an die zuständigen Finanzämter

  • Automatisierte Überweisungen an Dritte und automatisierte Überwachung der Überweisungen auf Ausgleich

  • Automatisierte Berechnung und Berücksichtigung von Widerspruchs- und Klagefristen sowie die prozessuale Umsetzung der Verfahren

Neben den gerade aufgezählten (eher fachlichen) Zielen werden des Weiteren noch die folgenden (eher technischen) Ziele verfolgt:

  • Integration der Drittsysteme mit loser Kopplung und standardisierter Kommunikation über definierte Schnittstellen

  • Minimierung des Customizings des E-Akten-Systems, um zukünftige Versionsupdates ohne Aufwand und Risiko durchführen zu können

  • Teilautomatisiertes Fachverfahren mit BPMN-gesteuerten Prozessen und somit einheitlicher und effizienter Bearbeitung der Anträge

  • Einführung regelbasierter Entscheidungstabellen, um Ablehnungsgründe, Sonderfälle und Inkonsistenzen schnell und zweifelsfrei identifizieren zu können

  • Automatisierte Übertragung und Import der Onlineanträge in die Fachanwendung sowie automatisierte Erstellung von Akten und Vorgängen im E-Akten-System

Durch die BPMN-gestützte Prozesssteuerung wird der Sachbearbeiter durch die Bearbeitung von Anträgen geführt. Durch die Zuweisung konkreter Aufgaben (Tasks) im Rahmen des Prozessverlaufs ist zu jeder Zeit klar, welcher Schritt mit welchen Tätigkeiten erfolgen muss. Schauen wir uns im Folgenden die daraus entstandene Architektur an.

Die Architektur

Abbildung 2 zeigt die zum Zeitpunkt der Erstellung dieses Artikels aktuelle Architektur des Gesamtsystems. Um dem Bürger eine Onlineantragsmöglichkeit bereitzustellen, läuft in der DMZ (demilitarisierten Zone) eine Webanwendung, die XML-Dateien erzeugt, die von der internen Fachanwendung in regelmäßigen Abständen importiert werden. Des Weiteren hat der Antragsteller die Möglichkeit, den aktuellen Bearbeitungsstatus online abzufragen. Das ist eine eigene Webanwendung.

Die zentrale Rolle spielt die Fachanwendung. Dabei handelt es sich ebenso um eine Java-Webanwendung, die wie alle anderen Webanwendungen als klassisches WAR-Archiv auf einem WildFly Application Server betrieben wird. Integriert in diese Fachanwendung ist die leichtgewichtige Workflow-Engine Camunda (embedded). Des Weiteren sind die Drittsysteme Dokumentenmanagementsystem und Zahlungssystem zu sehen, bei denen es sich um proprietäre Produkte handelt, die bereits existieren und über SOAP-Schnittstellen verfügen.

Um die Anbindung der Drittsysteme einfach und konsistent zu anderen Schnittstellen umzusetzen, wurden REST Services als Anti-Corruption Layer für die SOAP-Schnittstellen implementiert (DMS REST Service und ZS REST Service). Neben diesen REST Services existieren weitere (PLZ-, BLZ-, Textbaustein-, Report- und Status-Exporter-Service), die alle als Spring Boot Microservices in Docker-Containern betrieben werden.

Der PLZ-Service ist für die Validierung von Postleitzahl-Ort-Kombinationen zuständig und verwaltet alle möglichen Kombinationen in einer eigenen Datenbank. Die Daten stammen von einem Produkt der Post und werden quartalsweise aktualisiert. Der Textbaustein-Service liefert die für die Bescheiderstellung oder Nachforderungsschreiben notwendigen Textbausteine. Diese verwaltet er ebenso in einer eigenen Datenbank. Die Pflege der Daten erfolgt über die Fachanwendung. Beim Status-Exporter-Service handelt es sich quasi um einen Scheduler, der in regelmäßigen Abständen den Bearbeitungsstatus sämtlicher Fälle der letzten Monate aus der Fachanwendungsdatenbank liest und eine Datei erzeugt, die in der DMZ bereitgestellt wird. Diese wiederum kann von der App zur Onlinestatusabfrage ausgelesen werden. Der Report-Service kümmert sich um den Sonderfall der Erzeugung von Bescheiden im Word-Format, die zwar Daten aus dem Fall enthalten, aber um individuelle Texte durch einen Sachbearbeiter ergänzt werden müssen, z. B. im Widerspruchsverfahren. Der BLZ-Service kann mit Hilfe einer durch die Bundesbank bereitgestellten Datei zu einer IBAN die entsprechende Bankleitzahl feststellen.

Beim FinanzdatenService und der ElsterLohnApp handelt es sich technisch gesehen ebenfalls um Spring Boot Services. Ersterer kümmert sich fachlich um die Datenextraktion aus der Datenbank der Fachanwendung sowie die notwendige Transformation in das vorgegebene XML-Format, während die ElsterLohnApp den Transferprozess dieser XML-Daten an die Finanzämter steuert.

Bei den Komponenten, die am linken und rechten Rand vertikal aufgeführt sind, handelt es sich um Infrastrukturkomponenten, die im zweiten Teil dieser Serie genauer betrachtet werden.

Abb. 2: Architektur des Gesamtsystems

Abb. 2: Architektur des Gesamtsystems

Damit die Fachanwendung nicht die Endpunkte der Services kennen muss, wird eine Service Registry, hier HashiCorp Consul, verwendet. In dieser Registry sind alle Services registriert, meist mit mehreren Instanzen mit sich eventuell dynamisch ändernden Lokationen. Die Fachanwendung muss nur einen lokalen Agenten nach dem Namen eines Service fragen, und die Registry liefert einen Endpunkt zurück, der aktuell auch Anfragen entgegennehmen kann. Das wird mit Hilfe automatischer Health Checks sichergestellt.

Warum Microservices?

Das hier beschriebene System wird von einem lediglich zehnköpfigen Entwicklerteam umgesetzt, was bedeutet, dass organisatorische Gründe wie die Reduzierung von Kommunikationsbeziehungen und Abstimmungsaufwand bei der Entscheidung, Microservices zu nutzen, nicht entscheidend waren. Microservices bieten jedoch generell eine elegante Art der Modularisierung. Es ist möglich, die für die eigentliche Domäne primär nicht relevanten fachlichen Teile auszulagern, was Vorteile wie lose Kopplung, bessere Wart- und Testbarkeit sowie unabhängige Deployments ermöglicht.

Bei den in Abbildung 2 zu sehenden Microservices PLZ-Service, BLZ-Service sowie Textbaustein-Service handelt es sich um solche Komponenten, die im Domain-driven Design (DDD) als Generic Subdomains bezeichnet werden. Diese Services repräsentieren bereits gelöste Probleme, die für diverse Systeme oder sogar unterschiedliche Unternehmen immer gleich umgesetzt werden. Sie gehören in DDD nicht zum Kerngeschäft (den sogenannten Core Subdomains) und können im einfachsten Fall hinzugekauft werden – oder es existieren entsprechende Open-Source-Projekte.

In der Fachanwendung selbst existieren aktuell mehrere unterstützende Funktionalitäten, die zwar mit der Businesslogik verknüpft sind, jedoch leicht in separate Microservices ausgelagert werden könnten, um die Domäne von nicht zum Kern gehörendem Code zu befreien. Bei DDD spricht man dabei von Supporting Subdomains. Beispiele dafür sind Referenz- oder Stammdatenverwaltungen, Protokollierungs- und Kommentarfunktionen.

Die Services DMS-Rest-Service und ZS-Rest-Service dienen der Abstraktion der SOAP-Schnittstellen, was Information Hiding fördert und die Benutzbarkeit der Schnittstellen verbessert, da sie auf die fachlichen Bedürfnisse zugeschnitten sind. Diese Designtechnik wird auch als Anti-Corruption Layer bezeichnet [2]. Es handelt sich dabei um eine architekturelle Schicht, die das Domänenmodell von anderen Modellen trennt und die es ermöglicht, dass auf das fremde Modell so zugegriffen werden kann, wie es das eigene Domänenmodell erfordert.

Microservices bieten generell die Möglichkeit, unabhängige Technologiestacks zu verwenden. Bezüglich des Report-Service war es ursprünglich nicht vorgesehen, einen eigenen Microservice zu entwickeln. Die transitiven Abhängigkeiten der dafür eingesetzten Bibliothek waren jedoch mit denen der Fachanwendung nicht vereinbar. Durch die Auslagerung in einen separaten Service, der wiederum seine eigenen Abhängigkeiten mitbringen kann, konnte dieses technische Problem elegant gelöst werden.

Ist das nicht SOA?

Die soeben vorgestellten Services können in drei Kategorien unterteilt werden. In die erste Kategorie gehören der Postleitzahlen- und der Bankleitzahlen-Service. Diese Services kommen ohne jeglichen fachlichen Kontext aus und können daher von mehreren Consumern ohne Anpassungsbedarf wiederverwendet werden.

Zur zweiten Kategorie zählen der Status-Exporter-Service, der Report-Service und der Textbaustein-Service. Diese Services haben einen starken fachlichen Bezug zu der konkreten Fachanwendung. Es wäre vorstellbar, den Textbaustein-Service als zentralen Service anzubieten und in anderen Fachanwendungen wiederzuverwenden. Das würde jedoch dazu führen, dass entweder zu viel Aufwand in eine Generalisierung gesteckt wird oder fachlicher Kontext sich im Code oder sogar im API widerspiegelt. Ein Beispiel: In der in diesem Artikel betrachteten Domäne werden Textbausteine für diverse Kategorien gepflegt und verwendet: für Nachforderungsgründe, Ablehnungsgründe usw. Textbausteine einer Kategorie können direkt über das API abgefragt werden. Sollte ein weiteres System Textbausteine benötigen, jedoch keine Kategorien, wäre es gezwungen, eine fiktive Dummykategorie zu verwalten, um diesen Service so nutzen zu können. Das mag für dieses Beispiel akzeptabel klingen, aber ich denke, das Prinzip wird klar. Im Allgemeinen bedeutet es: Bei fachlichem Kontext werden separate Services entwickelt.

Der DMS-Service und der Zahlungssystem-Service bilden Kategorie 3. Es handelt sich um fachlich sehr stabile Services, die für mehrere Fachanwendungen einsetzbar sind. Daher wird ein Zwischenweg gewählt, indem die Services je Kontext mit unterschiedlichen Konfigurationen (Spring Boot Profiles) separat deployt werden. Sollte der Bedarf entstehen, für eine konkrete Fachanwendung spezielle Änderungen oder Funktionen in diesen Services bereitzustellen, kann noch auf die Variante eines Forks (wie Kategorie 2) umgestellt werden.

Das ist ein (Frontend-)Monolith, oder?

Bei der Fachanwendung handelt es sich immer noch eher um einen Monolithen, trotz einiger Microservices. Das ist generell auch kein Problem, vor allem unter Berücksichtigung der Teamgröße.

Ob in Zukunft die Fachanwendung in mehrere Bounded Contexts zerschnitten wird und somit weitere Microservices für die Core Subdomains entstehen, ist fraglich. Sowohl technisch als auch fachlich besteht aktuell kein Bedarf. Es gibt nur einen fachlich Verantwortlichen für das Verfahren, und somit existieren keine fachlichen Schnittstellen oder getrennte Kontexte. Wären mehrere Abteilungen am Prozess beteiligt und hätten interne Abläufe, für die sie selbst verantwortlich sind, würde alles dafürsprechen, sowohl die Fachanwendung als auch die Prozesse in unabhängige Einheiten zu separieren. Dadurch wären lokale Anpassungen leichter umsetzbar, ohne notwendige Abstimmung, wann welche Funktionalität in welcher Version releast werden kann.

Ein natürlicher Schritt in naher Zukunft wird sein, das UI des Textbaustein-Service (also das Pflegen von Textbausteinen) in den Service selbst zu überführen.

Eine einfache Möglichkeit der Integration in das Frontend der Fachanwendung wäre über Links möglich. Auch die Integration über iframes ist nicht auszuschließen, da diese das Aussehen und die Funktionalität sauber kapseln würden. Alternativen wären Transklusion, SSI (Server-side Includes) oder ESI (Edge-side Includes). Durch die Verlagerung des UI in den Service würde der Service zu einem Self-contained System (Kasten: „Self-contained Systems“).

Self-contained Systems

Bei Self-contained Systems handelt es sich um einen von INNOQ geprägten Begriff [3]. Grundsätzlich geht es darum, die Funktionalität eines Gesamtsystems in kleinere, unabhängige Systeme zu zerteilen, um die Probleme monolithischer Systeme zu umgehen. Dabei soll jedes SCS ein eigenständiges System sein, das heißt, einen vertikalen Schnitt mit Frontend, Backend und Datenhaltung abbilden. Kommunizieren soll ein SCS mit anderen SCSs, wenn nötig, asynchron über APIs. Des Weiteren teilen sie keine Geschäftslogik und keine Infrastruktur mit anderen SCSs. Gemeinsame (technische) Bibliotheken können genutzt werden, wie zum Beispiel ein OAuth-Client. Ein SCS ist „klein genug“, um von einem Team betreut werden zu können.

Wieso Workflow-Engine?

In diesem System verwenden wir wie in Abbildung 2 gezeigt eine Workflow-Engine. Generell wird durch den Einsatz von Geschäftsprozessmodellierung die Zusammenarbeit von Fachbereich und IT deutlich verbessert. Sie ermöglicht es, Abläufe in einfacher Notation darzustellen und ein gemeinsames Verständnis sowie eine gemeinsame Sprache zu entwickeln. Durch den Einsatz einer Workflow-Engine wird es möglich, den zwischen Fachbereich und IT abgestimmten Prozess in einen technischen Workflow zu überführen – im besten Fall ohne Anpassung der modellierten Elemente. Diese Prozesstransparenz verbessert das Spezifizieren von Anforderungen.

Eine Workflow-Engine kann als State Machine bezeichnet werden, was bedeutet, dass zu jedem Zeitpunkt ersichtlich ist, in welchem Status sich Prozessinstanzen befinden. Durch die Möglichkeit, Regeln und Entscheidungen leicht zu modellieren und zu automatisieren, werden die Verständlichkeit und vor allem die Durchlaufzeit von Vorgängen verbessert.

Existieren Prozesse, in denen es zu langlaufenden Aktionen kommen kann oder in denen menschliche Interaktion notwendig ist, sind das weitere Indikatoren für den Einsatz einer Workflow-Engine.

Ein weiterer Einsatzbereich ist die Microservices-Orchestration, was die Steuerung der Aufrufe an die diversen Microservices mit Hilfe des Prozesses bedeutet. Da es sich um verteilte Systeme handelt, bedingt das jedoch, sich mit Idempotenz und Kompensation [4] sowie Fehlerbehandlung und Resilienz innerhalb des modellierten Prozesses zu beschäftigen.

In dem hier beschriebenen Projekt koordiniert der Workflow, welche Aktion als Nächstes durchzuführen ist, und delegiert die Ausführung an die Fachanwendung, die wiederum weiß, welche Services aufzurufen sind und was zu tun ist, wenn einzelne Schritte fehlschlagen.

In Listing 1 ist ein kleines Beispiel zu sehen. Die Klasse implementiert das von Camunda bereitgestellte Delegate, ein Java-API, das erfordert, dass eine Methode execute überschrieben wird. An die Methode wird eine DelegateExecution übergeben, die es ermöglicht, an den Prozess und dessen Ausführung und somit an sämtliche Prozessvariablen zu gelangen. Die ausgelesene Fall-ID der Prozessinstanz wird im Anschluss an eine Servicemethode zum Anlegen oder Aktualisieren der zugehörigen Akte übergeben. Diese wiederum ruft den DMS REST Microservice auf und verwendet dabei Resilienzpattern wie Circuit Breaker und Fallbacks. Über ein execution.setVariable() wird das im Service generierte Geschäftszeichen an eine Prozessvariable übergeben. Der von der Klasse erweiterte CamundaEndpoint stellt ein selbst implementiertes Verhalten für Fehlerzustände bereit, das von allen Delegates im catch-Bereich einfach per createIncident() verwendet werden kann. Dabei handelt es sich zum Beispiel um speziell aufbereitete Logmeldungen oder eine Benachrichtigung per E-Mail. Die Prozessinstanz selbst erzeugt in diesem Beispiel im Fehlerfall einen Incident und muss manuell behandelt werden, da dann meist von einer technischen Störung auszugehen ist, die sich auch durch bereits drei standardmäßig durchgeführte Retries nicht selbst heilen konnte.

@Named
public class DmsFileCreateOrUpdateDelegate extends CamundaEndpoint implements JavaDelegate {
 
  ...
 
  @Override
  @Transactional(Transactional.TxType.REQUIRES_NEW)
  @Interceptors(CamundaLoggerIntercept.class)
  public void execute(DelegateExecution execution) throws Exception {
    try {
      Long fallId = (Long) execution.getVariable(Vars.ATTRIB_FALL_ID);
      Akte akte = antragService.createOrUpdateAkte(fallId);
 
      execution.setVariable(ATTRIB_AKTENZEICHEN, akte.getGeschaeftszeichen());
    } catch (Exception e) {
      createIncident(e, execution);
    }
  }
}

Weshalb Camunda?

Bei der Frage einer Prozesssteuerungssoftware fiel die Wahl sehr schnell auf Camunda. Zum einen handelt es sich dabei um ein Open-Source-Produkt, das bereits weit verbreitet und gut dokumentiert ist, zum anderen bietet es neben der Möglichkeit, REST APIs zu verwenden, auch ein leichtgewichtiges Java API. Nachdem die Dependencies in der pom.xml eingetragen sind, ist es sehr einfach möglich, laufende Prozesse anzufragen, Aufgabenlisten abzurufen oder entsprechende Schritte abzuschließen. Die Nutzung des Java API ist äußerst entwicklerfreundlich, und es ist einfacher, Unit-Tests zu implementieren und Transaktionen zu steuern sowie technische Tasks aus dem fachlichen Prozess weitestgehend herauszuhalten.

Neben der BPMN-Notation unterstützt Camunda auch Decision Model and Notation (DMN) für Entscheidungstabellen und Case Management Model and Notation (CMMN) für spezielle Fallbearbeitung.

Camunda wird bereits in der Open-Source-Variante mit zusätzlichen Applikationen ausgeliefert. Dazu zählt eine Administrationsoberfläche für Berechtigungen und Deployments, eine Taskliste, in der die durch die aktuell laufenden Prozesse erzeugten Human Tasks angezeigt werden, sowie ein Cockpit wie in Abbildung 3, in dem alle laufenden Prozesse überwacht und im Fehlerfall wieder gestartet werden können.

Abb. 3: Camunda Cockpit

Abb. 3: Camunda Cockpit

In dem in diesem Artikel beschriebenen System sind inzwischen acht Prozesse mit insgesamt 53 Tasks, begleitet von neun Decision Tables und acht Timern entstanden.

Aber als BPMN-Monolith, oder?

Ist durch die umfangreiche Auslagerung von Geschäfts- und Ablauflogik in den modellierten Geschäftsprozess ein BPMN-Monolith entstanden, der wiederum schwer zu warten und zu ändern ist? Wäre es nicht besser, zumindest die Subprozesse herauszulösen?

Dieser Annahme widerspricht wie bereits erwähnt die Tatsache, dass es für den gesamten Geschäftsprozess nur einen Owner gibt. Das heißt, eine Person ist Ende-zu-Ende verantwortlich, sodass die Notwendigkeit, hier Bounded Contexts zu ziehen, um Abstimmungsaufwände zu reduzieren, nicht gegeben ist.

Des Weiteren ist der Gesamtprozess bereits in mehrere Subprozesse aufgeteilt. Bei Bedarf wäre es denkbar, diese in eigene Spring-Boot-Applikationen mit jeweils eigener integrierter Workflow-Engine zu überführen. Die in der Fachanwendung betriebene Workflow-Engine wird nicht von weiteren Applikationen als eine Art zentrale Workflow-Engine verwendet.

Aufgrund der Integration der Workflows in die Fachanwendung müssen keine Überlegungen über separate und zu synchronisierende Deployment-Pfade stattfinden. Häufig wird eine neue Version eines Workflows mit einer neuen Version der Fachanwendung zusammenhängen.

Sehr positiv ist darüber hinaus die Möglichkeit, eine automatische Migration von laufenden Prozessen beim Deployment von einer alten auf eine neue Version durchzuführen, gegebenenfalls mit Hilfe programmierter Migrationslogik.

Fazit

Das in diesem Artikel vorgestellte Verfahren ist produktiv im Einsatz und hat alle gesteckten Ziele erreicht. Leider ist der letzte Schritt, das Onlinebereitstellen der Bescheide, noch nicht umgesetzt. Es fehlt hier an geeigneten technischen Möglichkeiten mit weiter Verbreitung, den Antragsteller eindeutig identifizieren zu können (Stichwort: Zwei-Faktor-Authentifizierung). Wer einen Vorschlag für uns hat, kann sich gerne bei mir melden.

In einem Folgeartikel gehe ich auf die Infrastruktur dieses modernen On-Premises-Verfahrens ein und stelle euch die organisatorischen Maßnahmen vor, die wir gewählt haben, um Agilität in einem nicht agilen Umfeld leben zu können.

Geschrieben von
Stephan Kaps
Stephan Kaps
Stephan Kaps leitet die Softwareentwicklung im Bundesversicherungsamt und ist Gründer der Java User Group Bonn. Als Softwarearchitekt und Entwickler hat er seit 2002 mit Java zu tun.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: