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.