Der Weg von einer Testinstallation oder einem PoC (Proof of Concept) hin zur produktiven Blockchainanwendung ist nicht trivial. Man bewegt sich auf einem relativ unbekannten Gebiet ohne ausgetretene Pfade. Es gibt eben nicht die 500 anderen Projekte und Dutzende Mitarbeiter, die sich in der Vergangenheit mit gleichen oder ähnlichen Fragen beschäftigt haben. Und Rückschlüsse aus öffentlichen Implementierungen wie Bitcoin oder Ethereum helfen im DLT-Bereich nur sehr bedingt weiter.

Dabei ist das Risiko, bereits mit einer Teststellung an fundamentalen Dingen zu scheitern, nicht gering. Möchte man neue Verfahren mit alternativen Paradigmen erproben (wie bei einer Blockchain), ist auf dem Weg nun einmal deutlich mehr Ungewissheit vorhanden, als beim PoC einer standardisierten Softwarelösung. Ein meiner Meinung nach häufig vernachlässigtes Problem ist es, falsche Schlüsse aus einer mangelhaften Teststellung zu ziehen. Mit einigen Projekten wurde primär bewiesen, dass auch eine gute Technologie nichts wert ist, wenn man sie falsch benutzt.

Ist es geplant, eine Blockchain auszuprobieren, stellen sich vier fundamental wichtige Fragen.

• Was soll fachlich in dem Test abgebildet werden, bzw. welche Erkenntnisse möchte man eigentlich gewinnen?
• Wer soll die Implementierung übernehmen?
• Welche Zeit will man sich geben und welche Kosten soll/darf das Experiment produzieren?
• Wie soll man den Use Case technisch und organisatorisch umsetzen?

Allein die erste Frage nach dem „Was“ ist gar nicht so einfach zu beantworten, weil es eben nicht trivial ist, eine gute fachliche Aufgabenstellung zu spezifizieren. Einen konkreten Anwendungsfall sollte es aber geben, denn ansonsten wird man nie über die Erkenntnis hinauskommen, dass Daten in eine Blockchain geschrieben werden können. Ich rate deshalb auf jeden Fall davon ab, eine Teststellung ohne gefestigte fachliche Basis zu starten.

Häufig werden auch Teststellungen installiert, deren Infrastruktur sehr überschaubar ist, sprich ein Knoten oder Miner im gesamten System. Um Informationen in einer Blockchain zu speichern, nur um sich einen ersten Eindruck oder ein Gefühl für die Technologie zu verschaffen, kann man sicherlich auch mit nur einem Knoten arbeiten. Es werden sich dann aber keinerlei sinnvollen technischen Erkenntnisse ableiten lassen (Betriebsaufwände, Systemverhalten bei Last, Mining- oder Replikationszeiten, etc.), die im DLT-Bereich jedoch wichtig sind. Man sollte sich dessen bewusst sein, wenn es darum geht, Schlüsse aus einem Test abzuleiten.

Ist man nicht in der Lage, eine sinnvolles fachliches Testziel zu definieren, sollten zwei Dinge ernsthaft in Betracht gezogen werden:

• A.) Das Vorhaben verwerfen, da es in diesem Fall wohl keinen nahe liegenden Mehrwert der Technologie für Ihr Unternehmen gibt.
• B.) Eine externe Fachkraft zurate ziehen, um Ihre Prozesse neutral zu betrachten. Vielleicht ist es so möglich, die Dinge zu identifizieren, die eventuell der Betriebsblindheit zum Opfer gefallen sind.

Ist das Ziel definiert, stellt sich die Frage, welche Personen intern die technische Implementierung umsetzen sollten. Grundlagen in den Theorien „verteilter Systeme“ sind in dem Kontext sicherlich kein Nachteil. Personen, die aus der relationalen Welt stammen und sich nicht vorstellen können, dezentrale Systeme zu implementieren, sind meist nicht die ideale Besetzung. Kollegen ohne diese Erfahrung sollten bereit sein, sich intensiv in „Distributed Technology“ einzuarbeiten und offen den alternativen Konzepten gegenüberstehen. Im Zweifel empfiehlt es sich auch hier, über externe Unterstützung nachzudenken. Es hilft nun einmal nicht ein verteiltes System zentral aufzusetzen, denn die vermeintlichen Erkenntnisse solch einer Installation besitzen keine sinnvolle Aussagekraft.

Haben Sie einen fachlichen Kontext und ein motiviertes Team, fehlen Ihnen noch der Zeitrahmen und die Budgetkalkulation. Sofern man ohne externen Support auskommt, ist das Budget meist relativ überschaubar, da der Sourcecode nahezu aller Blockchains als Open Source, also frei verfügbar, nutzbar ist. Bei der Kostenkalkulation sind nicht zu vergessen: Rechnerinstanzen (gegebenenfalls als Cloudservice), Storage und sonstige IT-Infrastruktur (datenlogistische Prozesse, Netzwerk, Load Balancer, etc.).

Bei der Zeitplanung fallen zwei Dinge ins Gewicht: Was ist technisch und was ist fachlich zu erledigen? Insbesondere, wenn es um konsortiale Lösungen geht, können sich Fragestellungen rund um die System-Governance schnell zu einem Albtraum entwickeln. Es ist deshalb dringend angeraten, dem Bereich entsprechend Zeit einzuräumen oder diesen Teil auszusparen. Man muss sich auf jeden Fall bewusst sein, dass aufgehoben nicht aufgeschoben ist. Wird ernsthaft in Erwägung gezogen, ein Produktionssystem zu installieren, holt Sie dieses Thema spätestens dann wieder ein. Sofern Sie sich im Rahmen Ihrer Evaluierung noch keinerlei Gedanken zu Fragen der Governance gemacht haben, schlummert definitiv ein Risiko in Ihrem Projekt.

Im letzten Schritt geht es an die technische Umsetzung des Vorhabens. Welche Technologie soll eingesetzt werden? Eine DLT-Version von Ethereum (zum Beispiel Quorum)? Multichain, Hyperledger Fabric oder R3 Corda? Es gibt viele Entwicklungsprojekte mit unterschiedlichen Schwerpunkten. Alle haben eines gemeinsam: Sie sind relativ neu. Einen Überblick zu behalten, ist nicht leicht, zumal der Teufel oft im Detail steckt. Es ist leider unmöglich, alle für einen individuellen PoC relevanten Aspekte bei der Auswahl zu berücksichtigen, ohne die Systeme genau zu analysieren. Und wenn bei einer Bewertung auf etwas kein Verlass ist, dann sind es die meisten Marketingunterlagen zu den Produkten. Da helfen schon eher Beiträge in den einschlägigen Foren oder ein Blick in das jeweilige GitHub (öffentliche Codeverwaltung). Ich möchte explizit bemerken, dass ein Blockchainprojekt nicht gut ist, nur weil es groß ist oder von Global Playern dominiert wird.

Endgültige Sicherheit bekommen Sie erst, wenn Sie sich für eine Lösung entschieden und diese ausprobiert haben. Sofern die Vorarbeiten hinsichtlich der geforderten Fachlichkeit gut waren, ergeben sich auch wertvolle Erkenntnisse bezüglich der eingesetzten Technologie. Der Markt ist schnelllebig. Deshalb macht es vielleicht Sinn, sich nicht nur mit einer, sondern mit zwei unterschiedlichen Ausprägungen einer Blockchain zu beschäftigen, um deren Vor- und Nachteile direkt vergleichen zu können.

_Hinweis: Dieser Beitrag wird auf der Deepshore-Homepage durch ein White Paper ergänzt, das sich mit der Konzeption einer produktiven DLT-Infrastruktur beschäftigt._

*DLT=Distributed Ledger Technology