MIC

Etablierte Firma

Alle Videos anzeigen

The MIC Tech Radar

Wolfgang Gassner von MIC zeigt in seinem devjobs.at TechTalk die Herangehensweise, wie im Unternehmen die riesige Zahl an verwendeten Technologien überschaubar gehandhabt werden.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In "The MIC Tech Radar" erläutert Wolfgang Gassner, wie MIC Technologieentscheidungen strikt an der Vision einer besten Cloud-Plattform für Global Customs & Trade Compliance ausrichtet und mit Tech-Strategie sowie internem Tech Radar transparent macht, wer was erkundet und was einsatzreif ist. Er beschreibt zwei Fünfjahresziele (bessere Produkte/Services und skalierte, beschleunigte Prozesse mit kürzerer Time-to-Market) sowie die Migration von On-Premise zu zentral betriebenen, cloud-nativen Multi-Tenant-Services auf Anbietern wie AKS und A1. Entscheidungen trifft ein funktionsübergreifendes Gremium statt allein das Management; daraus lassen sich Prinzipien für eigene Tech-Radars, klare Strategieanbindung und besseres Onboarding ableiten.

Transparenz, Cloud und Skalierung: Ein Blick in „The MIC Tech Radar“ mit Wolfgang Gassner

Warum MIC ein Tech Radar braucht

Als wir „The MIC Tech Radar“ mit Wolfgang Gassner (Director of Product Development) verfolgten, war die Ausgangslage sofort klar: In einer wachsenden Technologieorganisation mit rund 450 Mitarbeitenden laufen viele Evaluierungen, Prototypen und Initiativen parallel. Genau das schildert Gassner gleich zu Beginn – und er bringt das Kernproblem prägnant auf den Punkt: Für „normale“ Mitarbeitende ist es schwer, den Überblick zu behalten, wer woran arbeitet, was gerade erprobt wird und was bereits produktionsreif ist.

„Es ist wirklich schwer, nachzuvollziehen, was läuft, wer an welchen Themen arbeitet, was exploriert wird und was schon einsatzbereit ist.“

Dieses Orientierungsproblem ist kein reines Kommunikationsdetail. Es entscheidet darüber, ob Teams Synergien nutzen, Doppelarbeit vermeiden und strategisch in dieselbe Richtung laufen. MIC hat dafür eine Antwort gefunden: eine explizite Tech-Strategie und ein Tech Radar, die gemeinsam erklären, warum Dinge getan werden, wie Entscheidungen zustande kommen – und wie das alles zur Unternehmensvision passt.

Vision als Nordstern: Die „beste Cloud-Plattform“ für Zoll und Trade Compliance

Die Leitplanke ist bei MIC unmissverständlich:

„Wir wollen die beste Cloud-Plattform für Global Customs & Trade Compliance betreiben.“

Daraus folgt eine klare Konsequenz. „Cloud“ bedeutet: nicht on-premise. MIC verfolgt ein ambitioniertes Programm, alle On-Premise-Kund:innen in das SaaS-Angebot – die Cloud-Plattform – zu migrieren. Das ist ein technischer, organisatorischer und prozessualer Wandel. Und er spielt sich in einem Fachgebiet ab, in dem sich regulatorische Rahmenbedingungen regelmäßig ändern. Wer hier Software baut, muss beides beherrschen: die Dynamik der Cloud und die Dynamik der Regulatorik.

Zwei strategische Ziele mit Fünfjahreshorizont

Auf Basis dieser Vision formuliert MIC zwei strategische Ziele, die mindestens fünf Jahre tragen sollen.

1) Großartige Produkte und Services für überdurchschnittliches Wachstum

Kontinuierliche Erweiterung der Produkte um neue Funktionen, die Nutzenden helfen, ihre Arbeit besser zu erledigen.
Sicherstellung, dass die Produkte mit den wechselnden Vorgaben der Zollbehörden konform bleiben.
Neue Kund:innen gewinnen und bestehende Kund:innen begeistern.

2) Skalierung und Beschleunigung der Geschäftsprozesse

Software schneller und zuverlässiger zu den Nutzenden bringen.
Support stärken und Qualität erhöhen.
Die „Time-to-Market“ insgesamt reduzieren.

Gassner macht deutlich, dass MIC jede Aktivität, jedes Technologievorhaben und jeden Prototypen auf diese beiden Ziele und die Vision rückkoppelt. Für ein wachsendes Unternehmen ist das mehr als ein guter Vorsatz – es ist eine Notwendigkeit, um fokussiert zu bleiben.

Der organisatorische Hebel: Entscheidungen transparent machen

Inhaltlich deckt das Tech Radar die Technologielandschaft ab – Tools, Frameworks, Plattformen, Techniken. Organisatorisch hat MIC aber noch einen zweiten Hebel eingebaut: Entscheidungstransparenz. Dafür wurde ein Gremium etabliert, das Expertise bündelt und Entscheidungen gemeinsam trifft.

„Wir haben eine Gruppe von Menschen organisiert – Expert:innen für bestimmte Technologien oder Frameworks oder Programmiersprachen, Stakeholder in den Projekten, Support/Operations und natürlich ist das Management auch eingebunden.“

Wichtig ist Gassner die Botschaft, dass Entscheidungen nicht „von oben“ verordnet werden. Die Gruppe bringt Wissen zusammen, diskutiert, dokumentiert und trifft gemeinsame Entscheidungen. Das Tech Radar dient als Kommunikationsfläche: Es zeigt, was entschieden wurde, warum es entschieden wurde und wie es zur Vision passt.

Das erleichtert nicht nur die Zusammenarbeit. Es beschleunigt auch die Einarbeitung neuer Kolleg:innen: Wer neu startet, bekommt eine kuratierte Sicht auf Technologien, Entscheidungen und Ziele – und damit einen schnelleren Weg zur Wirksamkeit im Tagesgeschäft.

Tech-Strategie trifft Tech Radar: Was abgedeckt wird – und was nicht

Gassner betont, dass Tech-Strategie und Tech Radar einen Teil der Aktivitäten abdecken – die technologiebezogenen Themen rund um Tools, Frameworks, Plattformen und Techniken. Andere unternehmensrelevante Initiativen liegen daneben, werden aber mit einem eigenen Rahmenwerk gesteuert: einem OKR-basierten Ansatz, den MIC „MKR-MIC“ nennt. Dieses Zusammenspiel aus Tech-Strategie/Radar und MKR-MIC lässt sich so lesen: Technologieentscheidungen werden im Kontext der Vision und Ziele getroffen, während das OKR-Framework die Brücke in die Breite der Unternehmensaktivitäten schlägt.

Die Cloud-Plattform als Schwerpunkt

Ein Schwerpunkt der Tech-Strategie ist die operative und technische Realität einer Cloud-Plattform. Historisch liefen MIC-Anwendungen bei Kund:innen on-premise. Der Weg in die Cloud ist deshalb nicht bloß ein Rechenzentrumswechsel, sondern eine Umstellung des gesamten Bereitstellungsmodells.

„Es ändert sich viel, wenn man versucht, all die verschiedenen Anwendungen und Systeme an einem Ort zusammenzubringen.“

Entscheidungsrahmen: Provider und Bereitstellung

Gassner benennt eine zentrale Entscheidung:

„Wir haben entschieden, AKS als unseren Provider neben A1 zu nutzen.“

Diese Wahl – und die explizite Kommunikation darüber – ist exemplarisch für die Funktionsweise des Tech Radars. Sie schafft Klarheit: Welche Infrastruktur ist gesetzt? Wo laufen die zentralen Services? Welche Richtung unterstützt die Vision am besten?

Architekturelle Transformation: Von Single-Tenant zu Multi-Tenant

Die technische Kernaussage zur Architektur ist ebenso deutlich: MIC transformiert Single-Tenant-Anwendungen, isoliert Funktionen und implementiert Multi-Tenant-Services, die zentral in der Cloud deployt werden.

„… Multi-Tenant-Services, die wir zentral in unserer Cloud deployen, die die Kriterien für Cloud-native Anwendungen erfüllen, sodass sie skalierbar sind.“

Das Stichwort lautet Skalierbarkeit. Multi-Tenancy und Cloud-native-Kriterien werden nicht als abstrakte Ziele benannt, sondern als direkte Voraussetzung, die Vision zu erfüllen: die beste Cloud-Plattform für die spezifische Domäne zu betreiben.

Von der Vision in den Alltag: Wie die Ausrichtung wirkt

Gassner unterstreicht mehrfach, wie wichtig es ist, jede Aktivität an die strategischen Ziele zu koppeln. Für das Engineering bedeutet das:

Technologieevaluierungen sind Mittel zum Zweck. Sie müssen zeigen, welchen Beitrag sie zu Produktqualität, Compliance-Fähigkeit und Nutzer:innenmehrwert leisten.
Entscheidungen über Tools/Plattformen stehen unter dem Zielhorizont „Skalieren und Beschleunigen“. Trägt der gewählte Weg dazu bei, schneller und zuverlässiger in Produktion zu kommen? Verbessert er Support und Qualität?
Transparenz ist kein Extraschritt, sondern Teil der Technikarbeit. Das Radar und die Strategieunterlagen sind Bestandteil des Arbeitsprozesses.

Diese Orientierung macht einen Unterschied – gerade beim Übergang in die Cloud, wo Koordination und gemeinsame Standards über Erfolg und Geschwindigkeit entscheiden.

Entscheidungsfindung als Teamsport

Ein wiederkehrendes Motiv in Gassners Talk: Entscheidungen als Teamaufgabe. Die zusammengesetzte Gruppe (Expert:innen, Projekt-Stakeholder, Support/Operations, Management) übernimmt gemeinsame Verantwortung. Das hat mehrere Effekte:

Wissen wird an einem Ort konzentriert. Evaluierungen und Erfahrungen aus der Praxis finden unmittelbar Eingang in Entscheidungen.
Entscheidungen bekommen Akzeptanz. Wenn die Betroffenen beteiligt sind, ist der Weg zur Umsetzung kürzer.
Dokumentation wird selbstverständlich. Das Radar ist sichtbare, fortlaufend gepflegte Entscheidungsgrundlage.

„Wir versuchen zu zeigen, dass Entscheidungen nicht vom Management getroffen werden, sondern dass wir eine Gruppe haben, die das Wissen zusammenbringt und gemeinsame Entscheidungen trifft.“

Für eine 450-Personen-Organisation ist das ein skalierbarer Mechanismus: Entscheidungen erklärt zu bekommen („warum diese Technologie in diesem Kontext“) entlastet Teams von langwierigen Grundsatzdiskussionen und macht Raum für die eigentliche Produktarbeit.

Was das Tech Radar leistet

Gassner beschreibt das Tech Radar als Kommunikationsinstrument mit klarer Stoßrichtung:

Es macht Diskussionen und Entscheidungen transparent.
Es zeigt, wie Technologieentscheidungen in die Unternehmensziele einzahlen.
Es ist ein Einstiegspunkt für neue Mitarbeitende, um zu verstehen, „was wir tun und wohin wir uns entwickeln“.

Bemerkenswert: MIC denkt über eine Open-Source-Veröffentlichung nach. Noch ist das Radar intern, „vielleicht“ kommt Open Source in der Zukunft. Bis dahin erfüllt es seine interne Rolle: Klarheit schaffen.

Engineering-Learnings aus „The MIC Tech Radar“

Als DevJobs.at-Redaktion nehmen wir aus Gassners Talk eine Reihe handfester Impulse mit, die sich direkt auf Engineering-Praxis übertragen lassen – ohne über das Gesagte hinauszugehen.

1) Arbeit konsequent an Vision und Zielen ausrichten

Die explizite Kopplung jeder Aktivität an die Vision („beste Cloud-Plattform für Global Customs & Trade Compliance“) und an zwei strategische Ziele schafft Fokus. Wer Technologien evaluiert oder Services umbaut, argumentiert nicht abstrakt, sondern im Beitrag zu Wachstum, Qualität, Compliance und Time-to-Market.

2) Entscheidungsforen institutionalisieren

Ein cross-funktionales Gremium, das Expertenwissen, Projektperspektiven, Betrieb und Management bündelt, verhindert Insellösungen. Entscheidungen werden nachvollziehbar, wiederverwendbar und schneller umsetzbar, weil sie gemeinsam getragen werden.

3) Tech Radar als Prozess, nicht als Poster

Das Radar ist kein statisches Dokument, sondern ein Prozess der Diskussion und Dokumentation. Es beantwortet „Was?“, „Warum?“ und „Wie passt das zur Strategie?“ – und es aktualisiert sich mit der Organisation.

4) Cloud-Migration als Gesamtsystem denken

Die Aussage „Es ändert sich viel, wenn man Anwendungen und Systeme an einem Ort zusammenbringt“ ist zentral. Cloud ist nicht bloß Infrastrukturwechsel. Sie erzwingt klare Verantwortlichkeiten, einheitliche Bereitstellungspfade und ein Architekturzielbild (bei MIC: Multi-Tenant, Cloud-native, skalierbar).

5) Multi-Tenancy gezielt aufbauen

Der Schritt von Single-Tenant zu Multi-Tenant-Services ist mehr als Refactoring. Er ist die architektonische Grundlage, um zentral in der Cloud zu deployen und planbar zu skalieren. Das „warum“ ist bei MIC klar: Es dient direkt der Vision und der Time-to-Market-Verbesserung.

6) Providerentscheidungen früh klären – und kommunizieren

Die Entscheidung, „AKS als Provider neben A1“ zu nutzen, schafft Planungssicherheit. Solche Setzungen geben Teams Orientierung und beugen Komplexitätssprüngen vor.

7) Onboarding durch Transparenz beschleunigen

Gassner adressiert neue Mitarbeitende explizit: Das Radar zeigt, „was wir tun, in welche Richtung sich das Unternehmen entwickelt“. Wer früh versteht, welche Technologien gesetzt sind und warum, kommt schneller ins Liefern.

Konkrete Anwendungsfälle für Teams

Auch ohne in Details zu gehen, lassen sich aus dem Talk klare Anwendungsfälle ableiten:

Evaluierungen bündeln: Statt verteilte Prototypen „ins Blaue“ laufen zu lassen, Diskussionen im Radar strukturieren und Ergebnisse festhalten.
Architekturentscheidungen verankern: Der Schritt zu Multi-Tenancy sollte Radar-sichtbar sein – mit Zielzustand und Übergangsphasen.
Betriebsmodelle festziehen: Wer „Cloud-Plattform“ sagt, braucht eindeutige Betriebspfade und Zuständigkeiten. Das Radar ist der Ort, an dem das sichtbar wird.
Regulatorik im Blick behalten: Änderungen der Zollbehörden erfordern Produktanpassungen. Das „Warum“ hinter Technologieentscheidungen sollte diesen Bedarf spiegeln.
Time-to-Market messen und verbessern: Entscheidungen im Radar immer an der Frage ausrichten, ob sie Bereitstellung und Support beschleunigen und die Qualität erhöhen.

Zum Zusammenspiel mit MKR-MIC

Gassner nennt explizit ein OKR-basiertes Rahmenwerk namens „MKR-MIC“. Aus Sicht der Tech-Organisation wirkt es wie die komplementäre Ebene: Während das Radar Technologien und Entscheidungen kuratiert, sorgt MKR-MIC für die Verknüpfung mit übergreifenden Unternehmensaktivitäten. Wichtig ist: Beides zahlt auf die Vision und die zwei Ziele ein – und beides setzt auf Transparenz.

Kommunikation als Teil der Architektur

Eine oft unterschätzte Erkenntnis, die in Gassners Talk mitschwingt: Kommunikation ist Teil der Systemarchitektur. Wer Cloud-native, Multi-Tenant und skalierbar sagt, muss Entscheidungen, Gründe und Ziele erklärbar machen.

Das macht das System änderungsfreundlicher.
Es erleichtert Auditierbarkeit – ein naheliegendes Thema in einer Compliance-Domäne.
Es reduziert Reibungsverluste zwischen Entwicklung, Betrieb und Support.

In einem Satz: Das Tech Radar ist ein Architekturartefakt – genauso wichtig wie ein Diagramm oder eine API-Spezifikation, weil es Orientierung gibt und Kohärenz schafft.

Was Gassner explizit anspricht – und was nicht

Der Fokus der Session liegt klar auf Richtung, Organisation und Prinzipien. Gassner geht nicht in Tool- oder Code-Details. Er skizziert die zentralen Entscheidungen (Cloud statt On-Premise, Provider-Setzung, Multi-Tenancy, Cloud-native mit Skalierbarkeit) und die Governance, die diese Entscheidungen trägt (cross-funktionales Gremium, Transparenz, Kopplung an Ziele, MKR-MIC als ergänzender Rahmen). Genau diese Klarheit überlässt Implementierungsdetails den Teams – aber mit einem gemeinsamen Zielbild.

Ausblick und Einladung

Am Ende macht Gassner die Zielgruppe des Radars noch einmal groß: Es ist ein Arbeitsinstrument, aber auch ein Fenster für Interessierte.

„Wenn ihr interessiert seid, kommt zu MIC, schaut es euch an. Wir haben es noch nicht Open Source gestellt, vielleicht tun wir das in Zukunft.“

Für uns bleibt als Kernbotschaft: MIC nutzt Vision, Ziele, Tech-Strategie und Radar als zusammenhängenden Mechanismus, um Cloud-Transformation, Produktentwicklung und organisatorisches Wachstum synchron zu halten. Wer in einer ähnlichen Lage ist – viele Aktivitäten, wenig Sichtbarkeit, hoher Veränderungsdruck – findet in diesem Ansatz eine praktikable Blaupause: Entscheidungen gemeinsam treffen, transparent machen und konsequent an der Unternehmensausrichtung messen.

#

Zusammenfassung der wichtigsten Takeaways für Engineering-Teams

Vision als Nordstern: „Beste Cloud-Plattform für Global Customs & Trade Compliance“ bestimmt Prioritäten und Architektur.
Zwei strategische Ziele: überdurchschnittliches Wachstum durch großartige Produkte; Skalierung und Beschleunigung der Prozesse zur Verkürzung der Time-to-Market.
Tech Radar als Transparenzmotor: Diskussionen und Entscheidungen dokumentieren und mit Zielen verknüpfen.
Cross-funktionales Gremium: Expert:innen, Projekt-Stakeholder, Support/Operations, Management entscheiden gemeinsam.
Cloud-Fokus: Migration von On-Premise zu SaaS; Anwendungen und Systeme zentral zusammenführen.
Provider-Setzung: AKS neben A1 als klares Infrastruktur-Fundament.
Architekturpfad: Von Single-Tenant zu Multi-Tenant-Services; Cloud-native; Skalierbarkeit als Muss.
Ergänzendes Framework: MKR-MIC (OKR-basiert) für Aktivitäten jenseits der Technologie.
Onboarding beschleunigen: Radar dient neuen Mitarbeitenden als Kompass.
Qualität und Support: Entscheidungen stets daran messen, ob sie Qualität erhöhen und Support erleichtern.

Damit ist „The MIC Tech Radar“ weniger ein Dokument als ein Arbeitsmodus – einer, der Technologie, Organisation und Strategie kohärent zusammenführt.

Weitere Tech Talks

Weitere Tech Lead Stories