Vom Bleistift zum Cloud-Stack: Die Entwicklerreise von Michael Hahn (Corporate Software Architect bei Doka GmbH)

Ein DevJobs.at-Rückblick auf „Michael Hahn, Corporate Software Architect bei Doka“

Wenn wir bei DevJobs.at eine Devstory zusammenfassen, suchen wir nach den Momenten, in denen aus Technik Laufbahn wird – und aus Laufbahn Wirkung. In „Michael Hahn, Corporate Software Architect bei Doka“ zeichnet Michael eine klare, bodenständige Linie: vom ersten Scripting in der Hauptschule über Programmieren auf Papier, frühen .NET-Fokus und weltweite Rollouts bis hin zur Architekturverantwortung in einem internationalen Umfeld. Seine Geschichte ist kein Feuerwerk aus Buzzwords, sondern ein Wegweiser: pragmatisch, lernorientiert, menschenzentriert.

Was wir daraus gelernt haben: Wer technisches Handwerk ernst nimmt, der wächst – von Grundlagen ohne Tools bis hin zu globalen Rollouts. Wer Verantwortung als Architekt übernimmt, tut das nicht mit Elfenbeinturm-Blueprints, sondern mit Enablement, klaren Leitlinien und einem gemeinsamen Rahmen, der Teams hilft, sich auf inhaltliche Anforderungen zu konzentrieren. Und wer in einer schnellen Branche bestehen will, pflegt Routinen: lesen, zuhören, vergleichen, hinterfragen.

Erste Schritte: Scripting, Toolbook und die Lust am Ausprobieren

Michael beschreibt seinen Einstieg unprätentiös: In der Hauptschule beginnt er „so mit 13, 14“ mit dem Programmieren – wobei „Programmieren“ zunächst Scripting ist. Toolbook, ein damals eingesetztes Werkzeug, wird zur Spielwiese: Objekte fliegen durch die Gegend, ein Funke springt über. Wichtiger als das Tool ist dabei die Erfahrung: Auf dem Weg in die Softwarewelt zählen Neugier und kleine Experimente.

Noch während dieser ersten Gehversuche reift die Einsicht: Das könnte langfristig passen. Der nächste Schritt folgt konsequent – die HTL in der Richtung EDV-Unterorganisation (heute würden viele schlicht „IT“ sagen). Das Ziel: solide Grundlagen legen.

Programmieren auf Papier: Warum grundlegendes Denken zählt

Ein prägender Abschnitt im Rückblick: der Start in der HTL – mit Visual Basic Script, nicht etwa am Rechner, sondern „auf Papier mit Bleistift“. Das klingt unüblich, ist aber genau der Punkt:

Erfolgsgefühle stellen sich zunächst nicht ein: „Ich war nicht sehr erfolgreich am Anfang.“ Aber das Blatt wendet sich. Diese Phase illustriert, wie wertvoll es ist, Programmlogik wirklich zu durchdringen – unabhängig von IDEs, Autocomplete oder Debugger-Komfort. Wer Code zuerst im Kopf und auf Papier strukturiert, baut ein Fundament, das Frameworks und Sprachenwechsel überdauert.

Sprachenreise: Von Java bis .NET – und der Fokus auf Microsoft & Cloud

Über die Jahre arbeitet sich Michael „über Java bis .NET“ durch verschiedene Sprachen. Die technische Heimat kristallisiert sich heraus: .NET bleibt. Der Fokuskanon: Microsoft-Ökosystem, Cloud, .NET als „Steckenpferd“ – eine Kombination, die ihm offenbar Stabilität und Hebel bietet. In einer Welt, in der Tech-Auswahl inflationär wirkt, zeigt seine Linie: Spezialisierung und Tiefe zahlen sich aus, besonders wenn sie auf einem breiten Fundament liegen.

Berufseinstieg und Wechsel zur Doka GmbH

Nach der HTL folgt der Einstieg als Junior Softwareentwickler. Rund „eineinhalb Jahre“ sammelt Michael Erfahrung in unterschiedlichen Firmen, dann kommt der Wechsel zur Doka GmbH. Hier startet er als Entwickler für eine interne Kalkulationssoftware – und lernt auf einen Schlag mehr als nur Code:

• Er bekommt Einblick „in alle Prozesse … die sich so in den Sales und Operations Bereich verbergen“.
• Er begleitet weltweite Rollouts – „von Amerika bis Singapur“.
• Bis auf Australien schafft er jeden Kontinent.
• Und er erlebt, wie „jedes Land … doch ein bisschen eigen und anders“ ist.

Diese Phase ist zweifach prägend: fachlich (Domänenverständnis über Sales & Operations) und menschlich (internationale Zusammenarbeit, Respekt vor Unterschieden). Dazu kommt ein persönlicher Bonus: „Ich reise gerne“ – die globale Rollout-Erfahrung trifft auf eine private Motivation. Hier zeigt sich eine oft unterschätzte Karrierekomponente: Wenn fachliche Aufgaben und persönliche Interessen aufeinander einzahlen, entsteht Energie für die Extrarunde.

Neben dem Job studieren: Hagenberg, Hinterfragen und der Blick über den Tellerrand

2015 macht Michael den nächsten Schritt: ein berufsbegleitendes Software-Engineering-Studium in Hagenberg. Die Gegenüberstellung von HTL und Studium fällt deutlich aus:

Dieses „Hinterfragen“ wird zum Katalysator für den nächsten Karriereschritt. Es geht nicht mehr nur darum, wie man etwas baut, sondern warum – und welche Alternativen bestehen. Aus unserer Sicht liegt hier einer der stärksten Hebel in Entwicklerkarrieren: Theorie liefert die Sprache und die Konzepte, Praxis liefert Reibung und Realität – die Kombination aus beidem hebt das Niveau. Michael bringt es so auf den Punkt:

Ankommen in der Architektur: Verantwortung über Systeme und Teams

Mit dieser Basis erreicht Michael seine aktuelle Position: Corporate Software Architekt. Seit „mittlerweile zweieinhalb Jahren“ (ungefähr) verantwortet er diese Rolle – nicht statisch, sondern wachsend:

Aus Redaktionssicht steckt in dieser Formulierung eine wichtige Erkenntnis: Rollenreife ist ein Prozess. Titel sind Momentaufnahmen; Wirkung entsteht, wenn man mit jedem Projekt, jeder Entscheidung, jedem Gespräch die eigene Rolle schärft.

Vier Wirkfelder eines Corporate Software Architekten

Michael fasst die Architekturarbeit bei Doka in vier Bereiche:

1) Technisches Consulting für Softwareprojekte

Architektur beginnt bei konkreten Vorhaben. Der Fachbereich bringt Anforderungen und Produktideen, interne und externe Teams arbeiten zusammen. Aufgabe der Architektur:

• gemeinsame Sicht auf Umsetzung und Architektur schaffen,
• Komponenten und Bausteine auswählen,
• das System „aufbauen“ – in dem Sinn, dass die richtigen Teile zur richtigen Zeit am richtigen Ort sind.

Hier zeigt sich ein pragmatisches Selbstverständnis: Architektur ist ein Service für Projekte. Sie beantwortet nicht abstrakte Fragen, sondern hilft, Anforderungen tragfähig umzusetzen.

2) Upskilling und Enablement der Projektmitglieder

Ein zweites Feld ist das gezielte Befähigen. Das Team-Setup: „zwei Architekten und zwei Solution-Engineers“. Damit existieren eine konzeptionelle Schiene (Architektur) und eine operative (Solution Engineering). Besonders bei neuen Technologien geht das Team bewusst in Vorleistung:

• erste Schritte evaluieren,
• „passt das ins Projekt?“ klären,
• Projektmitglieder „auf die Reise mitnehmen“.

Dieser Modus ist entscheidend für Geschwindigkeit ohne Blindflug: Neues wird nicht unreflektiert in die Breite gegeben, sondern zunächst belastbar gemacht – und dann systematisch in die Teams getragen.

3) Guidelines und Konzeption – mit Security als Leitplanke

Drittes Feld: unternehmensweite Leitlinien. Fragen wie „Wie verwenden wir als Unternehmen die Cloud?“ werden bewusst gestaltet. Dazu gehören Standards bei Komponenten, klare Präferenzen und Regeln – auch in der Sicherheit. Die Beispiele sind bewusst konkret:

• „Man speichert keine Passwörter irgendwo.“
• „… und verschlüsselt … an der Datenbank.“

Michael macht deutlich, dass Verstöße trotz bester Absichten vorkommen können:

Diese Ehrlichkeit schärft den Blick: Security ist nicht primär eine Frage von Policies auf Papier, sondern von Alltagsroutinen, Checklisten, Reviews und Kultur. Leitlinien sind dafür notwendig – und nur dann wirksam, wenn sie in der Umsetzung ankommen.

4) Gemeinsames Framework – Werkzeuge, Pakete, Entscheidungen

Der vierte Bereich ist ein Multiplikator: ein gemeinsames Framework aus Tools, Packages und Komponentenentscheidungen. Ziel ist „zu vereinfachen … für alle Projektmitglieder“, damit sie sich „hauptsächlich auf die inhaltlichen Anforderungen“ konzentrieren können. Aus unserer Sicht reduziert ein solches Framework kognitive Last:

• weniger Zeit für wiederkehrende technische Entscheidungen,
• konsistentere Basis über Projekte hinweg,
• mehr Fokus auf Domäne, Fachlogik und Kundennutzen.

Das ist kein Selbstzweck, sondern ein Produktivitäts- und Qualitätshebel.

Arbeiten zwischen Technik und Menschen: Was wir beobachtet haben

Was uns in dieser Devstory besonders auffällt, ist die Balance zwischen Technologie und Enablement. Michaels Schilderung enthält kein Namedropping – und gerade dadurch wird klar, worauf es ankommt:

• Handwerk zählt: erst denken, dann tippen. Notfalls auf Papier.
• Tiefe statt Dauerwechsel: ein Stack als Heimat (bei ihm .NET, Microsoft, Cloud), ohne Scheuklappen.
• Architektur als Service: beraten, strukturieren, Entscheidungen tragen – und Teams stärken.
• Regeln ohne Dogma: Leitlinien und Security dienen der Realität, nicht umgekehrt.
• Frameworks als Hebel: Wiederverwendung, Konsistenz, Fokus auf Inhalte.

Diese Haltung, gepaart mit internationaler Erfahrung, zeichnet die Rolle eines Corporate Software Architekten: nicht die größte PowerPoint-Folie entscheidet, sondern die Summe guter, geteilter Praktiken – in Projekten, in Teams, im Alltag.

Kontinuierliches Lernen: Ausbildung, Blogs, Podcasts

Auf die Frage, wie man vorankommt, benennt Michael zwei Hebel – Ausbildung und Lernen im Fluss der Arbeit:

1) Die Ausbildung klug kombinieren. Seine Empfehlung basiert auf eigener Erfahrung: IT-HTL plus anschließendes Studium, idealerweise berufsbegleitend. Praktische Erfahrung und theoretisches Know-how verstärken sich gegenseitig:

2) Die Branche ist schnelllebig – also braucht es Routinen jenseits des Tagesgeschäfts. Michael hält es so:

• „Blogs … die ich einfach täglich verfolge“, um Trends zu erkennen und Anwendungsfälle zu entdecken.
• Podcasts, weil sie „überall“ funktionieren – „beim Laufen, beim Radeln, im Zug, im Auto“. Das Entscheidende daran ist nicht das Medium, sondern die Regelmäßigkeit. Wer kontinuierlich Input sammelt, erkennt schneller Muster, Technologien und Gelegenheiten.

Dazu kommt ein kultureller Aspekt: über die eigene Branche hinausblicken. „Was macht der restliche Markt so, was machen andere Branchen?“ Dieser Blick über den Tellerrand ist die Verlängerung des Studiums in die Praxis: Hinterfragen, übertragen, verbessern.

Praktische Ableitungen für Entwicklerinnen und Entwickler

Aus Michaels Weg lassen sich konkrete Schritte für die eigene Laufbahn ableiten – ohne große Theorien, dafür mit viel Anwendungssinn.

• Grundlagen bewusst schärfen: Übe Problemlösung ohne Tooling-Krücken. Skizziere Algorithmen, Datenflüsse und Grenzen zuerst in Worten oder Zeichnungen. Wer Logik klar fassen kann, programmiert zuverlässiger – in jeder Sprache.
• Einen Stack wirklich kennen: Entscheide dich für eine technische Heimat (wie bei Michael .NET und das Microsoft-Umfeld) und baue darin Tiefe auf. Das schließt andere Technologien nicht aus – es priorisiert Lernzeit und schafft ein Profil.
• Domäne verstehen: Egal ob interne Kalkulationssoftware oder Kundenprodukt – fachliche Prozesse (Sales, Operations, etc.) sind kein Beiwerk, sondern der Kern des Nutzens. Je besser du die Domäne kennst, desto besser werden Architekturentscheidungen.
• Architektur als Enablement: Wenn du Verantwortung für Systeme trägst, schaffe Klarheit, bevor du Komplexität einführst. Architekturen sind für Teams da – nicht Teams für Architekturen.
• Leitlinien lebbar machen: Schreib Regeln so, dass sie im Projektdruck tragen. Schaffe Beispiele, Checklisten und Defaults, die Fehler unwahrscheinlicher machen – gerade bei Security.
• Gemeinsame Bausteine pflegen: Ein leichtgewichtiger, geteilter Rahmen aus Tools und Packages spart Zeit, vermeidet Streuung und hebt Qualität. Überarbeite ihn iterativ – und erkläre das „Warum“.
• Lernroutinen fixieren: Lege fest, wann und wie du Blogs verfolgst und Podcasts hörst. Entscheidend ist die Konstanz, nicht die Länge. Nimm dir zudem bewusst Zeit, übertragbare Ideen aus anderen Branchen zu erkennen.

Globale Rollouts: Lernen in der Fläche

Michaels Hinweis auf weltweite Rollouts ist mehr als eine Reisestory. In komplexen Organisationen mit vielen Standorten zeigen sich Stärken und Schwächen von Software unter realen Bedingungen. Zwei Punkte werden dabei greifbar:

• Unterschiedlichkeit ernst nehmen: „Jedes Land ist … ein bisschen eigen und anders.“ Was in einem Markt funktioniert, wirkt anders in einem anderen. Architekturfeinheiten wie Konfigurierbarkeit, Lokalisierung oder Integrationspfade erhalten erst im Feld ihr Gewicht.
• Erfahrung skaliert: Wer an verschiedenen Orten live mit ausrollt, lernt schneller, wo Standards helfen – und wo man Abzweigungen braucht. Genau diese Lernerfahrung fließt in Guidelines, Frameworks und Beratungsarbeit zurück.

Die Rolle reift mit: Vom Entwickler zum Corporate Software Architekten

Der Übergang in die Architektur ist bei Michael kein Sprung über Nacht, sondern ein Kontinuum. Wichtig sind die Bausteine:

• frühe Programmiererfahrung – auch wenn sie holprig beginnt,
• die Breite über verschiedene Sprachen hinweg, bevor der Fokus stabil wird,
• Praxis in Businessprozessen und in globalen Rollouts,
• das berufsbegleitende Studium als Denkvertiefung,
• das schrittweise Schärfen der Architektenrolle über Jahre.

Dieser Weg ist wiederholbar – nicht als Blaupause, aber als Komposition: Praxis plus Theorie plus Verantwortung.

Zitat-Highlights, die hängen bleiben

Diese Sätze sind wie Pins in der Landkarte einer Entwicklerkarriere: Basics, Fokus, Feldarbeit, Denken in Systemen – und ein Kulturkern, der Technik menschlich hält.

Schlussgedanke: Technik als Handwerk, Architektur als Verantwortung

„Michael Hahn, Corporate Software Architect bei Doka“ zeigt, wie sich eine Laufbahn aus konsequenten Schritten zusammensetzt: von ersten Skripten über programmierte Grundlagenarbeit ohne Editor, über Spezialisierung und weltweites Rollout zur tragenden Rolle in der Unternehmensarchitektur. Die Lehre ist klar: Wer stetig lernt, sauber denkt und Teams befähigt, macht Fortschritt wahrscheinlicher. Oder, um mit Michael zu schließen:

Für alle, die in Architektur hineinwachsen wollen, ist das eine ebenso einfache wie robuste Richtschnur.

• 

  

  Benjamin Schauer, Group Leader Digital Operation Tools bei Doka

  Group Leader bei Doka Benjamin Schauer umreißt im Interview die Organisation des Teams für Digital Operation Tools, was dort technologisch spannend ist und wie das Recruiting und Onboarding gestaltet ist.

  Jetzt ansehen
• 

  

  Ronni Bjelosevic, DevOps Team Lead bei Doka

  DevOps Team Lead bei Doka Ronni Bjelosevic gibt im Interview einen Überblick über den Aufbau der Teams im Unternehmen, was dort neue Mitarbeiter erwartet und mit welchen Technologien gearbeitet wird.

  Jetzt ansehen

• 

  

  Matthias Schmutzer, Mobile Developer bei Doka

  Matthias Schmutzer von Doka spricht im Interview über seinen Einstieg ins Software Development, mit welchen Aufgabenbereichen er in seiner aktuellen Arbeit zu tun hat und gibt Ratschläge für Leute, die selbst gerne mit Development starten möchten.

  Jetzt ansehen
• 

  

  Katja Hammer, Software Developer bei Doka

  Katja Hammer von Doka erzählt im Interview über ihren Werdegang als Software Developer bis hin zu ihrer aktuellen Arbeit und gibt Tipps für Neueinsteiger.

  Jetzt ansehen