Dr. David Saive über die agile Methode und das „compliant programming“

Dr. David Saive


hat in Hamburg Rechtswissenschaften mit dem Schwerpunkt „Maritimes Recht“ studiert. Nach seinem Examen war er zunächst wissenschaftlicher Mitarbeiter bei der auf das Seerecht spezialisierten Kanzlei „Dr. Schackow & Partner“ in Bremen, bevor an die Universität Oldenburg an den Lehrstuhl von Prof. Dr. Prof. h.c. Jürgen Taeger wechselte.

Dort befasst er sich im Rahmen des vom BMWi geförderten Forschungsprojekts HAPTIK (haptik.io) mit der Digitalisierung von Seefrachtdokumenten mittels Blockchain-Technologie. Seine Kolleg:innen im Team und er stehen im ständigen Dialog und Austausch über Recht und Technik. Die Arbeit im Projekt brachte ihn auf die Idee des „compliant programming“, also die Umsetzung rechtskonformer Software.

Daneben publiziert er zu allen Rechtsfragen der Blockchain, insbesondere im maritimen Sektor und präsentiert seine Forschungsergebnisse auf Konferenzen und Fachtagungen.

IT und Rechtsblog: David, Für viele Juristen scheint die agile Methode noch ein Fremdwort zu sein. Wir sind es ja gewohnt, entweder als Kautelarjuristen vor dem Start eines IT-Projekts Hilfestellung zu leisten oder eben dann, wenn das Kind in den Brunnen gefallen ist. Du hast hierzu den Begriff „compliant programming“ geprägt. Was hat es hiermit auf sich?

David Saive: Der Begriff entstand im Rahmen des Projekts HAPTIK (https://haptik.io) an unserer Universität als unmittelbare Antwort auf herkömmliche Entwicklungsmethoden. Wir setzen im Rahmen des Forschungsprojekts eine blockchainbasierte Plattform zur Digitalisierung von Seefrachtdokumenten um. Dabei kamen wir sehr schnell zu der Erkenntnis, dass es gerade nicht ausreichend ist, nur die Funktionalitäten der papiergestützten Dokumente zu digitalisieren. Vielmehr gilt es, auch die rechtlichen Anforderungen zu berücksichtigen – denn was illegal ist, darf schlicht und ergreifend nicht eingesetzt werden, unabhängig davon wie gut die Technologie funktioniert!

In herkömmlichen Entwicklungsprojekten war es bisher so, dass zunächst ein Prototyp entwickelt wurde und dieser erst nach Fertigstellung der Rechtsabteilung oder externen Rechtsberater:innen zur Prüfung vorgelegt wurden. Was dann in den meisten Fällen passierte, könnt Ihr Euch sicher vorstellen: Die Jurist:innen sind mit der Umsetzung nicht zufrieden – eine zweite Iteration ist notwendig. Im besten Fall sind die rechtlichen Anforderungen dann umgesetzt. Im Schlechtesten Fall müssen die Entwickler:innen von Neuem beginnen. Der Zeit- und Kostenaufwand dafür ist immens.

„Compliant programming“ versucht, die juristischen Anforderungen bereits im Vorhinein zu berücksichtigen. So entsteht ein Prototyp, der von Anfang an den rechtlichen Vorgaben entspricht. Das agile Entwicklungsumfeld ermöglicht es den Jurist:innen, ad hoc und flexibel auf den Entwicklungsfortschritt zu reagieren und die rechtlichen Anforderungen entsprechend neu zu kommunizieren.

Durch „compliant programming“ werden Jurist:innen zu Übersetzern. Sie müssen die juristischen Anforderungen so formulieren, dass sie von den Entwickler:innen verstanden und umgesetzt werden können.

IT und Rechtsblog: Weg vom Shareholder-Prinzip zum Stakeholder-Prinzip! Product Owner, Scrum Master oder ab ins Entwicklungsteam? Wo gehört unser Jurist hin?

David Saive: Durch „compliant programming“ werden Jurist:innen zu Übersetzern. Sie müssen die juristischen Anforderungen so formulieren, dass sie von den Entwickler:innen verstanden und umgesetzt werden können. Dafür eignet sich die Stellung des Product Owner besonders. So haben die Jurist:innen den notwendigen Überblick über das gesamte Projekt, schreiben User-Stories und stehen im stetigen Austausch mit dem Entwicklungsteam.

Doch auch als Teil des Entwicklungsteams kann der juristische Sachverstand sehr gut eingebunden werden. Wir wollen jedoch keine festen Vorgaben machen, sondern Anregungen geben, herkömmliche Methoden zu durchbrechen. Wir wollen ein Bewusstsein dafür schaffen, dass Softwareentwicklung ohne Jurist:innen nicht mehr möglich ist.

IT und Rechtsblog: Der Informatiker schlägt die Hände über dem Kopf zusammen. Ein Jurist im Entwicklungsteam oder gar als Scrum Master. Wieso ist das deiner Meinung nach so wichtig?

David Saive: Nehmen wir Art. 25 DSGVO, das berühmte „privacy by design.“ Wie sollen wir die Anforderungen sinnvoll umsetzen können, ohne einen Austausch zwischen Entwickler:innen und Jurist:innen zu haben? Das ist schlicht nicht möglich. 

Das erfordert jedoch ein Umdenken in der gesamten rechtsberatenden Branche. Wir müssen uns davon lösen, „nur“ Problembewusstsein zu haben. Ein Umstand, der sicherlich unserer Ausbildung geschuldet ist – aber das ist ein anderes Thema. Jurist:innen müssen die Probleme nicht nur finden und Risiken aufzeigen, nein, sie müssen Lösungen bereitstellen, neue Wege aufzeigen und Alternativen vorschlagen. Dann wird die Zusammenarbeit mit uns weniger frustrierend – für alle Beteiligten. Jurist:innen als Ermöglicher, nicht als Bremser des technologischen Fortschritts, das ist das Credo!

IT und Rechtsblog: In diesem Zusammenhang sprichst du oft vom fehlenden Domänenwissen bei den Juristen. Hat der Jurist der Zukunft sich vermehrt mit informatischen Wissen auseinanderzusetzen?

David Saive: Unbedingt! Das kann man nicht oft genug betonen. Damit wir überhaupt sinnvolle Vorschläge machen können, müssen wir doch den technischen Sachverhalt überhaupt verstehen. Sonst geht es nicht. Das bedeutet aber nicht, dass wir gleich Programmieren in das Curriculum aufnehmen müssen. Nein – es genügt schon, offen für Neues zu sein und den Entwickler:innen einfach mal zuzuhören.

Beim interdisziplinären Arbeiten prallen Welten aufeinander. Wenn aber beide Seiten dazu bereit sind, ihren Gegenübern ihre Denkweise zu erklären, haben wir am Ende eine Menge gewonnen. Damit ändert sich aber nicht nur das Berufsbild der Jurist:innen, sondern auch der Entwickler:innen. Sie müssen genauso Übersetzer der Technologie für uns analoge Jurist:innen sein.

Vielen Dank für das Gespräch, David.