Teil 1: Mit DDD, Event Storming und ML Design Canvas zu mehr Produktverständnis

Ging es in Teil 1 von „Innovation on Steroids” um die Innovationskraft von Machine Learning und die Identifizierung von ML Use Cases, beschäftigen wir uns im zweiten Teil mit der Methodik, wie wir herausfinden, wo sich der Einsatz von ML/AI lohnt und wie wir danach strukturiert vorgehen.

Ein fundiertes „Business Understanding“ ist laut CRISP-ML(Q)-Verfahrensmodell die Voraussetzung für eine erfolgreiche Einführung von ML/AI. Denn um zu wissen, wo man ein ML-Task einsetzt, muss man den kompletten Workflow, die Prozesse sowie das Produkt verstehen. ML-Ziele sollten sich explizit an den Business-Problemen orientieren. Wie finden wir aber heraus, wo sich der Einsatz von ML/AI lohnt, und wie gehen wir danach strukturiert vor? In diesem Artikel beschreiben wir unsere Methode, um ML Use Cases mithilfe von Event Storming zu identifizieren und ML-Projekte mit Machine Learning Design Canvas zu strukturieren.

ML-Anwendungsfälle mit Event Storming identifizieren und mit Machine Learning Design Canvas strukturieren
ML-Anwendungsfälle mit Event Storming identifizieren und mit Machine Learning Design Canvas strukturieren

DDD: Task Decomposition für ML/AI

Domain-driven Design (DDD) hat in der letzten Zeit ein klares Momentum bekommen. DDD ist eine Sammlung von fortgeschrittenen Techniken, Mustern und Prinzipien, um die Komplexität von Software anzugehen. Prinzipiell geht es bei DDD um die Übersetzung von der Problemdomäne in die Softwarelösung. In diesem Bereich haben Entwickler am meisten Probleme. DDD-Techniken sind primär darauf ausgerichtet, ein Domänenmodell in den Vordergrund zu stellen, eine gemeinsame Sprache zwischen allen Stakeholdern und Entwicklern zu finden und somit ein Verständnis für die Prozesse oder die Software zu erzeugen. Dementsprechend nutzen wir DDD-Techniken, um ein Problem oder vielmehr einen Use Case für ML/AI zu identifizieren und dafür eine strukturierte Lösung zu entwickeln.

Die Komplexität eines Problems lässt sich verstehen, wenn man jede einzelne atomare Komponente versteht. Das ist das Konzept von DDD. Für die Zerlegung des kompletten Workflows in die konstituierende Domäne hat die DDD-Community „Knowledge Crunching”-Methoden ausgearbeitet: User Story Mapping, Event Storming, Model Exploration Whirlpool und Domain Storytelling. In diesem Artikel gehen wir detaillierter auf das Event Storming ein – eine aus unserer Erfahrung effektive und einfache Methode, um beliebige Prozesse zu sezieren und Subdomains zu identifizieren.

Eine wichtige Eigenschaft von „Knowledge Crunching“ ist, dass es kollaborative und visuelle Methoden sind. Auf diese Weise lässt sich ein komplexer Workflow in einer gemeinsamen Sprache - Ubiquitous Language - verstehen. Der ganze Prozess findet auf Whiteboards statt. Man arbeitet gemeinsam in einer Art Brainstorming-Format an verschiedenen Szenarien.

Ein tiefes Verständnis für die Prozesse sowie die Business Domains ist Voraussetzung, um die existierenden Probleme zu erkennen. Diese sogenannten „Pain Points” sind potenzielle Use-Cases für ML/AI-Technologien. Aber nicht alle Probleme sind für ML/AI gleich gut geeignet. Der nächste Schritt wäre, die Probleme zu untersuchen und diejenigen auszusortieren, die definitiv nicht mit ML/AI-Algorithmen lösbar sind. Die Liste mit den übriggebliebenen Problemen ist nun unser Use Case für ML und AI.

„Knowledge Crunching“-Methoden aus dem DDD nutzen, um ML/AI Use-Cases zu identifizieren
„Knowledge Crunching“-Methoden aus dem DDD nutzen, um ML/AI Use-Cases zu identifizieren

Die Integration von ML/AI-Technologien erfolgt nach dem Prinzip „One Use Case at a Time”. Das bedeutet, dass ein Team in der Einführungsphase nur an einem Use Case arbeitet. Nachdem die geeigneten Use Cases identifiziert wurden, müssen diese priorisiert werden. Erst dann wird ein Use Case mit der höchsten Priorität ausgewählt, um zunächst nur diesen Anwendungsfall mit ML/AI umzusetzen.

Die Priorisierung von Use Cases lässt sich mit der Kategorisierung von Subdomains koordinieren. Eine Subdomain repräsentiert ein logisches Domain Model oder eine Funktionalität und ist ein Teil der Business Domains. DDD Strategic Design definiert drei Kategorien von Subdomains in einem Projekt: Core, Supporting und Generic.

Core Subdomain

Die Core Subdomain, wie der Name schon sagt, repräsentiert den Kern des Geschäfts einer Organisation. Das sind Gebiete, in denen die Unternehmen versuchen, sich gegenüber ihren Konkurrenten zu profilieren. Die Funktionalität ist dementsprechend industrie- und unternehmensspezifisch. Dadurch, dass wir uns hier in einer business-relevant Sparte befinden, kann dsich ie Einführung von ML/AI-Technologien als kritisch erweisen. Daher sollten die ersten ML/AI-Projekte nicht in diesem Bereich geplant werden. Ein Beispiel könnte die Implementierung von Dynamic Landing Pages im E-Commerce sein, um die Interaktivität des Users zu steigern. Solche ML/AI-Projekte sind entscheidend für die Differenzierbarkeit und werden als In-House Entwicklung betrieben.

Supporting Subdomain

Eine Supporting Subdomain umfasst die Funktionalität zur Unterstützung der Core Subdomain. Verglichen mit der Core Subdomain ist sie zwar strategisch weniger relevant aber trotzdem entscheidend für den Erfolg der Core Subdomain. ML/AI-Lösungen werden für die typischen Bereiche vieler Industries wie HR, Marketing oder Sales eingesetzt. Die entsprechenden ML-Modelle können In-House entwickelt werden, lassen sich aber auch outsourcen. Mögliche Beispiele finden sich im Bereich Sentiment Analysis für die Unterstützung im Marketing - konkret bei der Meinungsermittlung. Ein Einsatz von digitalen Assistenten (Chatbots) ist eine populäre Lösung in vielen Bereichen. Solche ML/AI-Projekte sind zwar weniger komplex als die aus der Core Subdomain, setzen aber ein Team aus ML-Engineers und die notwendige Infrastruktur für die Operationalisierung von Machine Learning-Modellen voraus.

Generic Subdomain

Die Generic Subdomain ist eine notwendige, aber nicht kritische Funktionalität, die sich durch geringe Differenzierbarkeit auszeichnet. Diese Arten von Lösungen können mit bereits existierenden Softwareprodukten implementiert werden. Dieser Teil der Business-Domain ist gut für die ersten Schritte mit ML/AI geeignet. In diesem Bereich lassen sich sehr kleine Use Cases finden, um die ML/AI-Lösungen einzuführen. Ein Beispiel dafür wäre eine OCR (Optical Character Recognition) Implementierung, um Belege oder andere Dokumente in eine textuelle Form zu bringen. Man kann dafür existierende OCR Software verwenden. Das Ziel von solchen einfachen Projekten ist, mit den neuen Technologien in Berührung zu kommen und mit ML/AI warm zu werden. Ein anderer Vorteil ist, dass man die initiale Infrastruktur sowie CI/CD Prozesse für die nächste Phase vorbereitet hat.

Entsprechend der „AI Readiness”-Phasen – Tactical, Strategic und Transformational – ist es sinnvoll, für die Einführung von ML/AI-Technologien mit einfachen und nicht kritischen Use Cases zu starten. Solche Use Cases findet man immer in der Generic Subdomain. Mit der Zeit und gewonnener Erfahrung können die Problembereiche in Richtung Core Subdomains angegangen werden.

„Knowledge Crunching“-Methoden helfen uns also nicht nur, die für ML/AI geeigneten Use Cases zu identifizieren. Durch die Einordnung der Funktionalität in Core, Supporting und Generic Subdomains, lässt sich die Implementierung von ML/AI Use Cases zusätzlich priorisieren.

Einordnung der ML/KI-Anwendungsfälle in die Subdomäne-Kategorien
Einordnung der ML/KI-Anwendungsfälle in die Subdomäne-Kategorien

Nach jedem Projekt sollte man immer eine Retrospektive durchführen, um zu lernen, was gut lief und wie man sich verbessern kann. Mit jedem ML-Projekt sammelt man mehr Erfahrungen und die Komplexität der Use Cases kann steigen. DDD ist eine lohnende Investition, um eigene Workflows zu verstehen und die Innovation mit ML/AI voranzutreiben.

Event Storming

Um die Prozesse, Fachlichkeiten und Workflows in unseren Systemen oder Produkten zu verstehen, bietet sich eine Variante der „Knowledge Crunching“- Methode, der „Big Picture Event Storming”-Workshop an. Dabei entdeckt man Probleme und Möglichkeiten, diese Probleme mit Machine Learning zu lösen.

Grundsätzlich benötigt man für ein „Big Picture Event Storming“ eine Wand und Post-its in verschiedenen Farben. Diese Art von Workshops wurde primär als Präsenz-Format entwickelt, lässt sich aber als Online-Event durchführen. Entscheidend beim Event Storming ist, dass alle Perspektiven – Business, Technik und UX – durch die Teilnehmer abgedeckt sind. Mit anderen Worten: alle Stakeholder, sowohl Domain-Expert:innen als auch die Entwickelnden als Teilnehmende sind involviert.

Ein Event Storming besteht aus sieben Phasen:

Im Folgenden erklären wir an einem Beispiel aus unserem Projekt jede dieser Event Storming-Phasen. Im konkreten Projekt ging es um ein Reisekostenabrechnungssystem.

Kick Off

Die initiale Phase dient als kurze Einführung durch einen Facilitator für alle Beteiligten. Man erklärt den Ablauf, die Bedeutung der Farben von Post-its und die Aufgabe. In unserem Fall möchten wir die UX in unserer Software für Reisekostenabrechnung verbessern.

Chaotic Exploration

Die eigentliche Arbeit beginnt genau in dieser Phase. Die Teilnehmenden beschreiben Domain Events, die in dem System stattfinden. Das können Aktionen von Usern, Interaktionen externer Systeme oder Konsequenzen anderer Domain Events sein. Ein Beispiel: Ein User hat eine Rechnung hochgeladen oder ein Feld eingetragen. Man nutze dabei orangene Post-its. Das Eintragen von Events soll eine Zeitachse berücksichtigen. Wichtig dabei ist, dass die Domain Events immer eine Vergangenheitsform haben, um die Prozesse rückblickend zu betrachten.

Enforcing the Timeline

In der dritten Phase des Workshops werden alle Domain Events angeordnet. Dabei kann man verschiedene Strategien nutzen, um die Events zu gruppieren. Man identifiziert die wichtigsten Events - Pivotal Events. Die parallelen Abläufe werden durch Swimlanes abgetrennt. Falls zutreffend, werden Events mit Deadlines sortiert. Alternativ kann man die Domain Events in die Cluster („hot spots”) eingruppieren. In unserem Projekt tritt ein Pivotal Event ein, wenn das System den hochgeladenen Beleg erkannt hat.

People and Systems

Im nächsten Schritt werden weitere Elemente des Workflows eingetragen, und zwar User und externe Systeme, die mit der Software in Berührung kommen. Auf dem Board werden User mit gelben Post-its und die externen Systeme auf großen lila Post-its markiert.

Der Zwischenstand einer Event Storming-Session für das Reisekostenabrechnungssystem mit Pivotal Events, Swimlanes, Externen Systemen und People
Der Zwischenstand einer Event Storming-Session für das Reisekostenabrechnungssystem mit Pivotal Events, Swimlanes, Externen Systemen und People

Explicit Walkthrough

Nun ist auf unserem Board eine Struktur zu erkennen und in der fünften Phase wird diese Struktur weiter manifestiert. Das Ziel dabei ist, aus den gesammelten Domain Events, eine Story zu gestalten. Man versuche einen Workflow mit Events zu erstellen und dabei eine Story zu erzählen. Idealerweise lässt sich die Story auch in der umgekehrten Richtung erzählen. Alle Lücken sollten sofort geschlossen werden, indem man neue Domain Events erstellt oder einen Kommentar schreibt.

Problems and Opportunities

In Hinblick auf das Ziel, Machine Use Cases zu identifizieren, ist die sechste Phase des Big Picture Event Stormings entscheidend.

Um die „Pain Points” zu identifizieren, haben wir in unserem Projekt folgende Fragen beantwortet:

Eine Antwort von unseren Usern ist „Ich will mit dem System nicht interagieren” gewesen. Dies war für uns ein Indiz für ein Problem, wenn man zu viele Felder ausführen muss. Mit einem lila Post-it haben wir solche Stellen wie „Kategorie eingetragen” markiert.

Der Zwischenstand einer Event Storming-Session für das Reisekostenabrechnungssystem mit Pivotal Events, Swimlanes, Externen Systemen und People
Der Zwischenstand einer Event Storming-Session für das Reisekostenabrechnungssystem mit Pivotal Events, Swimlanes, Externen Systemen und People

Daraus haben wir eine Opportunity identifiziert, dass die Kategorien von Reisebelegen automatisch identifiziert werden. Auf diese Weise möchten wir die Produktivität unserer User steigern.

Pick Your Problem

Das ist die finale Phase vom „Big Picture Event Storming Workshop”. Nachdem man alle Probleme und Opportunities identifiziert hat, werden nur diejenigen Probleme und Opportunities durch Voting ausgewählt, die für ML prädestiniert sind. Die Priorisierung von Opportunities erfolgt nach der Subdomain Kategoriezugehörigkeit und der „AI Readiness”-Stufe. Wie wir bereits erwähnt haben, bearbeitet man die ML-Opportunities immer nach dem Prinzip „ein Use Case pro Team“.

ML Projekte mit ML Design Canvas strukturieren

Nachdem wir mit Big Picture Event Storming die ML-Opportunities identifiziert und priorisiert haben, möchten wir sowohl die Vision für das ML-System als auch die Implementierungsdetails des Systems konkretisieren. Das Ziel ist, die Umsetzung des ML-Projektes zu planen. Um das zu erreichen, gibt es ein weiteres Werkzeug, das Machine Learning Design Canvas, vorgeschlagen von Louis Dorard. Dieses Canvas strukturiert das ML-Projekt und hilft, die Anforderungen zur Implementierung des Projekts zu spezifizieren.

Zu Beginn identifizieren wir das Ziel, indem wir eine Frage beantworten: Was wollen wir für die Endbenutzer des Systems erreichen? Als Nächstes verbinden wir den Business Value mit der ML-Aufgabe.

Der zentrale Teil des Canvas ist die Value Proposition. Üblicherweise klärt man folgende Fragen: Welche Probleme versuchen wir zu lösen? Warum ist es wichtig? Wer sind User unseres Systems? Welchen Wert liefert das ML-Projekt für die User? Wie werden sie die Ergebnisse/Vorhersagen des ML-Systems verwenden?

Die verbleibenden Teile des Canvas sind in drei große Kategorien unterteilt:

Die Kategorie Learning ist dafür verantwortlich, festzulegen, wie das ML-Modell gelernt werden soll. Der Teil Prediction beschreibt, wie die Vorhersage durchgeführt wird. Die Kategorie Evaluierung enthält Methoden und Metriken für das ML-Modell und die Systemevaluierung.

Insgesamt ist das Machine Learning Canvas in zehn zusammengesetzte Blöcke gegliedert: Value Proposition, Data Sources, ML-Task, Features (Engineering), Offline Evaluation, Decisions, Making Predictions, Collecting Data, Building Models und Live Evaluation and Monitoring. Jeder dieser Blöcke konzentriert sich auf einen Aspekt der zukünftigen ML-Anwendung.

Machine Learning Design Canvas nach Louis Dorard
Machine Learning Design Canvas nach Louis Dorard

Value Proposition

Dies ist der entscheidende Block auf dem Canvas. Hier sollten wir drei wichtige Fragen beantworten:

Data Sources

Daten sind für das Training von ML-Modellen unerlässlich. In diesem Block klären wir alle verfügbaren und möglichen Datenquellen, die für das ML-Modell-Training zu verwenden sind. Als Beispiel könnten wir folgende Datenquellen in Betracht ziehen: Interne und externe Datenbanken, Data Marts, OLAP-Cubes, Datawarehouse, OLTP-Systeme, Hadoop-Cluster, REST-APIs zum Sammeln von Daten, Web-Scraping, die Ausgabe anderer (ML) Systeme, Open-Source-Datensätze.

ML-Task

Nachdem wir geklärt haben, welche Daten verfügbar sind, machen wir ein Brainstorming, wie man das Business Problem in Machine Learning-Fragen übersetzt. Hier sind einige Beispiele für Fragen, die man stellen kann:

Es gibt keine Richtlinien für die Übersetzung von einem Business Problem in die ML-Task. Eigene und die Erfahrung von anderen spielt eine entscheidende Rolle. Wichtig hier ist erstmal mit einfachen und interpretierbaren Modellen anzufangen, damit man die Ergebnisse der Prediction nachvollziehen kann.

Features (Engineering)

Da jeder ML-Algorithmus Eingabedaten in Form von Features erfordert, sollten wir klären, wie die Eingabedaten dargestellt werden sollen: D.h., wie extrahieren wir Features aus Rohdaten? Es ist sinnvoll, Domain-Experten einzubeziehen, um festzulegen, welche Daten und Aspekte für die jeweilige ML-Aufgabe am wichtigsten sind.

Impact Simulation

Vor jeder Implementierung des ML-Modell-Trainings müssten wir die Methoden und Metriken zur Evaluierung des Systems spezifizieren und einrichten. Folgende Fragen sollte man beantwortet haben:

Decisions

Nachdem man weiß, welches ML-Modell gebaut und getestet wird, kommen folgende Fragen auf: Wie werden Predictions verwendet, um Entscheidungen zu treffen? Wie interagieren User oder Systeme mit den Ergebnissen von ML-Inferenz? Zum Beispiel: Was passiert, wenn User eine Liste mit Produktempfehlungen erhalten? Was passiert, wenn die eingehende E-Mail als „Spam" klassifiziert wird? Solche Informationen sind auch notwendig, um später zu entscheiden, wie das Deployment des ML-Modells umgesetzt werden soll.

Making Predictions

Dieser Block enthält Informationen darüber, wann man eine Prediction über neue Eingaben durchführen soll. Zum Beispiel werden jedes Mal, wenn User die Anwendung öffnen, neue Predictions gemacht, z.B. Empfehlungen. Oder sollten neue Vorhersagen auf Anfrage oder in Real-Time erstellt werden?

Collecting Data

Um „Model Drift” zu vermeiden, müssen ML-Modelle immer wieder mit neuen Daten trainiert werden, um die Generalisierung auch für die neuen Daten zu gewährleisten. Daher muss man eine Dateninfrastruktur aufbauen, um die neue Daten zu sammeln. Weitere Fragen, die in diesem Block zu beantworten sind: Wie wird das Labeling für neue Daten durchgeführt? Brauchen wir Menschen dafür oder haben wir das automatisiert? Wie teuer ist es, neue Daten zu sammeln?

Building Models

Nach dem soeben beschriebenen „Collecting Data” geht es um die Frage, wann man das ML-Modell neu trainiert. Wie oft sollte man das Modell erneuern? Darüber hinaus sollten auch Fragen zur Hardware-Infrastruktur beantwortet werden, da das Training sehr ressourcen- und kostenintensiv werden kann.

Live Evaluation and Monitoring

Nach dem Deployment sollte das ML-Modell evaluiert werden. Hier muss man sowohl Modell- als auch Business-Metriken spezifizieren, die korrelieren sollten. Im Allgemeinen sollten die Metriken der S.M.A.R.T.-Methodik (Specific, Measurable, Achievable, Relevant, Time-bound) folgen. Folgende Fragen sind hier relevant: Wie misst man die Systemleistung? Kann man z.B. A/B-Tests nutzen? Wie bewertet man den Business Value? Kann man z.B. die Produktivität der User messen?

Zusammenfassung

Machine Learning und Artificial Intelligence sind mittlerweile ein großer Bestandteil unseres Lebens. Viele Unternehmen versuchen ihre Wettbewerbsfähigkeit durch die Einführung von innovativen Methoden wie ML und AI zu steigern. Die entscheidende Frage ist, wie nutzt man solche Technologien, wenn man ML und AI einführen möchte. Es gibt keine Instruktionen, wie man solche Technologien in Unternehmen einführt. Der Gesamtprozess der Innovation mit ML/AI umfasst die Use Case-Findung, Data Science Prozesse bis hin zum Deployment von ML-Modellen und Monitoring. Es ist ein sehr individueller und kein trivialer Prozess. In diesem Artikel haben wir eine Grundlage für dei ML Use Cases-Spezifizierung geschaffen und gezeigt, welche Probleme für Machine Learning geeignet sind, wann die Transition zu ML und AI stattfinden kann und mit welchen ML-Methoden man arbeiten kann. Darüber hinaus haben wir eine Methodik vorgestellt, um dies praktisch umzusetzen. Wir haben gezeigt, wie man mit „Knowledge Crunching”-Methoden aus dem DDD wie Big Picture Event Storming, die Prozesse, Fachlichkeiten und Workflows in unseren Systemen oder Produkten versteht. Das Ergebnis von solchen Workshops ist eine Liste an Problemen, die man mit Machine Learning-Methoden angehen kann. Darüber hinaus haben wir ein Framework für die Strukturierung von ML-Projekten vorgestellt - das Machine Learning Design Canvas.

Quellen

TAGS