Offene Spezifikationen, portable Prozesse

In den meisten Organisationen ist die genaueste Beschreibung dessen, wie die Arbeit abläuft, der Code der Software, die sie ausführt. Eine Regel, die einmal aus gutem geschäftlichem Grund aufgestellt wurde, landet als Bedingung irgendwo in einer Anwendung. Eine Verantwortung wird zu einer Mischung aus Berechtigungen und Workflow-Einstellungen. Eine Zusammenarbeit mit einem Partner wird zu einer Reihe von API-Aufrufen und Mappings.

Die Software funktioniert weiter, aber die Gründe dahinter sind immer schwerer zu finden. Und wem die Software gehört, dem gehört in der Praxis das Wissen darüber, wie Sie arbeiten.

In CaseFlows ist Ihre Arbeitsweise in einer offenen Spezifikation festgehalten: der Case, die Phasen, die er durchläuft, die Case-Rollen, was jede Rolle in jeder Phase sehen und tun kann und welche Dienste verwendet werden. Präzise genug, um ausgeführt zu werden, und lesbar genug, um sie mit den Menschen zu besprechen, die die Arbeit tun.

Die Dateien sind offen: JSON für die Struktur, Markdown für die Begründung. Sie können sie ohne CaseFlows lesen, aufbewahren und mitnehmen.

Die Spezifikation ist keine Dokumentation neben dem System. Sie definiert den Caseflow, den die Runtime ausführt: seine Phasen, Rollen, Berechtigungen und Regeln. Die Runtime setzt diese Grenzen durch; Menschen, Dienste und KI erledigen die Arbeit innerhalb dieser Grenzen.

Darin unterscheidet sich CaseFlows auch von vieler modellgetriebener Software, bei der ein Modell in Code oder Konfiguration übersetzt wird und beide danach auseinanderlaufen können. Hier liest die Runtime die Spezifikation selbst. Eine Änderung der Spezifikation ändert den definierten Prozess, ohne dass dieser Prozess als Anwendungscode neu gebaut werden muss. Wie aus einer Absicht eine Spezifikation wird, lesen Sie unter Von der Absicht zum laufenden System.

Offene Dateien sind der Anfang. Echte Portabilität braucht drei Ebenen, und es hilft, genau zu sagen, wo jede steht:

• Offenes Format: Die Spezifikation ist lesbar und lässt sich mitnehmen. Das gilt heute.
• Offene Bedeutung: eine öffentliche Definition dessen, was eine Case-Rolle ist, wann eine Berechtigung gilt und was passiert, wenn ein Case die Phase wechselt, unabhängig von einer bestimmten Runtime. Heute wird diese Bedeutung durch unsere Schemas und durch die CaseFlows-Runtime definiert; sie eigenständig zu veröffentlichen ist unsere Richtung.
• Unabhängige Ausführung: andere Runtimes, die dieselbe Spezifikation mit derselben Bedeutung ausführen. Heute ist CaseFlows die einzige.

Was Ihnen heute gehört, ist also eine lesbare, portable Beschreibung Ihrer Arbeitsweise, in einer Form, mit der Menschen und KI arbeiten können. Sie anderswo auszuführen ist das, was die offenen Formate möglich machen sollen, nicht etwas, das es schon gibt.

Open Source hat es möglich gemacht, Software zu teilen, zu studieren und zu verbessern, ohne von ihrem ursprünglichen Entwickler abhängig zu sein. Offene Spezifikationen könnten etwas Ähnliches für die Arbeitsweise von Organisationen leisten.

Statt eine Anwendung zu teilen, teilen Organisationen, was sie gelernt haben: die Verantwortlichkeiten, Regeln, Entscheidungen, Ausnahmen und Muster der Zusammenarbeit, die einen Prozess funktionieren lassen. Dieses Wissen ist nicht nur etwas für Programmierende. Prozessverantwortliche, Fachleute und Branchenverbände können es lesen, besprechen und verbessern.

Die Spezifikation wird zum gemeinsamen Gut. Wie sie umgesetzt wird, soll eine Wahl bleiben; heute läuft sie auf CaseFlows.

Drei Versprechen, jedes mit eigenem Stand:

• Eigentum: Ihre Organisation besitzt eine lesbare, portable Beschreibung ihrer Arbeitsweise. Heute.
• Wiederverwendung: Eine Spezifikation lässt sich übernehmen und zu einer eigenen Variante anpassen. Heute innerhalb von CaseFlows möglich; bisher innerhalb unserer eigenen Plattformen umgesetzt.
• Interoperabilität: Verschiedene Anbieter führen dieselbe Spezifikation aus. Unsere Richtung, und die schwierigste der drei.

Angenommen, eine andere Organisation hat einen guten Weg gefunden, eine bestimmte Art von Anfrage zu bearbeiten. Würde sie ihre Software teilen, müssten Sie sie wahrscheinlich neu bauen, damit sie zu Ihren eigenen Systemen und technischen Entscheidungen passt.

Teilt sie ihre Spezifikation, bekommen Sie, was sie gelernt hat: welche Case-Rollen sich als nötig erwiesen haben, wo die Verantwortung liegt, welche Informationen in welcher Phase wichtig sind, welche Ausnahmen aufgetreten sind. Sie übernehmen den Caseflow, machen Ihre eigene Variante, binden Ihre eigenen Dienste an, wo deren Dienste nicht passen, und entwickeln ihn weiter, ohne auf den ursprünglichen Autor zu warten.

Wenn zwei Organisationen zusammenarbeiten, müssen sie ihre internen Caseflows nicht teilen. Was sie teilen, ist die Grenze: die Case-Rolle, die die eine an die andere übergibt, mit ihrer Verantwortung, ihren Informationen, dem, was sie in jeder Phase tun darf, und dem erwarteten Ergebnis. Diese Grenze ist eine Spezifikation, die beide Plattformen verstehen und beide bestätigen; eine Änderung ist eine neue Version, die beide in ihrer Entwicklungsumgebung ausprobieren können, bevor sie gilt.

Das ist eine andere Art des Teilens als die Wiederverwendung:

• Eine Spezifikation wiederverwenden heißt, einen Entwurf für eine Arbeitsweise zu teilen, zur Entwurfszeit. Sie machen Ihre eigene Variante, und es gibt keinen gemeinsamen Case.
• Eine Case-Rolle teilen heißt, eine abgegrenzte Verantwortung zu teilen, während die Arbeit läuft. Sie handeln innerhalb vereinbarter Grenzen, in einem Case, der bei seinem Eigentümer bleibt. Mehr dazu unter Organisationsübergreifend arbeiten.

Offene Spezifikationen bedeuten keine offenen internen Abläufe. Vereinbarungen werden explizit und testbar; wie jede Seite ihren Teil erledigt, bleibt ihre eigene Sache.

Ein Standard wird üblicherweise entworfen, vereinbart und dann jahrelang angewendet. Eine offene Spezifikation bleibt Teil der Arbeit. Jeder Case kennt die Version der Spezifikation, unter der er läuft. Wenn Menschen melden, dass etwas nicht passt, oder dieselbe Ausnahme immer wieder auftritt, verweist dieses Signal auf den Case und damit auf die Version.

Von dort aus wird ein Änderungsantrag gestellt, eine neue Version gebaut und in der Entwicklungsumgebung ausprobiert, und nur was der oder die Prozessverantwortliche freigibt, wird zur nächsten Version. Neue Cases starten unter ihr; bereits laufende Cases behalten die Version, mit der sie begonnen haben, sodass sich niemandem die Arbeit unter den Füßen verändert.

Wenn mehrere Organisationen auf derselben Spezifikation aufbauen, muss jemand sie pflegen, vorgeschlagene Änderungen prüfen und entscheiden, wann eine neue Version bereit ist. Und Beteiligte auf unterschiedlichen Versionen müssen weiterarbeiten können, während eine neue eingeführt wird.

Diese Verantwortung könnte bei einer Organisation liegen, bei einem Branchenverband oder bei einer Gemeinschaft von Beteiligten. Unsere Richtung ist, gemeinsame Spezifikationen zu unterstützen, die Organisationen übernehmen, anpassen und verbessern können, ohne die Kontrolle über ihre eigene Variante oder ihre eigene Umsetzung aufzugeben.

Besitzen Sie Ihre Arbeitsweise. Teilen Sie, was Sie gelernt haben. Wählen Sie, wie sie umgesetzt wird. Das Erste läuft heute, das Zweite innerhalb von CaseFlows, das Dritte ist unsere Ambition.

Läuft heute

• Offene, lesbare Spezifikationen für Cases, Caseflows, Case-Rollen und Dienste, die die Runtime direkt ausführt.
• Jeder Case trägt die Version, unter der er läuft; eine neue Version gilt für neue Cases.
• Signale aus echten Cases, die zu Änderungsanträgen werden, in der Entwicklung erprobt und von den Prozessverantwortlichen freigegeben.
• Grenzvereinbarungen zwischen zwei Plattformen, die beide Seiten bestätigen, wobei jede Änderung eine neue Version ist.
• Spezifikationen, die innerhalb unserer eigenen Plattformen wiederverwendet und an jede einzelne angepasst werden.

Wohin wir gehen

• Die Bedeutung der Spezifikation eigenständig veröffentlicht, unabhängig von der CaseFlows-Runtime.
• Ein Ort, an dem Organisationen Spezifikationen veröffentlichen, die andere finden und übernehmen können.
• Spezifikationen, die eine Branche gemeinsam entwickelt und pflegt, in gemeinsamer Verantwortung.
• Eine zweite Runtime für dieselben offenen Formate.