API‑First, End‑to‑End und mobiles Offline: Inside ITSM Development bei Kontron AG in Wien mit Florian Fiby

Ein Blick hinter die Kulissen der Business Unit ITSM

In der Session „Florian Fiby, Teamlead ITSM Development bei Kontron AG“ haben wir bei DevJobs.at einen klaren, praxisnahen Blick auf ein Team erhalten, das moderne Service-Lösungen mit Pragmatismus, Ownership und sauberem Engineering verbindet. Der Schwerpunkt: maßgeschneiderte ITSM- und Field‑Service‑Lösungen, die sowohl im Frontend als auch in Mobile und Datenbank durchdacht umgesetzt werden – und dies mit einer Kultur, die API‑First, End‑to‑End‑Verantwortung und langfristige Kundenbeziehungen ins Zentrum stellt.

Florian Fiby beschreibt sein Team in der Business Unit ITSM am Standort Wien prägnant:

Was sofort ins Auge fällt: Die ITSM‑Entwicklung bei Kontron AG ist kein reines „Feature‑Factory“-Set‑up. Das Team verantwortet den gesamten Lebenszyklus – von der Anforderungsanalyse über die Umsetzung bis hin zu Tests, Betrieb und Wartung. Diese Breite verbindet sich mit einer Arbeitsweise, die auf klare Iterationen, Feedbackschleifen und stabile Schnittstellen ausgerichtet ist. Projekte werden national wie international umgesetzt – im DACH‑Bereich ebenso wie konzernintern.

Für Tech‑Talente, die Verantwortung übernehmen, Schnittstellen beherrschen und sich in Kundenanforderungen hineindenken wollen, bietet dieses Set‑up viel Gestaltungsspielraum und Sichtbarkeit. In den folgenden Abschnitten fassen wir die Kernaussagen zusammen – aus einer Employer‑Branding‑Perspektive, die zeigt, wie Teamstruktur, Kultur, Hiring und Technologie bei Kontron AG zusammenspielen.

Teamauftrag und Scope: ITSM und Field Service end‑to‑end gedacht

Die Business Unit ITSM der Kontron AG in Wien arbeitet an Lösungen, die im Kundeneinsatz tragen – und das über Jahre hinweg. Der Auftrag ist klar umrissen und doch breit in den Anforderungen:

• Maßgeschneiderte ITSM‑Lösungen für Kund:innen
• Lösungen im Field Service Management
• End‑to‑End‑Umsetzung: Frontend, Mobile, Datenbank
• Rollout bei Kund:innen national, international (DACH‑Bereich) und konzernintern

Die Kombination aus IT Service Management und Field Service Management fordert ein Engineering‑Mindset, das über Einzelmodule hinausdenkt. Gerade im Field Service ist Offline‑Fähigkeit zentral. Entsprechend betont Fiby die mobile Schiene:

Offline‑Szenarien stellen erhöhte Anforderungen an Datenmodellierung, Synchronisation und App‑Zustände. Wer hier baut, denkt zwangsläufig in robusten APIs, Konfliktlösungsstrategien und Testbarkeit unter unsteten Netzwerkbedingungen. Dass das Team diese Ebene konsequent mitdenkt, zeigt, wie nah die Entwicklung am realen Betriebserfolg der Kund:innen ausgerichtet ist.

Arbeitsweise: Agil, iterativ und kundentaktisch flexibel

Agilität ist nicht nur Etikett, sondern an konkrete Taktung und Rituale geknüpft. Fiby beschreibt einen Prozess, der sowohl teamintern als auch im Kundentakt funktioniert:

Dort, wo das Team die Taktung frei wählen kann, sind zweiwöchige Sprints gesetzt. Wo Kundenprozesse maßgeblich sind, wird auf monatliche Zyklen umgestellt – bewusst so, dass Abnahmen realistisch eingeplant sind. Diese Flexibilität ist ein starkes Signal an Entwickler:innen: Hier wird Agilität nicht dogmatisch verstanden, sondern als Rahmen, der die Zusammenarbeit mit Stakeholdern erleichtert.

Die Sprintstruktur folgt einem klaren Ablauf:

• Planungs‑Meeting zum Start des Sprints
• Tägliche Dailies
• Review‑Meeting mit Feedback von externen oder internen Kund:innen
• Ableitung von Verbesserungen und Planung der nächsten Arbeitspakete

Diese Feedbackschleifen sind essenziell, um Funktionalität frühzeitig zu validieren – gerade wenn Mobile, Frontend und Backend eng verknüpft sind. Auch die spätere Betriebsverantwortung des Teams profitiert von regelmäßiger Abnahme und gelebter Transparenz.

API‑First als Zusammenarbeitssignal: OpenAPI vor der Implementierung

Ein Merkmal, das sich wie ein roter Faden durch die Aussagen von Fiby zieht, ist die konsequente Schnittstellenorientierung. Statt „erst Code, dann Dokumentation“ setzt das Team auf API‑First:

Das ist mehr als nur Methodik – es ist ein Organisationsprinzip. Wer OpenAPI früh nutzt, investiert in klare Verträge zwischen Teams. Das entkoppelt Frontend‑ und Mobile‑Entwicklung von Backend‑Änderungen, schafft Testbarkeit (Mocking, Client‑Generierung) und reduziert Reibung im Sprint. Diese Disziplin zahlt sich insbesondere in Umgebungen aus, in denen mehrere Teams parallel liefern und Releases im Kundentakt stattfinden.

Für Entwickler:innen ist das attraktiv, weil:

• Verantwortungsbereiche klarer geschnitten sind
• die eigene Arbeit durch definierte Verträge belastbarer planbar wird
• die Qualität der Integrationspunkte steigt

Kurz: API‑First ist hier nicht Buzzword, sondern gelebte Praxis, die Cross‑Team‑Collaboration vereinfacht und die Gesamtqualität hebt.

Tech‑Stack und Plattformen: Bewusste Auswahl, die Breite ermöglicht

Fiby skizziert einen Stack, der moderne Entwicklungsmuster abbildet – ohne Tool‑Überfrachtung und mit klarem Bezug zur Produktanforderung:

• Python für die „DSM‑Lösungen“
• Frontend‑Module auf Angular‑Basis
• Mobile‑App mit Flutter
• Couchbase als „neues Quell‑Datenbank“ in der mobilen App
• Rollout auf OpenShift oder Kubernetes
• GitOps‑Pipelines zur automatisierten Ausrollung von Entwicklungs‑ und Test‑Releases
• Freie Wahl der Arbeitsumgebung: Windows‑Laptop, Linux‑Laptop oder MacBook

Die Kombination ist stimmig: Python als robuste Backend‑Basis, Angular für modulare Frontends, Flutter für performante, plattformübergreifende Mobile‑Apps – ergänzt um Couchbase, um Offline‑Szenarien in der App sauber zu unterfüttern. Container‑basierte Deployments mit OpenShift oder Kubernetes und GitOps‑Pipelines runden das Bild ab: Continuous Delivery wird zum Standard, Umgebungen werden reproduzierbar, und Test‑Releases lassen sich zuverlässig ausrollen.

Ein weiterer Pluspunkt aus Sicht zukünftiger Teammitglieder: Die freie Wahl des Betriebssystems. Das vermeidet unnötige Reibung und erlaubt Entwickler:innen, in der Umgebung zu arbeiten, in der sie am produktivsten sind.

Ownership, Qualität und Betrieb: End‑to‑End ist Standard

Ein zentrales Signal an Kandidat:innen ist die klare Erwartung von End‑to‑End‑Verantwortung. Fiby formuliert es eindeutig:

Das Team übernimmt nicht nur die initiale Umsetzung; Kontron AG betreut die Kund:innen „über mehrere Jahre hinweg“. Dieses Langfrist‑Commitment prägt Designentscheidungen. Wer weiß, dass er/sie den Betrieb mit verantwortet, entwickelt wartbarer, beobachtbarer und resilienter – ein Reifegrad, den viele Entwickler:innen aktiv suchen, der aber eine passende Teamkultur braucht.

Bemerkenswert ist außerdem der Umgang mit Erfahrungsstufen:

Das ist gelebtes Lernen im Projektkontext: Juniors wachsen an Real‑World‑Problemen, Seniors teilen Wissen im direkten Doing. In Summe entsteht eine Lernkurve, die Neugier belohnt und Verantwortung fördert.

Hiring: Schnell, dialogorientiert und mit Teamfokus

Das Recruiting‑Vorgehen ist transparent und zügig – ein wichtiger Faktor für Kandidat:innen:

Das Erstgespräch findet online statt und ist als beidseitiges Kennenlernen gedacht. Teilnehmen tun „immer einer von der HR und entweder ich oder mein Chef“. Ziel: grundlegende fachliche Kenntnisse abklopfen, Einblick in die Arbeit geben und das gegenseitige Interesse prüfen.

Verläuft das positiv, folgt ein Zweitgespräch im Büro „am Start Nordwien“. Der Fokus liegt dann deutlich auf dem Teamfit:

Die Botschaft ist klar: Fachliche Grundlagen sind wichtig – doch entscheidend sind Zusammenarbeit, Kommunikationsfähigkeit und die Bereitschaft zu lernen:

Dieses Mindset passt zum End‑to‑End‑Anspruch und zu den kundennahen Iterationen. Wer Freude an dialogorientierter Arbeit hat und gern Verantwortung übernimmt, findet hier das passende Umfeld.

Was Bewerber:innen konkret erwartet

Aus den Aussagen lassen sich klare Erwartungen ableiten, ohne in Buzzwords zu verfallen:

• Grundlagen sitzen: solide Basiskompetenzen in relevanten Technologien
• Lernbereitschaft: neue Themen eigenständig und im Tandem mit Seniors erschließen
• Kundennähe: Interesse an fachlichen Anforderungen, nicht nur an Technologie
• Ownership: von Anforderung über Tests bis hin zu Betrieb/Wartung denken
• Teamfit: respektvolle, konstruktive Zusammenarbeit auf Augenhöhe

Dazu kommt die Freude an Schnittstellenarbeit: Wer API‑First schätzt und in OpenAPI‑Spezifikationen denkt, ist hier genau richtig.

Zusammenarbeit in der Praxis: Iterationen, Feedback, Schnittstellenklarheit

Die Kombination aus Sprint‑Ritualen, API‑First und GitOps prägt die alltägliche Zusammenarbeit. In der Praxis heißt das:

• Anforderungen werden so geschnitten, dass sie in Sprint‑Taktung passen und über Reviews validiert werden können.
• Schnittstellen sind vor der Implementierung klar – ein Schutz vor Missverständnissen in Frontend/Mobile/Backend‑Koordination.
• Feedback von Kund:innen wird regelmäßig eingeholt und bewusst in Verbesserungen übersetzt.
• Ausrollungen von Entwicklungs‑ und Test‑Releases werden automatisiert – das macht Qualitätsarbeit sichtbarer und zuverlässiger.

Dieser Arbeitsmodus stärkt sowohl die Delivery‑Geschwindigkeit als auch die Produktqualität – und gibt Entwickler:innen das Werkzeugset, um Entscheidungen transparent und datenbasiert zu treffen.

Warum dieses Team für Tech‑Talente spannend ist

Aus Employer‑Branding‑Perspektive kristallisieren sich mehrere Gründe heraus, warum Entwickler:innen hier wirksam werden können:

• End‑to‑End‑Verantwortung: Wer Wirkung über den gesamten Lebenszyklus sucht, findet sie hier – inklusive Betrieb und Wartung.
• Klare API‑Kultur: OpenAPI vor Implementierung schafft Qualität, Planbarkeit und reibungsarme Teamarbeit.
• Moderner Stack mit Purpose: Python, Angular, Flutter, Couchbase, Container‑Orchestrierung und GitOps – sinnvoll auf die Produkte zugeschnitten.
• Mobile Offline als Engineering‑Challenge: Anspruchsvolle Anwendungsfälle, die robuste Architekturen und Tests erfordern.
• Kundennahe Iteration: Regelmäßige Reviews mit externen und internen Kund:innen erhöhen Relevanz und Lernkurven.
• Lernumfeld über Erfahrungsstufen hinweg: Juniors bauen Lösungen gemeinsam mit Seniors – Learning by Doing im echten Projekt.
• Arbeitsumgebung nach Wahl: Windows, Linux oder macOS – produktives Arbeiten statt Tool‑Dogma.
• Zügiger, transparenter Hiring‑Prozess: Schnelles Feedback und echter Teamfokus im Zweitgespräch.

Unser Fazit aus „Florian Fiby, Teamlead ITSM Development bei Kontron AG“

Die Kontron AG zeigt in ihrer Business Unit ITSM in Wien ein Engineering‑Setup, das moderne Praxis mit Bodenhaftung verbindet. Agilität wird konsequent gelebt – inklusive Anpassung an Kundentakte. API‑First und OpenAPI‑Spezifikationen sind Standard, nicht Ausnahme. Der Stack ist bewusst gewählt und unterstützt die Produktanforderungen, insbesondere für mobile Offline‑Szenarien. Und das Team übernimmt Verantwortung über den gesamten Lebenszyklus, mit klarer Haltung zu Qualität und Betrieb.

Für Talente, die nicht nur Code abliefern, sondern Produkte nachhaltig tragen wollen, ist dieses Umfeld attraktiv. Oder, wie es Florian Fiby zusammenfasst: Entscheidend sind die Menschen, ihre Bereitschaft zu lernen und die Fähigkeit, sich in die fachlichen Anforderungen hineinzudenken. Wer das mitbringt, findet hier ein Arbeitsumfeld, in dem Zusammenarbeit, Ownership und Technik sinnvoll ineinandergreifen.

In Summe ist dieses Team ein Beispiel dafür, wie man mit klarem Engineering‑Kompass, API‑Disziplin und echter End‑to‑End‑Verantwortung Lösungen baut, die im Feld bestehen – und Entwickler:innen die Bühne geben, ihr Können breit einzusetzen und kontinuierlich zu erweitern.

• 

  

  Sascha Leber, Mobile App Developer bei Kontron AG

  Sascha Leber von Kontron AG gibt im Interview einen Überblick über seinen Weg bis zur aktuellen Arbeit im Mobile App Development, was das spannend in diesem Feld ist und teilt Tipps für Neueinsteiger ins Programmieren.

  Jetzt ansehen