EDDA - Ein Vorgehensmodell für datengetriebene Anwendungen

Im Begriff des Softwarebauens steckt viel von dem Selbstverständnis der IT-Experten. Sie bauen, ähnlich wie der Architekt ein Haus oder der Ingenieur eine Maschine, Software. Dafür greifen die Beteiligten auf seit Jahren oder Jahrzehnte etablierte Abläufe, Vorlagen und Techniken zurück. Die Kombination aus erprobten Standards und Erfahrung in der Projektorganisation sorgt für Zuverlässigkeit im Prozess. Auch Softwareprojekte laufen gelegentlich aus dem Ruder und überschreiten vorgegebene Budget- oder Zeitgrenzen. Im Extremfall führen sie gar nicht zum gewünschten Ergebnis. Aber das ist eher die Ausnahme als die Regel.

Aktuell ist in Unternehmen ein Umbruch zu erkennen: Machine-Learning (ML)- beziehungsweise Artificial-Intelligence (AI)-Technologien halten verstärkt Einzug in die IT-Landschaften. Allerorts initiieren Verantwortliche Projekte, um die neuen Möglichkeiten auszutesten. Ziel ist es häufig, Zusammenhänge in Daten zu erkennen oder große Datenmengen automatisch zu klassifizieren. Bei der Entwicklung solcher datengetriebener Anwendungen kommt es in der Praxis immer wieder zu Schwierigkeiten. Denn: Im Vergleich zu klassischen IT-Lösungen benötigen sie eine andere Projektstruktur und ein anderes Fachwissen der Beteiligten. Datengetriebene Anwendungen entstehen nicht auf magische Art und Weise von selbst. Sie sind das Ergebnis von sauber auf- und umgesetzten Projekten.

Der entscheidende Unterschied: Die Experten entwickeln auf der Grundlage vorhandener Daten. Um dabei erfolgreich zu sein, müssen die Beteiligten Verständnis für die zugrundeliegenden Daten, die Besonderheiten des eigenen Unternehmens und der eigenen Branche, Möglichkeiten der Analyse und darauf aufbauend des Entwickelns von Algorithmen mitbringen.

Hinter der Idee des "Engineering Process for Developing Data-Driven Application (EDDA)" verbirgt sich genau das: ein Vorgehensmodell mit Phasen, Rollen und Verantwortlichkeiten, das den Besonderheiten der Entwicklung gerecht wird.

Der Erfolg hängt an vier Rollen

In einem datengetriebenen Projekt haben vier Rollen entscheidende Bedeutung für die erfolgreiche Umsetzung. Der Begriff Rolle steht dabei für ein Set an Fähigkeiten und Verantwortlichkeiten, nicht für eine Person. So kann eine Person mehrere Rollen in einem Projekt einnehmen oder eine Rolle wird von mehreren Beteiligten ausgefüllt.

1. Domain Expert: Diese Rolle kennt die Geschäftsprozesse des Unternehmens, die Abläufe in der Branche und die Anforderungen der Anwender. Der Domain Expert ist bei Branchenspezifika genauso fit wie beim Bewerten von Anwendungsfällen.

2. Data Scientist: Mit dieser Rolle hält das ML-/AI-Fachwissen Einzug in das Projekt. Der Data Scientist kombiniert Fähigkeiten eines IT-Experten und eines Statistikers. Er ist firm im Umgang mit ML- und AI-Technologien, bringt Programmierkenntnisse mit und hat Erfahrung im Umgang mit großen Datenmengen.

3. Software Engineer: Er verantwortet das übergeordnete Software Engineering und stellt das Bindeglied zwischen dem datengetriebenen und dem klassischen Projekt da. Der Software Engineer ist Experte für Softwareentwicklung und bringt ein grundlegendes Verständnis für das Thema Data Science mit.

4. Data Domain Expert: Den Zugriff auf und das Wissen über Daten und Datenquellen innerhalb des Unternehmens und der Domäne liefert diese Rolle. Im Gegensatz zum Domain Experts, die aus der Perspektive des Geschäfts auf Daten blicken, bringt der Data Domain Expert eine eher technische Sichtweise mit.

Auf diesen vier Säulen steht die Entwicklung von datengetriebenen Anwendungen. Diese Rollen sorgen dafür, dass das Projektteam das nötige Fach-, IT- und AI-Wissen mitbringt. So ausgestattet machen sich die Beteiligten daran, AI-basierte Anwendungen zu entwickeln.

Ein festes Modell für ein flexibles Vorgehen

EDDA unterteilt den Entwicklungsprozess, abhängig von der vorhandenen Datengrundlage, in bis zu sechs Prozessschritte. Die lineare Abfolge dient zum einfachen Visualisieren und Beschreiben. In der Projektpraxis wählen Entwicklerteams nicht den gradlinigen, sondern den passenden Weg für ihr Projekt.

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.