Vom Labor zur Cloud: Dominik Steininger (Bosch-Gruppe Österreich) über DevOps, Qualität und Feedback-Loops in Data-Science-Teams

Ein Quereinstieg mit System: Was wir aus „Dominik Steininger, DevOps Engineer bei Bosch“ mitnehmen

Wir bei DevJobs.at haben die Session „Dominik Steininger, DevOps Engineer bei Bosch“ mit Speaker Dominik Steininger von der Bosch-Gruppe Österreich aufmerksam verfolgt. Was sofort auffällt: Sein Weg in die Technologie ist alles andere als linear – und gerade darin liegt die Stärke seiner Geschichte. Vom Studium der Molekularbiologie über die Bioinformatik in die Welt von Linux, Bash und Webentwicklung hin zu einem DevOps-Fokus in einem interdisziplinären Data-Science-Team: Steininger zeigt, dass Neugier, strukturiertes Denken und die Lust auf Automatisierung Türen öffnen.

Seine Botschaft ist durchgängig praxisnah: Qualität entsteht nicht am Ende, sondern von Anfang an im Produkt. Feedback-Schleifen sind kein „Nice-to-have“, sondern die Grundlage für Verbesserungen. Und: Ein formales Studium ist hilfreich, aber nicht zwingend – wichtiger ist der Wille, Technik wirklich verstehen zu wollen.

Vom Kellerrechner zur Produktverantwortung

Steiningers Einstieg in die Technik beginnt – wie bei vielen – früh und spielerisch: Ein Rechner im Keller, Ausprobieren, Computerspiele. Aus diesem Erkunden erwächst Substanz: Erste Schritte mit Linux und Bash, die Neugier, Prozesse zu verstehen und zu beeinflussen. Über die Spiele kommt er in Kontakt mit Server- und Netzwerktechnik; unter dem Eindruck der .com-Zeit folgt der nächste Schritt: Webentwicklung mit HTML und PHP. Parallel erweitert er sein Fundament an der Universität, erst mit C++ und Java, heute arbeitet er hauptsächlich mit Python.

Diese Stationen beschreiben nicht nur ein Skill-Set, sondern ein Denken: Systeme ganzheitlich betrachten, von der lokalen Maschine bis zum Server, von der Analyse bis zur produktiven Bereitstellung. Dieses Denken trägt er heute als DevOps Engineer in ein Data-Science-Umfeld hinein.

DevOps als verbindendes Element in einem Data-Science-Team

Wie sieht ein interdisziplinäres Team im Bereich Data Science aus? Steininger beantwortet die Frage durch seinen eigenen Beitrag: Er übernimmt den DevOps-Part – mit dem klaren Ziel, das Team zu sensibilisieren, „ein Produkt von Anfang bis Ende“ zu denken. Gemeint ist der komplette Bogen von der Analyseentwicklung über den gesamten Entwicklungsprozess bis zum produktiven Betrieb.

Daraus leitet sich ein Handlungsprinzip ab, das sich durch die gesamte Session zieht:

• End-to-End-Denken ist Teamaufgabe, keine Rolle im Silo.
• Automatisierung ist kein Komfort, sondern eine Grundvoraussetzung.
• Qualität wird eingebaut („Quality built-in“), nicht am Ende geprüft.
• Feedback-Loops sind der Taktgeber für Verbesserungen.

Diese Punkte greift Steininger immer wieder auf – nicht als Buzzwords, sondern als praktische Leitlinien für die tägliche Arbeit.

„Quality built-in“: Qualität in den Fluss einweben

Einer der stärksten Akzente der Session liegt auf dem Thema Qualität. Steininger spricht davon, „Qualitätskontrollen einzubauen“, die Qualität also „built-in“ ins Produkt zu bringen. Der entscheidende Effekt: Fehler wandern nicht nach hinten, sondern werden früh sichtbar.

Was bedeutet das operativ? Aus seinen Hinweisen lassen sich mehrere Prinzipien ableiten:

• Qualität ist eine Eigenschaft der Architektur: Wer den Durchgang vom Prototyp zur Produktion mitdenkt, plant Kontrollpunkte ein – nicht erst am Release-Tag, sondern vom ersten Commit an.
• Automatisierung verringert Wiederholungsfehler: Repetitive Schritte werden entfernt oder verschlankt, damit nicht jedes Mal von Hand dieselben Risiken entstehen.
• „Früh scheitern“ statt „spät überraschen“: Kontrollmechanismen im Vorfeld reduzieren das Risiko, dass Probleme erst in der Produktion auftreten.

Bemerkenswert ist, wie nüchtern diese Haltung ist: Keine Tool-Schlacht, keine Checklisten-Prosa – vielmehr die klare Forderung, Qualität als integralen Bestandteil der Entwicklung zu verankern.

Monitoring und Alerting: Der Feedback-Loop als Motor der Verbesserung

Steininger verankert das Thema Qualität in einem Zyklus. Monitoring und Alerting sind für ihn keine Nebenaufgaben, sondern der Mechanismus, der dem Team schnelle Rückmeldungen gibt.

Entscheidend ist der Anschluss an die nächste Iteration: Ein Ereignis löst nicht nur einen Alarm aus; es führt zu einer Anpassung im Produkt, die ähnliche Probleme künftig abfängt. Das ist gelebtes Lernen im System:

• Sichtbarkeit: Probleme müssen für alle sichtbar sein – besonders für diejenigen, die Änderungen umsetzen.
• Reaktionsfähigkeit: Alarmierung ist so effektiv wie die Zeit bis zur Reaktion.
• Iteration: Jede Störung wird zum Input für die nächste Version.

Dieser Kreislauf zeigt die Essenz von DevOps in Steiningers Lesart: Er ist nicht nur Brücke zwischen Entwicklung und Betrieb, sondern ein Lernsystem, das in kurzen Zyklen Erkenntnisse in Robustheit übersetzt.

Cloud und Tooling: Wandel als Normalzustand

Wenn Steininger über Technologie spricht, ist ein roter Faden unübersehbar: Veränderung. Er beschreibt „Cloud-Geschichten“, unterschiedliche Cloud-Systeme und immer neue Produkte, die den gesamten Zyklus vom Start der Produktplanung über die Entwicklung bis zum Deployment unterstützen.

Unser Eindruck: Für ihn ist dieser Wandel kein Störfaktor, sondern Rahmenbedingung. Daraus ergibt sich ein Leitgedanke für Teams:

• Konzeption vor konkretem Tool: Wer die Prinzipien beherrscht – End-to-End-Denken, Automatisierung, Qualität, Feedback –, kann neue Werkzeuge schneller und gezielter einsetzen.
• Modularität: Ein sauberer Prozess lässt sich auf verschiedenen Infrastrukturen ausrollen.
• Lernbereitschaft als Teamkompetenz: Der Stack ändert sich; der Anspruch an konsistente Qualität bleibt.

Steininger benennt keine Einzeltools – und das passt zu seiner Haltung. Wichtiger als die konkrete Auswahl ist die Fähigkeit, neue Optionen am Prinzipienraster zu messen: Unterstützt ein Tool den Feedback-Loop? Fördert es Automatisierung? Macht es Qualität früher sichtbar?

Karrierepfad ohne Dogma: Warum ein Studium nicht zwingend ist

Vielleicht der ermutigendste Teil seiner Story: Ein formales Studium ist hilfreich, aber nicht Voraussetzung für eine Karriere in diesem Feld. Steininger formuliert das klar:

Er nennt die Faktoren, die wirklich tragen:

• Interesse an Technologie und Konzepten
• Freude am Verbessern von Workflows und Produkten
• Der Wille, repetitive Schritte zu entfernen oder zu automatisieren
• Der Anspruch, Qualität früh und bewusst sicherzustellen

Wer diese Haltung mitbringt, findet Anschluss – und kann, so Steininger, intern weiterlernen. Dass „man natürlich nicht alles wissen“ kann, ist Teil der Realität; entscheidend sind die nächsten Schritte und wie man sie strukturiert.

Lernen als Prozess: „Man kann natürlich nicht alles wissen“

Fortbildung ist keine einmalige Maßnahme, sondern ein kontinuierlicher Teil der Arbeit. Steininger verweist auf „viele Möglichkeiten zur Weiterbildung auch intern“. Für uns steckt in dieser Aussage ein doppelter Hinweis:

• Lernen ist organisiert: Teams schaffen Räume und Angebote, damit Wissen wächst.
• Lernen ist zielgerichtet: Es orientiert sich an den nächsten Schritten des Produkts – dort, wo Automatisierung, Monitoring oder Produktdenken das größte Delta versprechen.

Auch hier gilt: Werkzeuge dürfen wechseln, Prinzipien bleiben. Wer die Grundkonzepte versteht, kommt schneller in die Anwendung.

Ein Blick zurück: Von Molekularbiologie zu DevOps – konsequenter, als es klingt

Der Wechsel von Molekularbiologie und Bioinformatik in die Welt des DevOps wirkt auf den ersten Blick groß. Doch Steiningers Weg zeigt: Es ist eine Bewegung entlang eines roten Fadens – Strukturen erkennen, Abläufe optimieren, Daten und Systeme so miteinander verknüpfen, dass verlässliche Ergebnisse entstehen.

Die Stationen – Linux und Bash, Server- und Netzwerktechnik, Webentwicklung mit HTML und PHP, später C++ und Java, heute vor allem Python – markieren dabei nicht nur Skills, sondern Meilensteine im Verständnis: Wie interagieren Komponenten? Wo entstehen Reibungen? Welche Schritte lassen sich automatisieren? Wie wird aus einer Idee ein produktives System?

Handlungsempfehlungen für Entwicklerinnen und Entwickler: Aus Prinzipien Praxis machen

Aus Steiningers Impulsen lassen sich konkrete Schritte ableiten, die sowohl für Einsteiger als auch für Erfahrene relevant sind.

1) End-to-End-Denken trainieren

• Ziele klären: Wo soll eine Analyse am Ende laufen? Welche Nutzerinnen und Nutzer, welche Bedingungen, welche Risiken?
• Den Pfad skizzieren: Von der ersten Analyse bis zum Betrieb – welche Übergaben, welche Prüfpunkte, welche Automatisierungen?
• Ownership verteilen: Alle Beteiligten sehen das Gesamtbild und wissen, wo ihr Beitrag verankert ist.

2) Qualität früh sichtbar machen

• Kontrollpunkte definieren: Welche Eigenschaften gelten als „qualitätskritisch“ – und wie werden sie geprüft?
• Tests automatisieren, wo möglich: Wiederholbare Aufgaben nicht manuell belassen.
• Regression vermeiden: Aus Vorfällen Regeln ableiten und im Prozess verankern.

3) Feedback-Loops ernst nehmen

• Monitoring als Produktbestandteil planen: Was messen wir, wie alarmieren wir, wer reagiert?
• Alarm-Routinen klarziehen: Wer erfährt was, wann, in welcher Form?
• Lernen sichern: Jede Störung führt zu einer Anpassung, die künftige Vorfälle abfängt.

4) Toolwandel gelassen begegnen

• Prinzipien festigen: Automatisierung, Qualität, Feedback – diese Konstanten sind die Basis.
• Neues am Nutzen messen: Hilft ein Tool, die oben genannten Konstanten zu stärken?
• Modular arbeiten: Prozesse so bauen, dass ein Wechsel der Infrastruktur möglich bleibt.

5) Lernen planen, nicht vertagen

• Nächste Schritte definieren: Welches Konzept bringt jetzt den größten Hebel?
• Internes Wissen nutzen: Austausch im Team, Lernpfade, kollegiale Reviews.
• Realistisch bleiben: „Man kann nicht alles wissen“ – Fokus und Priorität sind Teil des Handwerks.

Für Quereinsteiger: Der Weg beginnt mit Neugier

Steiningers Biografie ist eine Einladung an Quereinsteigerinnen und Quereinsteiger. Der Schlüssel ist keine magische Abkürzung, sondern eine konsequente Haltung:

• Neugier vor Spezialisierung: Erst verstehen, wie Dinge funktionieren; später vertiefen.
• Kleine Systeme, große Lerneffekte: Ein eigener Server, ein einfacher Analyse-Workflow, eine Mini-Deployment-Strecke – Lernen passiert im Tun.
• Sprachen als Zugang: Wer wie Steininger von C++/Java heute bei Python gelandet ist, erkennt: Sprachen sind Werkzeuge. Wichtig ist, was man damit macht.

Diese Fragen sind der Kompass. Wer sie ernst nimmt, wird Fortschritt eher am Verstehen als an Titeln messen – und genau das ist die Grundlage für nachhaltige Entwicklungspraxis.

DevOps in Data Science: Besonderheiten des Zusammenspiels

Ein Data-Science-Team hat spezifische Anforderungen: Analysen werden entwickelt, Modelle und Auswertungen entstehen, Ergebnisse müssen reproduzierbar und belastbar sein. Steiningers Rolle macht deutlich, wie DevOps hier Mehrwert schafft:

• Von Analyse zu Betrieb: Der Transfer ist Teil der Aufgabe, nicht der „späte Sprint“ vor dem Go-Live.
• Reproduzierbarkeit durch Automatisierung: Das, was einmal funktioniert, soll nachvollziehbar und wiederholbar funktionieren.
• Qualität als Risikomanagement: Früh prüfen, statt spät kompensieren.

Auch hier ist der Feedback-Loop zentral: Monitoring und Alerting schlagen die Brücke zwischen Analyse und Betrieb. So wird das Team nicht nur schneller, sondern robuster.

Kultur vor Checkliste: Sensibilisieren statt verordnen

Steininger spricht davon, „das ganze Team zu sensibilisieren“. Das ist mehr als eine Richtlinie; es ist ein kultureller Auftrag. Sensibilisieren heißt:

• gemeinsam dasselbe Zielbild verfolgen;
• Verständnis für Auswirkungen entwickeln (was bedeutet eine Änderung im Betrieb?);
• Verantwortung teilen – Qualität ist Teamleistung.

Solche Kulturarbeit beginnt mit Haltung und Sprache. Wer Feedback-Loops ernst nimmt und Qualität ins Produkt einwebt, stärkt Vertrauen im Team und gegenüber Stakeholdern.

Warum dieser Ansatz resilient ist

Weil er auf wenige, robuste Grundsätze setzt:

• Ganzheitliches Denken schützt vor Silos.
• Automatisierung schützt vor Wiederholungsfehlern.
• Frühzeitige Qualität schützt vor späten Überraschungen.
• Feedback schützt vor Stillstand.

Diese vier Schutzmechanismen sind Steiningers Leitplanken – unabhängig davon, ob die Infrastruktur on-premise oder in der Cloud liegt, ob neue Produkte kommen oder alte verschwinden.

Zitate, die hängen bleiben

Einige Originalpassagen fassen seine Haltung prägnant zusammen:

Diese Sätze sind mehr als Stichworte – sie sind eine Agenda für Teams, die Data-Science-Resultate zuverlässig in die Produktion bringen wollen.

Konkrete nächste Schritte für Teams

Wer aus der Session unmittelbare Aktionen ableiten möchte, kann mit drei Initiativen starten:

1) Laufende Analysen kartieren: Welche Schritte führen von der Exploration zur Produktion? Wo fehlen Kontrollpunkte? Wo wird manuell wiederholt?

2) Monitoring-Plan schreiben: Welche Signale sind kritisch? Wie werden sie erfasst? Wer bekommt welche Alerts?

3) Automatisierbare Schritte identifizieren: Welche wiederkehrenden Tätigkeiten lassen sich am zuverlässigsten und schlichtesten automatisieren?

Diese drei Maßnahmen führen direkt in die von Steininger beschriebenen Prinzipien – ohne einen Werkzeugwechsel vorauszusetzen.

Fazit: „Kein Hexenwerk“ – aber ein klarer Anspruch

Die Session „Dominik Steininger, DevOps Engineer bei Bosch“ mit Speaker Dominik Steininger (Bosch-Gruppe Österreich) ist ein Plädoyer für solides Handwerk im besten Sinne. Der Weg vom Kellerrechner zur DevOps-Rolle in einem Data-Science-Team zeigt: Neugier, Systemdenken und der Wille zur Automatisierung sind stärkere Prädiktoren für Erfolg als ein lückenloser CV.

Was bleibt, ist ein prägnanter Katalog an Haltungen:

• Produkte von Anfang bis Ende denken.
• Qualität in den Prozess einweben.
• Monitoring und Alerting als Pflichtbestandteil behandeln.
• Lernen organisieren und akzeptieren, dass niemand alles weiß.
• Wandel in der Cloud- und Tool-Landschaft gelassen annehmen.

Wer diese Haltungen übernimmt, wird – ganz im Sinne von Steiningers Worten – feststellen: Es ist kein Hexenwerk. Aber es ist ernsthafte, befriedigende Ingenieursarbeit, die aus Analysen verlässliche Produkte macht.

• 

  

  Why you shouldn't build a microservice architecture

  Michael Eisenbart von Bosch stellt in seinem devjobs.at TechTalk die Vor- und Nachteile einer Microservice Architektur gegenüber – mit dem Hintergedanken, stets die Dinge etwas kritisch zu beleuchten.

  Jetzt ansehen

• 

  

  Michael Eisenbart, Senior Manager bei Bosch

  Der Senior Manager bei Bosch Michael Eisenbart fasst im Interview die wesentlichen Eckpunkte der Teamorgansiation, des Recruitings und der Dev-Technologien zusammen – und warum Gitlab Profile wichtig sind.

  Jetzt ansehen
• 

  

  Jürgen Webersinke, Gruppenleiter Softwareapplikation bei Bosch

  Gruppenleiter Softwareapplikation bei Bosch Jürgen Webersinke spricht im Interview über den Aufbau des Teams, wie das Recruiting und Onboarding abläuft und wie mit den technologischen Challenges umgegangen wird.

  Jetzt ansehen
• 

  

  Florian Berg, Digital Leader bei Bosch

  Digital Leader bei Bosch Florian Berg gibt im Interview einen Überblick über die Teamorganisation, den Ablauf des Recruitings und die eingesetzten Technologien.

  Jetzt ansehen

• 

  

  Jasmin Grabenschweiger, Data Scientist bei Bosch

  Data Scientist bei Bosch Jasmin Grabenschweiger spricht im Interview über ihren Werdegang und gibt Tipps für Neueinsteiger und Einblicke in den Data Science Alltag mit Beispielen.

  Jetzt ansehen
• 

  

  Liam Rafael, Data Engineer bei Bosch

  Liam Rafael von Bosch spricht im Interview von seinen ersten Berührungspunkten mit dem Programmieren bis hin zur aktuellen Arbeit als Data Engineer und gibt Tipps für Neueinsteiger.

  Jetzt ansehen
• 

  

  Melika Parpinchi, Data Scientist bei Bosch

  Melika Parpinchi von Bosch erzählt im Interview über ihren ursprünglichen Zugang zum Programmieren, das Besondere an ihrer aktuellen Arbeit bei Bosch und was ihrer Meinung nach wichtig für Anfänger ist.

  Jetzt ansehen