Phase 1: Passt ML/AI?

Der Einstiegspunkt des Prozesses ist ein übergeordneter Softwareentwicklungsprozess. Hier stoßen die Beteiligten auf eine Fragestellung, von der sie vermuten, dass ML-/AI-Anwendungen einen Lösungsansatz liefern. Die zentralen Rollen in dieser Phase spielen der Data Domain Expert und der Data Scientist. Diese Experten müssen am Ende die Frage nach der passenden Technologie beantworten. Dazu beschäftigen sie sich eingehend mit der vorhandenen Datenbasis: Verfügbarkeit, Qualität, Herkunft, Konsistenz aber auch rechtliche Rahmenbedingungen der Nutzung sind ein Thema.

Je nach Ausgangssituation ergeben sich in dieser Phase unterschiedliche Folgeschritte [siehe Grafik AI-Entscheidungsbaum]. Sind Daten vorhanden? Falls ja, geht der Data Scientist der Frage nach, ob in dieser Datengrundlage die notwendigen Informationen für das Entwickeln der gewünschten Funktionalität stecken. Sind die Informationen vorhanden, folgt die Phase "Model Requirements". Ist der Data Scientist unsicher, geht das Projekt in die Phase Data Lake.

Gibt es keine Datengrundlage, entwickeln die Experten zunächst einen Ansatz für eine mögliche ML-/AI-Lösung. Auf dieser Basis beurteilen sie, ob ML/AI für die Aufgabestellung geeignet ist. Kommen die Beteiligten zu einem positiven Ergebnis, prüfen sie, ob die notwendigen Daten mit vertretbarem Aufwand beschafft werden können, beispielsweise durch das Messen von Maschinendaten. Ist dies nicht möglich, ist ML/AI nicht der geeignete Lösungsweg.

Diese intensive Analysephase am Anfang sorgt dafür, dass die Beteiligten nicht zu lange auf das falsche Pferd setzen: Falls die Datenlage sich für ML-/AI-Ansätze nicht eignet, erkennen sie dies direkt zu Beginn - und nicht erst, wenn bereits im großen Maßstab Ressourcen in das Projekt geflossen sind.

Phase 2: Data Lake

Ist das Team unsicher, ob die vorhandene Datenbasis für einen ML-/AI-Ansatz geeignet ist, analysiert sie diese eingehender in der Phase "Data Lake". Die zentrale Rolle übernimmt der Data Scientist, indem er die verfügbaren Daten überprüft und Gruppen oder Zusammenhänge analysiert. Der Data Scientist überarbeitet die Daten so, dass er mit den Domänenexperten auf dieser Basis über Nutzungsmöglichkeiten diskutieren kann. In wöchentlichen Meetings tauschen sich die Beteiligten über neue Erkenntnisse aus. Ihre Analyse dokumentieren sie im sogenannten Data Report.

Im Gegenzug dazu konkretisiert der Domain Expert die Anforderungen der geplanten Anwendung. Dafür bietet sich das Nutzen eines sogenannten Backlog an, das beispielsweise aus agilen Entwicklungsprozessen bekannt ist. Auf Grundlage des Data Reports und des Backlogs entscheidet das Team, ob die vorhandenen Daten sich für einen ML-/AI-Ansatz eignen.

Phase 3: Anforderungen

Kommen die Beteiligten - egal auf welchem Weg - zum Ergebnis, dass ML-/AI-Lösungen geeignet sind, kümmern sie sich in dieser Phase um die Details: Sie definieren die Anforderungen und definieren eine denkbare Architektur für die ML-/AI-Komponenten.

Auf den ersten Blick ähnelt diese Phase dem aus der Softwareentwicklung bekannten Requirements Engineering (RE). Der Fokus des klassischen RE liegt auf den gewünschten Funktionen und klammert technische Fragestellungen aus. Dies ist bei der Entwicklung datengetriebener Anwendungen anders: Die Beteiligten berücksichtigen technische Aspekte von vornherein. Denn die zu entwickelnden Komponenten müssen zur Architektur der übergeordneten Anwendung passen.

In dieser Phase nutzt das Team zwei Instrumente: die sogenannten Data Stories und Architecture Sketches. Mit Hilfe der Data Stories verknüpfen sie die Anforderungen der Anwendung mit den notwendigen Daten. Architecture Sketches dienen dazu, die Komponenten der ML-/AI-Architektur zu beschreiben.

Phase 4: Modellentwicklung

Nun sind die Beteiligten soweit, dass sie das erste Modell implementieren. Federführend in dieser Phase ist der Data Scientist. Gemeinsam mit den Teammitgliedern bewertet er Algorithmen, leitet Modelle ab oder erstellt Prototypen. In Abstimmung mit dem Data Domain Expert definiert er die notwendigen Datensätze (Data Exploration Set, Training Set, Test Set) und arbeitet an Eigenschaften und Labels (sogenanntes Feature Engineering). Ziel dieser Phase ist die prototypische Entwicklung eines Modells.

Von Bedeutung für die Modellentwicklung ist das Definieren von Tests. Die Verantwortlichen definieren Anforderungen, die die Anwendung erfüllen soll. Anschließend überprüfen sie das Erfüllen dieser Anforderungen durch geeignete Testfälle.

Die Phase endet, wenn sich das Projektteam auf ein Modell einigt.

Phase 5: Integration des Modells

Mit dieser Entwicklungsphase geht das Projekt auf die Zielgerade. Die Beteiligten konzentrieren sich darauf, das definierte Modell in die übergeordnete Anwendung zu integrieren und die endgültige Komponente zu erstellen. In der Verantwortung ist der Software Engineer. Während der Data Scientist die ML-/AI-bezogenen Aufgaben wie das Modelltraining abarbeitet, integriert der Software Engineer die Komponente in das Gesamtsystem. Gegebenenfalls ist es notwendig, dass er zu diesem Zweck das Modell neu aufsetzt. So kann es für ihn notwendig sein, Werkzeuge, die der übergeordneten Entwicklung entsprechen, beispielsweise mit passenden Programmiersprachen oder Schnittstellen, zu nutzen.

6. Phase Betrieb

Am Ende steht, so auch bei klassischen Softwareprojekten, der Übergang von der Entwicklung zum Betrieb. Aber auch hier unterscheiden sich die datengetriebenen Anwendungen von klassischen Lösungen. Falls die Anwendung im laufenden Betrieb auf Basis neuer Daten lernt - was typisch ist für ML-/AI-Anwendungen -, muss das Team dies überwachen. Verhält sich die Anwendung immer noch wie gewünscht? Hat die Weiterentwicklung Einfluss auf den Gesamtprozess? Sind die Entscheidungen verständlich? Bei Abweichungen greifen die Beteiligten ein und passen die Anwendung an.

EDDA ist ein Ansatz, der Projektverantwortlichen hilft, datengetriebene Anwendungen zu entwickeln. Dank dieses Vorgehensmodells erkennen die Beteiligten frühzeitig, ob ML-/AI-Technologien die richtige Wahl sind. Sie verstehen, welches Fachwissen in welcher Projektphase gefragt ist und wie sie die Zusammenarbeit mit übergeordneten Softwareprojekten reibungslos koordinieren.

Dieser Artikel beschreibt nur die grundlegenden Zusammenhänge. In der nächsten Zeit werden einzelne Aspekte wie das Thema Data Lake, das Rollenkonzept oder die Schnittstellen mit dem klassischen Software-Engineering-Prozess weiter ausgearbeitet.