Von der Web‑App zum MLOps‑Betrieb: Technische Erkenntnisse aus „Our Journey towards productionizing AI“ von Ciarán Baselmans (craftworks GmbH)

Worum es in der Session ging – und warum sie für Engineers relevant ist

In „Our Journey towards productionizing AI“ schildert Ciarán Baselmans, Product Owner und Softwareentwickler bei craftworks GmbH, wie aus einer klassischen Softwareagentur ein Team wurde, das industrielle KI‑Lösungen nicht nur erforscht, sondern auch zuverlässig in den Betrieb bringt. Der Vortrag ist bewusst nicht übermäßig technisch – und gerade deshalb für Engineering‑Teams wertvoll: Er legt offen, welche Entscheidungen, Tools und Arbeitsweisen in der Praxis darüber entscheiden, ob ein Machine‑Learning‑Projekt nach dem Proof of Concept (PoC) im Sande verläuft oder realen Geschäftsnutzen stiftet.

Wir fassen die zentralen Stationen, die verwendeten Technologien und die aus Engineering‑Sicht wichtigsten Lessons Learned zusammen – stringent entlang der Inhalte der Session und mit Fokus auf das, was wir als DevJobs.at‑Redaktion aus den Aussagen und Beispielen mitnehmen.

Der Ausgangspunkt: 2014, Werte, und der Sprung ins Softwaregeschäft

Ciarán verankert die Geschichte im Jahr 2014 – der Zeit des Ice‑Bucket‑Challenges und dem Ende eines beliebten Microsoft‑Betriebssystems. In Wien setzten sich damals Simon und Jakob, langjährige Freunde mit Informatik‑Background, zusammen. Ihre Erkenntnis nach „viel Überlegung und ein paar Bieren“: Die Leidenschaft für IT, Softwareentwicklung und Technologie spiegelte sich nicht in den Werten ihrer Arbeitgeber wider. Bürokratie bremste Kreativität, die Beziehung fühlte sich „rein transaktional“ an.

Die Konsequenz war der Start von Craftworks – zunächst als „klassisches“ Softwarehaus, mit einem klaren Ziel: „ein freundliches und professionelles Arbeitsumfeld von Entwicklern für Entwickler“ zu schaffen. In echter Start‑up‑Manier begann alles in einer Wohnung; das erste Kundenprojekt war ein Transport‑Management‑System (TMS) für Datenaustausch via APIs, Kundenverwaltung und Logistik.

Der Grundstack: Java, Spring Boot, Angular, PostgreSQL, Jenkins, Docker

Aus diesem ersten Projekt ergab sich ein Tech‑Stack, der bis heute die Basis der Softwareprojekte bildet:

• Backend: Java (heute Spring/Spring Boot)
• Frontend: Angular
• Datenbank: PostgreSQL
• CI/Pipelines: Jenkins
• Containerisierung: Docker

Die Nachfrage nach qualitativ hochwertigen Web‑ und Business‑Anwendungen wuchs, und damit das Team – inklusive Sales, Frontend‑ und später Backend‑Kolleg:innen. Diese Expansionsphase war mehr als Skalierung: Sie ließ das Unternehmen offen für Veränderungen werden.

Der nächste Schritt: Von klassischer Software zu Data Science und KI

Craftworks verstand Innovation und Exploration als Kernelemente. Mit wachsendem Erfahrungswissen in Machine Learning entstand eine Hypothese: Kund:innen könnten erheblich profitieren, wenn Prozesse nicht nur durch klassische Software, sondern zusätzlich mit KI/ML verbessert werden. Die logische Folge war der Aufbau eines Data‑Science‑Teams.

Der Data‑Science‑Stack: Python, Spark, Pandas, TensorFlow, PyTorch, MLflow

Für die neuen Projekte etablierte sich technologie‑seitig:

• Programmiersprache: Python
• Datenanalyse/-exploration: Apache Spark, Pandas
• Deep‑Learning‑Frameworks: TensorFlow, PyTorch
• Experiment‑Tracking und Packaging: MLflow

Industrielle Anwendungsfälle – konkrete Beispiele

Der Fokus liegt auf industriellen Use Cases:

• Visuelle Inspektion
• Predictive Maintenance
• Predictive Quality

Ein Beispiel für Predictive Quality: Das Team sagte das Gewicht von Kunststoffgranulat voraus, das durch einen Extruder läuft. Das Modell fungierte als „virtueller Sensor“ – es ersetzte keine Waage, sondern schätzte die Masse, um teure Industriewaagen in großflächigen Rollouts zu vermeiden.

Ein weiteres Beispiel knüpfte an das initiale TMS an: Anstatt mit vorgegebenen Ankunftszeiten zu planen, prognostizierte craftworks die Estimated Time of Arrival (ETA) selbst. Für Rail Cargo entstand so ein Modell zur ETA‑Vorhersage von Güterlieferungen. Ergebnis laut Ciarán: „Wir konnten die ETA mit 98% degree of confidence vorhersagen.“

Der Bruch zwischen PoC und Produktion: Warum 90% der Modelle nie live gehen

An dieser Stelle adressiert Ciarán ein weit verbreitetes Muster: Nach dem PoC passiert – nichts. Projekte schaffen es nicht in die produktive Nutzung. Das frustriert Data Scientists und verhindert echte ROI‑Effekte. Ciarán nennt hierzu eine Zahl: „In fact, 90% of machine learning models never make it into production.“

Aus der Session wird klar: Es mangelt nicht an Algorithmen oder Experimenten, sondern am Weg in den Betrieb. Genau dort setzt der Rest des Vortrags an.

Die fünf Hürden des „Productionizing AI“ – technisch eingeordnet

Ciarán strukturiert die Herausforderung entlang von fünf Themen. Für Engineering‑Teams sind die dahinterliegenden Implikationen entscheidend – wir ordnen sie entlang seiner Punkte ein.

1) Infrastruktur

Viele industrielle Kunden sind keine großen Softwareunternehmen. Häufig fehlen sowohl die technische Infrastruktur als auch die Menschen, um diese zu betreiben. Produktionstaugliche ML‑Dienste müssen hochverfügbar und robust laufen – vom Rechenzentrum bis zum Shopfloor. Daraus folgen unter anderem:

• Klar definierte Betriebsumgebungen (on‑premises, Cloud oder hybride Setups)
• Containerisierung als Standardbaustein (Ciarán verweist im Softwarestack auf Docker)
• Reproduzierbarkeit von Builds und Deployments (Jenkins taucht früh in der Craftworks‑Geschichte auf)

2) Access Management

Produktionsmodelle arbeiten mit sensiblen Daten. Das erfordert eine saubere Rechte‑ und Rollentrennung nach dem Least‑Privilege‑Prinzip – sowohl zur Datensicherheit als auch, um Fehlbedienungen mit weitreichenden Folgen zu verhindern. Praktisch heißt das:

• Genaue Rollenzuschneidung (Data Scientist, Domänenexpert:in, Betrieb)
• Isolierte Umgebungen für Modelle und Datenflüsse
• Auditierbarkeit von Zugriffen und Änderungen

3) Monitoring

Modelle in Produktion müssen überwacht werden – nicht nur auf Verfügbarkeit, sondern fachlich:

• Out‑of‑Distribution (OOD): Echte Eingangsdaten weichen von Trainingsdaten ab. Ursache kann z. B. ein defekter Sensor sein – klar erkennbar als Ausreißer – oder eine schleichende Veränderung.
• Data Drift: Daten verschieben sich über die Zeit; das Modell performt schlechter und braucht Retraining. Ciarán betont: „A model is only ever going to be as good as the data it’s trained on.“

Aus Engineering‑Sicht heißt das: Messgrößen für Daten‑ und Modellverhalten definieren, Alarmierung und Reaktionen planen, Retraining‑Prozesse vorbereiten.

4) Deployment

„It’s got to be as easy to deploy as possible.“ Die meisten ML‑Lösungen sind kundenspezifisch, eine One‑Size‑Fits‑All‑Schablone gibt es selten. Gleichzeitig sollen auch weniger tief technische Rollen Deployments anstoßen können. Konsequenz: Vereinheitlichte Verpackung von Modellen, automatisierte Ausrollprozesse und ein einfach zu bedienendes Interface.

5) Integration

Neue Modelle sollen sich in bestehende Systeme einfügen – mit deren Protokollen, Schnittstellen und Ein-/Ausgaben. Andernfalls drohen Insellösungen oder Re‑Implementierungen „pro Modell“. Integrationsfähigkeit ist das Nadelöhr, wenn Mehrwert in die Fläche gehen soll.

Die Antwort von craftworks: Navio als MLOps‑Plattform

Aus diesen Herausforderungen entstand „Navio“, eine „unified MLOps platform that simplifies the serving, monitoring, and management of machine learning models“. MLOps – die Verbindung aus Machine Learning und DevOps – zielt auf die betrieblichen Aspekte rund um KI.

Ciarán positioniert Navio als Brücke zwischen Experiment und produktivem Geschäftsnutzen. Was die Plattform laut Session ausmacht:

Kernprinzipien und Features

• One‑Click‑Deployment: „Sehr, sehr einfach“ Container hochfahren – mit UI für „alles“, damit auch nicht‑super‑technische Nutzer:innen ein Modell nach dem Training und Upload managen können.
• Skalierbarkeit: Rollout über viele Werkshallen bzw. Standorte.
• Einfachheit: Domänenexpert:innen sind nicht zwingend Tech‑Profis; das System muss selbsterklärend sein.
• Nutzerzentrierung und Betriebsmodelle: On‑premise oder in der Cloud. Außerdem besteht eine Partnerschaft mit TT Tech Industrial und deren „Nerf hardware devices“, um Modelle direkt am Shopfloor zu deployen – „dort, wo die Daten entstehen“.

Architekturfluss: Von Training zu Betrieb

Der Prozess, wie ihn Ciarán beschreibt:

1) Data Scientists trainieren ein Modell in ihren bevorzugten Frameworks.

2) Das Modell wird mit MLflow „gepackaged“ – so bleiben verschiedene Deep‑Learning‑Bibliotheken unterstützbar.

3) Upload nach Navio.

4) Domänenexpert:innen (oft auf Kundenseite) übernehmen das Management und Monitoring.

5) Integration von Navio aus in Drittanwendungen, Maschinen oder Mobilgeräte.

Aus Engineering‑Sicht sind zwei Punkte wesentlich: Standardisiertes Packaging (MLflow) als Entkopplungsschicht zwischen Training und Serving sowie eine Oberfläche, die Rollenwechsel ermöglicht – von der Experimentierumgebung der Data Scientists in den verantwortlichen Betrieb durch Fachexpert:innen.

Praxisnah weitergedacht: Was Engineers konkret anwenden können

Die Session bleibt nah an realen Projektbedingungen. Diese Punkte lassen sich direkt übertragen:

1) Standardisierung vor Automatisierung

Sinnvolle Automatisierung setzt ein gemeinsames Modell‑Artefakt voraus. MLflow dient hier als standardisierender Layer: Experimente tracken, Modelle konsistent paketieren, Artefakte eindeutig adressieren. Ohne einheitliches Packaging ist reproduzierbares Serving schwer.

2) Saubere Rollentrennung – mit bewusstem Interface‑Design

Ciarán betont die Zielgruppe jenseits der Data Scientists: Domänenexpert:innen an der Kundenschnittstelle. Das bedeutet für die Systemgestaltung:

• UI statt CLI, wenn Nicht‑Engineers Modelle bedienen
• „Least Privilege“ bereits in der Tool‑Architektur berücksichtigen
• Verantwortlichkeiten entlang des Modell‑Lebenszyklus trennen (Trainieren vs. Betreiben)

3) Monitoring als First‑Class‑Citizen

Ausfälle und Drift beginnen bei Daten – nicht erst beim REST‑Endpoint. OOD‑Erkennung und Drift‑Signale früh anlegen, klare Reaktionspfade definieren (wie Eskalation, Retraining, Rollback). Ohne diese Vorkehrungen gerät Produktion zur „Black Box“.

4) Infrastruktur passend zum Kontext wählen

Industrielle Kunden haben oft on‑premise‑Bedarfe, geringe Toleranz für Ausfälle und heterogene Anlagen. Die Session zeigt: Flexibilität (Cloud und on‑premise) erhöht Realisierbarkeit. Edge‑nahe Deployments – Ciarán verweist auf Shopfloor‑Geräte – reduzieren Latenz und Abhängigkeiten.

5) Integration als Kriterium Nummer eins

Ohne nahtlose Einbindung in bestehende Systeme verpufft Mehrwert. Bereits beim Design sollten Ein-/Ausgaben, Protokolle und Schnittstellen mitgedacht werden – sonst wiederholt man Integrationsaufwand pro Anwendungsfall.

Die Beispiele im Detail – was wir daraus lernen

ETA‑Vorhersage für den Güterverkehr

Das ETA‑Projekt illustriert, wie bestehende Software (TMS) durch ML erweitert wird. Anstatt externe Ankunftszeiten nur zu konsumieren, prognostiziert das System diese selbst – mit einem von Ciarán genannten Ergebnis von „98% degree of confidence“. Engineering‑Takeaway:

• ML ergänzt bestehende Prozesslogik – ersetzt sie nicht zwingend.
• Nutzen entsteht, wenn die Prognosen an der richtigen Stelle in die Planung zurückfließen.

Virtueller Sensor im Extruder

Die Vorhersage der Pelletmasse zeigt die Kostenperspektive: Ein ML‑Modell als „virtueller Sensor“ spart teure physische Sensorik und skaliert einfacher über viele Linien. Engineering‑Takeaway:

• Modelle als Softwaresensoren denken: aus vorhandenen Signalen Sekundärgrößen schätzen.
• Betriebssicherheit berücksichtigen: Ausreißererkennung (z. B. bei Sensordefekten) gehört von Anfang an dazu.

Warum PoCs oft liegenbleiben – und wie die Session den Gap adressiert

Ciarán beschreibt die Frustration, wenn PoCs nie den Weg in die Produktion finden. Seine Liste der Hürden (Infrastruktur, Access, Monitoring, Deployment, Integration) macht deutlich, dass der Engpass selten im Jupyter‑Notebook liegt. Entscheidend ist der Übergang in stabile Betriebsprozesse – und dort setzt Navio an: einheitliche Modellpakete, einfache Deployments, Rollenmodell, Skalierbarkeit.

Für uns als DevJobs.at‑Redaktion ist das die klare Botschaft der Session: Die Technik im Modell ist wichtig, aber die Technik um das Modell herum entscheidet darüber, ob Mehrwert in die Fläche kommt.

Arbeitskultur als Enabler: Wandel zulassen, Verantwortung ermöglichen

Ein roter Faden in Ciaráns Geschichte ist Kultur: Die Firma entstand aus dem Wunsch nach einem Umfeld, „in dem du und deine Arbeit geschätzt werden“ und „du die Freiheit hast zu wachsen und dich zu verändern“. Er selbst begann als Softwareentwickler und ist heute auch Product Owner für Navio. In technischen Organisationen ist diese Durchlässigkeit ein wichtiges Element, um neue Felder (hier: MLOps) ernsthaft aufzubauen.

Leitlinien für Teams, die ähnliche Wege gehen wollen

Auf Basis der Session formulieren wir verdichtete Leitlinien – ohne über die Inhalte hinauszugehen:

• Baue früh einen stabilen Grundstack auf (im Vortrag: Java/Spring Boot, Angular, PostgreSQL, Jenkins, Docker) und erweitere ihn bewusst um Data‑Science‑Komponenten (Python, Spark, Pandas, TensorFlow/PyTorch, MLflow).
• Etabliere MLflow oder einen gleichwertigen Mechanismus für konsistentes Modell‑Packaging – das entschärft Deployments und Integrationen.
• Richte Betriebsmodelle auf die Realität der Kund:innen aus: on‑premise, Cloud oder beides; Edge‑nahe Ausführung, wenn Daten vor Ort entstehen.
• Plane Rollen und Interfaces von Beginn an: Domänenexpert:innen sollen Modelle „verantwortlich“ bedienen können – sicher, nachvollziehbar, ohne Shell‑Magie.
• Nimm Monitoring ernst: OOD‑Erkennung, Drift‑Signale, Alarme und Retraining‑Wege gehören zum Produktionssystem wie Logging und Healthchecks.
• Optimiere für Integration: Wo fließen die Vorhersagen hin? Welche Systeme konsumieren sie? Welche Protokolle sind gesetzt?

Fazit: Produktion statt Prototyp – die Brücke, die zählt

„Our Journey towards productionizing AI“ zeigt, wie craftworks GmbH den Sprung von klassischen Web‑Anwendungen zu produktionsreifen KI‑Diensten vollzogen hat. Die technischen Bausteine sind bekannt – entscheidend ist ihre Orchestrierung zu einem verlässlichen MLOps‑Prozess. Navio bündelt dabei laut Ciarán die Praxisanforderungen: One‑Click‑Deployment, UI‑Fokus, Skalierbarkeit, flexible Betriebsmodelle und eine MLflow‑basierte Verpackung, die unterschiedliche Frameworks zusammenführt.

Der Vortrag endet mit einer Einladung: „Will you join us on this journey?“ Aus Engineering‑Perspektive nehmen wir mit: Der Weg in die Produktion ist eine Reise – mit klaren Hürden, aber auch mit praxiserprobten Mustern. Wer Infrastruktur, Zugriff, Monitoring, Deployment und Integration ernst nimmt, gibt KI‑Modellen eine echte Chance, über den PoC hinaus Wirkung zu entfalten.