Was ist eine Prozessapplikation?

“Prozessapplikation” klingt nach einem weiteren Buzzword, und je nachdem, wen du fragst, bekommst du eine andere Antwort. Für die einen ist es ein Workflow-Tool, für die anderen eine zentrale Taskliste oder eine Integrationsplattform. Der Grund: Es gibt sehr unterschiedliche Vorstellungen davon, wie man Prozesse automatisiert. Hersteller, Berater und Fachbereiche meinen oft etwas anderes, wenn sie dasselbe Wort benutzen.

Genau deshalb lohnt sich eine saubere Abgrenzung. Wer den Begriff klar fasst, trifft bessere Entscheidungen: Was gehört in welche Schicht, wo lebt die Fachlichkeit, und wann brauchst du überhaupt eine Prozessapplikation. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von verwandten Konzepten ab.

Integrativer Prozess vs. Fachprozess

Bevor wir die Prozessapplikation definieren, braucht es eine Unterscheidung zwischen einem integrativen und einem fachlichen Prozess.

Ein integrativer oder orchestrierender Prozess verbindet vor allem Systeme oder Domänen. Er sorgt dafür, dass ein Aufruf von A nach B geht, dass Reihenfolgen eingehalten werden und dass am Ende alle beteiligten Systeme ihren Teil getan haben. Eigene Fachlichkeit bringt er kaum mit. Die Logik lebt in den Systemen, die er koordiniert.

Ein Fachprozess dagegen enthält konkrete Domänenlogik. Er bildet einen fachlichen Ablauf ab, trifft fachliche Entscheidungen und arbeitet mit den Regeln und Begriffen einer bestimmten Domäne. Er ist nicht nur Koordinator, er ist der eigentliche “Inhalt”.

Dieser Unterschied ist der Kern: Eine Prozessapplikation dreht sich um einen Fachprozess, nicht um reine Integration.

Oben ein integrativer Prozess, der nur Systeme verbindet. Unten ein Fachprozess mit eigener Domänenlogik. Integration koordiniert, der Fachprozess trägt den Inhalt.

Was ist eine Prozessapplikation?

Damit lässt sich der Begriff klar fassen:

Thomas HeinrichsSolution Architecture Lead bei Miragon

Definition

Eine Prozessapplikation ist ein eigenständig versioniertes und deploybares Software-Bundle, das einen oder mehrere konkrete Fachprozesse innerhalb einer Domäne ausführt.

Zwei Dinge stecken darin:

• Sie enthält Fachlichkeit und bildet genau eine konkrete Domäne ab, statt über mehrere Domänen hinweg zu wachsen. Sie bleibt fokussiert.
• Prozess, Formulare, Entscheidungslogik und weitere fachliche Logik werden als Einheit gebündelt und gemeinsam ausgeliefert.

Eine Prozessapplikation ist also nichts Loses. Sie ist ein Software-Bundle, das man als Ganzes versioniert und deployt. Und sie führt echte Fachprozesse aus, nicht nur einen Ablaufplan.

Der Begriff hat eine Geschichte. Bei Technologien wie Camunda 7, CIB seven oder Operaton sind häufig sogenannte Application-Programming-Use-Cases entstanden: Die Engine war in eine Anwendung eingebettet, und diese Anwendung enthielt viel Fachlichkeit. Genau solche Anwendungen sind Prozessapplikationen. Der Name macht nur explizit, was da ohnehin gebaut wurde.

Bestandteile einer Prozessapplikation

Eine Prozessapplikation bündelt typischerweise mehrere Bestandteile. Nicht jeder ist immer nötig, aber sie gehören zusammen und werden gemeinsam ausgeliefert:

• BPMN-Prozesse, sofern sinnvoll. BPMN muss nicht zwingend verwendet werden, kann aber ein zentraler Bestandteil sein.
• Entscheidungslogik, optional, zum Beispiel als DMN, für fachliche Regeln.
• Formulare für die Schritte, die ein Mensch bearbeitet.
• Fachliche Validierungen, die prüfen, ob eine Eingabe für die Domäne gültig ist.
• Domänenlogik, der eigentliche fachliche Kern.
• UI- bzw. Frontend-Anteile, mit denen konkrete Anliegen bearbeitet werden.

Die Aufzählung ist nicht abschließend. Genauso gehören zum Beispiel PDF-Templates und Vorlagen dazu, die im Prozess erzeugt oder genutzt werden.

Entscheidend ist, dass diese Teile eine Einheit bilden. Sie werden zusammen versioniert und zusammen deployt. Die Prozessapplikation läuft auf einer Prozess-Engine, aber die Engine ist keiner dieser Bestandteile. Sie ist Infrastruktur.

Die Bestandteile bilden ein Deployment-Bundle. Die Prozess-Engine trägt das Bundle als Infrastruktur, sie ist selbst kein Bestandteil.

Die Prozess-Engine ist Infrastruktur

Die Prozess-Engine führt die Prozesse aus, hält ihren Zustand und kümmert sich um Timer, Wiederholungen und Historie. Das ist wichtig für den Betrieb, aber es ist nicht die Fachlichkeit.

Der beste Vergleich ist eine Datenbank. Kaum jemand würde sagen, die Datenbank sei seine Anwendung. Sie ist notwendig, damit die Anwendung läuft, aber der fachliche Wert steckt in der Anwendung darüber. Genauso ist es mit der Prozess-Engine: Sie ist notwendige Infrastruktur, nicht der Kern.

Und weil sie nur Infrastruktur ist, sollte sie austauschbar bleiben. Auch eine Datenbank bindet man selten direkt in die Fachlogik ein, sondern greift über eine Abstraktion wie JPA darauf zu. Für die Prozess-Engine gilt dasselbe: Ob darunter Temporal, Camunda, CIB seven, Operaton oder etwas ganz anderes läuft, sollte die Prozessapplikation nicht interessieren müssen. So entsteht keine Bindung an einen einzelnen Hersteller.

Für genau diese Abstraktion gibt es die process-engine-api der BPM-Crafters-Community, an der wir selbst mitarbeiten. Sie entkoppelt die Fachlichkeit von der konkreten Engine, so wie JPA die Anwendung von der konkreten Datenbank entkoppelt. Dieselbe Haltung, offene Standards und Herstellerunabhängigkeit mit der Fachlichkeit im Zentrum, vertritt auch das BPM Manifesto.

Die Fachlichkeit liegt in der Prozessapplikation selbst. Die Engine lässt sich einkaufen, bereitstellen oder austauschen, den Fachprozess und seine Domäne muss man selbst besitzen.

Prozessapplikation im End-to-End-Prozess

Eine Prozessapplikation steht selten allein. Sie ist oft Teil eines größeren End-to-End-Prozesses, der sich über mehrere Fachbereiche zieht.

Dieser übergreifende Prozess ist selbst eher integrativ. Er orchestriert mehrere Domänen und ruft mehrere Prozessapplikationen auf, jede für ihren fachlichen Teil. Die einzelne Prozessapplikation bleibt dabei auf ihre Domäne fokussiert. Sie wächst nicht in fremde Domänen hinein, nur weil sie in einem größeren Ablauf mitspielt. Warum das wichtig ist, haben wir in unserem Post zu übergreifenden BPMN-Prozessen beschrieben.

So bleibt jede Prozessapplikation überschaubar und klar einem Team zugeordnet, während der End-to-End-Prozess das Zusammenspiel koordiniert.

Ein übergreifender End-to-End-Prozess orchestriert mehrere domänenfokussierte Prozessapplikationen. Jede bleibt auf ihre Domäne fokussiert.

Zentrale Taskliste vs. Prozessapplikation

Eine häufige Verwechslung ist die mit einer zentralen Taskliste. Eine solche Liste, manchmal auch Portal oder Aufgabenliste genannt, kann unternehmensweit anzeigen, welche Aufgaben anstehen und wer sie erledigen soll. Häufig wird sie sogar für Workforce-Steering genutzt und in diese Richtung ausgebaut, also um Arbeit über Teams hinweg zu verteilen und zu steuern.

Aber die eigentliche Bearbeitung gehört woanders hin. Die domänenspezifischen Formulare, die fachlichen Validierungen und die Fachlogik liegen in der Prozessapplikation. Die zentrale Taskliste zeigt die Aufgabe an, die Prozessapplikation liefert den fachlichen Inhalt dazu, oft als eingebettete Web Components. Ein modulares Formular-Framework dieser Art haben wir zum Beispiel bei DigiWF für die Landeshauptstadt München gebaut.

Es wäre ein Fehler, domänenspezifische Validierungen in die zentrale Taskliste zu verlagern. Sie würde damit Fachlichkeit übernehmen, die nicht ihre ist, und müsste über kurz oder lang alle Domänen kennen. Die Taskliste macht Arbeit sichtbar. Die Fachlichkeit bleibt in der Prozessapplikation.

Die zentrale Taskliste zeigt Aufgaben an. Die Prozessapplikation liefert Aufgabe und Formular samt Validierung und Fachlogik.

Gegenüberstellung: Orchestrierung, Integration, Prozessapplikation

Zum Abschluss die drei Begriffe klar nebeneinander, damit du sie im Gespräch sicher auseinanderhältst:

	Orchestrierungsprozess	Integrationsprozess	Prozessapplikation
Zweck	Koordiniert Schritte und Systeme über einen Ablauf	Verbindet Systeme und Domänen, reicht Daten weiter	Führt konkrete Fachprozesse einer Domäne aus
Eigene Fachlichkeit	Wenig: die Logik liegt in den koordinierten Systemen	Kaum: verbindet, entscheidet aber nicht fachlich	Ja: Domänenlogik, Regeln, Validierungen, Formulare
Domänenbezug	Übergreifend, oft mehrere Domänen	Übergreifend	Genau eine Domäne, fokussiert
Typische Rolle	Klammer um einen End-to-End-Ablauf	Brücke zwischen Systemen	Fachlicher Baustein, der echte Arbeit erledigt

Fazit

Eine Prozessapplikation hält die Fachlichkeit: sie ist ein eigenständig deploybares Bundle, das die Fachprozesse einer Domäne ausführt. Die Engine darunter ist austauschbare Infrastruktur, nicht der Kern. Orchestrierung koordiniert, Integration verbindet, die Taskliste zeigt an, aber die Fachlichkeit gehört in die Prozessapplikation. Wer das sauber trennt, baut Systeme, die man versteht, besitzt und weiterentwickeln kann.