Sechs Tipps für den Schnell-Start ins Blockchain-Projekt

Die Stärke von Blockchain-Technologien liegt im dezentralen Konsens. Sie haben das Potenzial, Datenbanken oder andere Legacy-Anwendungen in den Fällen abzulösen, in denen Vertragspartner einander vertrauen müssen oder Dritte als neutrale Vermittlerinstanz etablieren – und dafür bezahlen. Das ist beispielsweise bei IT-Lösungen für Lieferketten der Fall; viele etablierte Konzerne testen derzeit Ideen für Geschäftsmodelle etwa im Energiemarkt oder im Versicherungsmarkt auf technische Machbarkeit sowie Kunden-Akzeptanz.

Schnelligkeit ist hier entscheidend: Wer jetzt den ersten funktionierenden Prototypen an die Kunden bringt, setzt Standards für die eigene Branche.

Doch wie startet man schnell mit der Blockchain-Entwicklung? Wie baut man gute Prototypen mit Distributed-Ledger-Technologien (DLT) effizient? Wir haben sechs Tipps für ein erfolgreiches Blockchain-Protoyp-Projekt:

• gemeinsames Verständnis entwickeln
• Use Case trägt
• Technologiefrage sinnvoll beantworten
• Machbare Lösungen Schritt für Schritt umsetzen
• „Prototyping“ verinnerlichen
• Technologie-Stack: schnell ans Laufen kommen

Welche Blockchain ist gemeint?

Was ist eigentlich Blockchain und wann setzt man Distributed-Ledger-Technologien (DLT) ein? Allein darüber kann man schon sehr lange diskutieren. Oft wird aneinander vorbei gesprochen. Daher sollte man vorher unbedingt sicherstellen, dass das Team die gleiche Sprache spricht und ein gemeinsames Verständnis von Blockchain teilt. Ist das nicht der Fall, diskutiert man mögliche Anwendungsfälle unterschiedlich, oder sucht in verschiedenen Lösungsräumen nach möglichen Anwendungsfällen.

Was wir sehr oft sehen: Blockchain wird als Zahlungsmethode gesehen, Anwendungsfälle werden dann im Umfeld von „Payment“ gesucht. Das ist nur ein kleiner Anwendungsbereich von DLT.

Wie komme ich jetzt am schnellsten zu einem gemeinsamen Verständnis über DLT? Dazu gibt es unsererseits den Blockchain Disruption Workshop. Hier wird Blockchain für Nicht-Techniker interaktiv erklärt.

Gute Vorbereitung beim Use Case ist die halbe Miete

Ideen scheitern nicht nur an organisatorischen oder technologischen Hürden; häufig genug eignet sich ein Use Case nicht als Prototyp.

Unser erster Schritt ist es deswegen, mögliche Use Cases auf ihre Tauglichkeit abzuklopfen. Entwickeln Sie eine Fragestellung, die für ihre Branche oder ihr Unternehmen relevant ist: Als produzierendes Unternehmen könnten Sie sich beispielsweise auf die Supply Chain fokussieren. Sammeln und bewerten Sie nun Ideen, und das am besten nicht im stillen IT-Kämmerlein. Laden Sie zum Beispiel Kolleginnen und Kollegen aus der Fachabteilung, der Partnerbetreuung und aus der Materialentwicklung zum Ideen-Workshop ein. Denn nur dann erfahren Sie möglicherweise, dass ein bestimmter Rohstoff zertifiziert ist – und damit teuer im Beschaffungsaufwand. Lassen Sie alle Ideen am besten gleich durch die Teilnehmer bewerten. So bekommen Sie schnell Feedback von Fachexperten, ob eine Idee ein echtes Problem löst; diese Fokussierung hilft Ihnen, einen tragfähigen Use Case zu finden. Wir haben das kollaborative Ideensammeln und -bewerten übrigens in einem interaktiven und moderierten Workshop-Format als „Digital Venture Game“ zusammengefasst. Lassen Sie sich inspirieren.

Während der Technologieentscheidung kritisch bleiben

Im Überschwang der Technologiebegeisterung fällt schnell die Entscheidung, die Datenbank eines etablierten Systems durch eine DLT zu ersetzen. Dann folgt die Ernüchterung: Das System ist zu langsam, oder Zugriffsberechtigungen lassen sich nicht nur schwer abbilden. Spätestens jetzt haben Beteiligte gelernt, dass sich nicht jeder Use Case effizient mit DLT lösen lässt. Wir plädieren dafür, die Lernkurve auszulassen, und die Technologiefrage von Anfang an sinnvoll und ehrlich zu beantworten.

Denn Datenbanken sind einer Blockchain nach wie vor überlegen, wenn Skalierbarkeit, Datendurchsatz und Zugriffsberechtigungen für Datensätze eine Rolle spielen. DLT spielen ihre Vorteile in bei automatisierbaren Abläufen aus, wenn Markt- oder Transaktionsteilnehmer einander vertrauen müssen oder ein hoher Anspruch an die Manipulationssicherheit der Daten besteht, und gleichzeitig Geschwindigkeit wenig Priorität hat. Ein Use Case hat das Potenzial zum Fliegen, wenn sie diese Einschränkungen bei der Auswahl Ihres Kandidaten für den Prototypen beachten. Natürlich kann es Marketingmotivationen für einen Use Case geben. Wir wollen uns auf technologisch motivierte Anwendungsfälle konzentrieren.

Hilfreich ist es, sich am Ende der Suche nach einem Anwendungsfall noch einmal aktiv ins Bewusstsein zu holen: Welche Blockchain-Eigenschaften fordert der ausgewählte Anwendungsfall? Was macht gerade ihn zu einem guten Use Case für DLT? Eine einfache Checkliste hilft hierbei ungemein und schafft Nachvollziehbarkeit und Transparenz.

Stufenweise prototypen

DLT punkten im organisationsübergreifenden Zusammenspiel. Aber gerade da werden Projekte administrativ komplex und oft kompliziert: Die wesentliche Frage ist für uns: Lässt sich organisatorische Komplexität im Anwendungsfall reduzieren, ohne ihn technisch zu stark zu vereinfachen? Denn im Prototyp wollen wir ja Machbarkeit trotz technischer Komplexität beweisen.

Und: Wir wollen ein großes Problem nicht in einem Wurf lösen. Unser Ziel ist es, es geschickt zu zerlegen und dann schrittweise umsetzen. Das bedeutet, wir nehmen uns einzelne technische Fragestellungen vor und setzen diese mittels DLT um; oder wir suchen alternative Lösungsmöglichkeiten, wenn sich DLT als nicht nutzbar zeigt.

Prototyping heißt: schnell produktiv gehen, viel Feedback einholen und zügig iterieren

Für Blockchain-Prototypen brauchen wir das gleiche Mindset wie für andere Prototypen auch: Wir holen früh, viel und regelmäßig Feedback von Nutzern ab.

Frühes Feedback bedeutet zum Beispiel, schon die Idee für den Use Case mit Kunden oder Fachanwendern zu verproben. Dafür muss erst mal noch keine Zeile Code geschrieben werden - Prototypen aus Papier reichen vollkommen aus. Wenn wir an dieser Stelle offen für das Feedback bleiben, bekommen wir häufig Priorisierungen für Feature Requests und Ideen für die Weiterentwicklung. Viel Feedback meint, mehrere Menschen zu fragen, die im Idealfalls sogar verschiedene Experten-Level abdecken, oder verschiedene Anliegen an die Lösung haben könnten.

Da wir bei nicht wenigen Blockchain-Ideen Technologie und Geschäftsmodell parallel testen, ist regelmäßiges Feedback auf beiden Ebenen wesentlich! Für das Geschäftsmodell brauchen wir das Feedback der Nutzer, sei es in einer Fachabteilung für eine B-to-B-Integration; sei es durch Endkunden in B-to-C. Feedback zur Technologie bekommen wir beispielsweise durch Auswertung vorab definierter Kennzahlen, etwa zur Performance, oder regelmäßige Gespräche mit dem Anwendungsbetrieb über Probleme mit dem eingesetzten Technologie-Stack.

Und nicht vergessen: Wenn wir den ersten Durchstich produktiv geschaltet haben, geht es in die nächste Runde: Feedback einholen und zügig iterieren ist die Devise.

Schnell ins Programmieren einsteigen

Alle Vorbereitungen sind getroffen – jetzt geht’s ans Programmieren. Gerade bei volatilen und sich schnell entwickelnden Distributed-Ledger-Technologien ist es gar nicht so einfach, den richtigen Technologie-Stack zusammenzustellen. Oft braucht es viel Zeit und Aufwand, um das Basis-Setup einzurichten. Das muss nicht sein: Wir nutzen die Zeit im Prototyping-Stadium für den Beweis der technischen Machbarkeit. Um schnell ins Programmieren zu kommen, haben wir Ressourcen aus dem Ethereum-Universum zusammengefasst und als Docker-Container Open Source gestellt. Damit können wir eine private Test-Blockchain auf unserem eigenen Rechner installieren und starten., Sie kann echte Begebenheiten simulieren, Accounts befüllen und gibt uns einige Eckdaten als Visualisierung aus. Das Projekt heißt EDEN, kurz für Ethereum Development Environment + Network. Über Mit-Entwickler und neue Commits freuen wir uns genauso wie über Hinweise, wenn Ihnen etwas gefehlt hat.