Ich schaue mir @NewtonProtocol an, und da ist eine Stelle, die mich die ganze Zeit irgendwie komisch vorkommt.

Eigentlich sollte der Teil eines Protokolls, der wirklich komplex ist, der Ausführungsablauf sein. In der gesamten Whitepaper ist aber das Wort „Policy“ ständig präsent. Von der Frage, wer es aufrufen darf, bis dazu, wann die Ausführung erlaubt ist, und welche Bedingungen erfüllt sein müssen, damit es weitergehen kann – in jedem Schritt kommt man fast nicht daran vorbei. Ich hatte ursprünglich vor, diesen Abschnitt einfach zu überspringen, weil es sich für mich eher wie Berechtigungsverwaltung oder wie ein Compliance-Design anfühlt. Wirklich untersuchenswert sei doch der nachfolgende Ausführungsablauf.

Irgendwann habe ich dann den gesamten Ausführungspfad noch einmal neu sortiert, ja sogar diese Abfolge Transaction Intent → Gateway → Policy Engine → Operator → Attestation komplett neu gezeichnet, und erst da habe ich gemerkt, dass ich anfangs auf den falschen Punkt geachtet habe.

Ich dachte immer, dass ein System vor allem eine einheitliche Ausführung braucht. Schließlich ist die Ausführung der Ort, an dem wirklich eine Transaktion stattfindet und sich der Status ändert. Daher sollten die größten Unterschiede zwischen Anwendungen auch aus der Ausführungslogik selbst kommen.

Und je weiter ich nach unten schaue, desto mehr habe ich das Gefühl, dass etwas nicht stimmt.

Das, was wirklich ständig wiederholt wird, scheint nicht die Ausführung zu sein, sondern diese ganze Kette an Entscheidungen vor der Ausführung.

Wer kann es aufrufen? Wann ist die Ausführung erlaubt? Welche Bedingungen müssen erfüllt sein? Diese Entscheidungen finden sich in praktisch jeder Anwendung. Früher wurden sie meist direkt in den Geschäftscode geschrieben, und für jede neue Anwendung musste man sie erneut implementieren. Mit zunehmender Komplexität der Systeme wird nicht die Transaktionslogik ständig kopiert, sondern diese immer umfangreicheren Regeln.

Erst an dieser Stelle verstehe ich wirklich, warum das Whitepaper immer wieder die Bedeutung des Policy Engine betont.

Nicht eine bestimmte Fähigkeit wird wirklich ausgegliedert, sondern der Entscheidungsprozess, auf den alle Anwendungen immer wieder stoßen. Transaction Intent dient dazu, auszudrücken „was ich tun möchte“, Gateway organisiert den Ablauf, Operator führt die Aufgaben aus, und die Policy Evaluation beantwortet letztlich eine andere Frage – nämlich warum diese Ausführung diesmal möglich ist.

Später habe ich das Whitepaper noch ein paar Mal durchgelesen und plötzlich erkannte ich ein Problem, über das ich vorher noch nie ernsthaft nachgedacht hatte.

Warum gehen wir immer selbstverständlich davon aus, dass die Regeln im Geschäft verankert sein sollten?

Wenn jede Anwendung ihre eigene Regelmenge pflegt, dann wird es mit zunehmender Komplexität der Asset-Typen, der regionalen Aufsichtsvorgaben und der institutionellen Berechtigungen tatsächlich immer schwieriger zu warten – nicht der Ausführungscode, sondern diese sich ständig verändernden Entscheidungen. Unterschiedliche Teams schreiben unterschiedliche Implementierungen; ähnliche Regeln werden wiederholt gewartet. Am Ende fragmentiert nicht das Geschäft selbst das Gesamtsystem, sondern die Regeln selbst.

Je weiter ich hierher schaue, desto mehr habe ich das Gefühl, $NEWT dass das, was wirklich refaktoriert werden soll, nicht der Ausführungsablauf ist.

Was es wirklich herausfordert, ist die alte Gewohnheit in Softwaresystemen, die viele Jahre lang Bestand hat: Warum müssen die Regeln immer zum Geschäft gehören?

Die Ausführung kann immer vielfältiger werden, weil sie für unterschiedliche Szenarien dient; aber die Regeln sollten immer einheitlicher werden, denn sie bestimmen, wie das gesamte System zusammenarbeitet. Zukünftig können verschiedene Anwendungen völlig unterschiedliche Ausführungsweisen haben, aber ob ein Transaction Intent gültig ist, ob Authorization erfüllt ist, ob Policy es erlaubt – diese Entscheidungen sollten nicht immer wieder neu im Zuge der Geschäftsentwicklung implementiert werden.

So finde ich inzwischen immer mehr, dass der Wert des Policy Engine vielleicht nicht darin liegt, Entwicklern beim Schreiben von Regeln zu helfen. Was er wirklich unabhängig macht, ist die gesamte Decision Layer des Systems.

Früher bestimmten die Geschäfte die Regeln, und#Newt eher wie der Versuch, dass die Regeln vor dem Geschäft existieren. Was wirklich standardisiert werden muss, ist vielleicht nie die Ausführung, sondern der Entscheidungsvorgang, der sich immer wieder vor der Ausführung befindet und bisher weitgehend ignoriert wurde.