Von Mainframe zu Cloud — Mein Weg durch 6 Branchen

Warum Branchenvielfalt zaehlt

Wenn ich in Vorstellungsgespraechen nach meinem Werdegang gefragt werde, sehe ich manchmal ein Stirnrunzeln. Banking, Logistik, Events, Transport, Cloud, KI — sechs verschiedene Branchen in zwanzig Jahren. Manche lesen das als Unstetigkeit. Ich sehe es als meinen groessten Vorteil.

Jede Branche hat mir etwas beigebracht, das ich in keinem Buch und keinem Online-Kurs haette lernen koennen. Und jede Branche hat mir Werkzeuge gegeben — mentale und technische — die ich in den folgenden Kapiteln meiner Karriere gebraucht habe.

Das hier ist die Geschichte dieser Reise.

Kapitel 1: Banking — Wo alles begann

Mein erster professioneller Job war bei einer oesterreichischen Bank. Ich war frisch aus der Ausbildung, voller Elan und hatte keine Ahnung von der realen Welt der Softwareentwicklung. Was mich erwartete: PL/I auf IBM-Mainframes, JCL-Batch-Jobs, gruene Terminals und Deployment-Zyklen, die Wochen dauerten.

Es war nicht glamouroes. Es war nicht aufregend. Aber es war lehrreich.

Was ich im Banking gelernt habe, ist etwas, das viele Entwickler nie wirklich verstehen: Zuverlaessigkeit. In einer Bank darf Software nicht “meistens” funktionieren. Sie muss immer funktionieren. Jede Transaktion muss korrekt verbucht werden, jeder Cent muss stimmen, jeder Audit-Trail muss vollstaendig sein.

Diese Mentalitaet der absoluten Zuverlaessigkeit hat mich gepraegt. Ich habe gelernt, defensiv zu programmieren, Fehlerszenarien zu durchdenken und Transaktionssicherheit als nicht verhandelbar zu betrachten. Ich habe gelernt, dass “es funktioniert auf meinem Rechner” keine akzeptable Aussage ist.

Aber ich habe auch gelernt, was in traditionellen Unternehmen falsch laeuft: zu viel Buerokratie, zu lange Zyklen, zu wenig Mut zum Experimentieren. Nach drei Jahren wusste ich: Ich brauche etwas Schnelleres.

Kapitel 2: Logistik — Die reale Welt

Mein naechster Stopp war die Logistikbranche. Hier ging es nicht um abstrakte Finanztransaktionen, sondern um physische Dinge, die von A nach B bewegt werden mussten. LKWs, Lagerhaeuser, Barcode-Scanner, Echtzeit-Tracking.

Der groesste Kulturschock: In der Logistik sind Echtzeit-Systeme lebenswichtig. Wenn das Tracking-System ausfaellt, stehen LKWs an der falschen Stelle, Lager laufen ueber oder leer, Kunden bekommen ihre Lieferung nicht. Es gibt keine “geplante Wartung am Wochenende” — das System laeuft rund um die Uhr, sieben Tage die Woche.

Was ich hier gelernt habe: Systeme fuer die reale Welt zu bauen ist fundamental anders als Software im Vakuum zu entwickeln. Hardware kann ausfallen, Netzwerke koennen instabil sein, Nutzer koennen Dinge tun, die man sich in der wildesten Fantasie nicht vorgestellt haette. Ein Lagerarbeiter, der einen Barcode-Scanner als Tuerstopper verwendet, ist keine Ausnahme — es ist Dienstag.

Technisch habe ich hier viel ueber Integration gelernt. Verschiedene Systeme muessen zusammenarbeiten, oft ueber veraltete Protokolle und Schnittstellen. Ich habe gelernt, mit EDI, SOAP und diversen proprietaeren Formaten zu arbeiten. Ich habe gelernt, dass Interoperabilitaet wichtiger ist als Eleganz.

Kapitel 3: Events — Kreative Freiheit

Die Eventbranche war das Gegenteil der Bank. Hier wurde nicht ueber Monate geplant, hier wurde improvisiert. Ein Festival in sechs Wochen? Kein Problem. Das System muss Zutrittskontrolle, Cashless Payment und Artist Management koennen? Machen wir.

Was mich an der Eventbranche fasziniert hat: die Kombination aus Hardware und Software. Ich habe nicht nur Code geschrieben, sondern auch Barcode-Scanner konfiguriert, RFID-Lesegeraete integriert und Netzwerke auf Festivalgelaenden aufgebaut. In einem Zelt, bei Regen, mit einer instabilen Stromversorgung.

Die Lektion: Unter Druck liefern. Wenn das Festival morgen beginnt und das System nicht laeuft, gibt es keine Option “wir verschieben.” Man loest das Problem, egal wie. Diese Mentalitaet hat mich gelehrt, Prioritaeten zu setzen, das Wesentliche vom Unwesentlichen zu trennen und Loesungen zu finden, statt Probleme zu diskutieren.

Technisch habe ich hier gelernt, resiliente Systeme zu bauen. Systeme, die auch dann noch funktionieren, wenn die Haelfte der Infrastruktur ausfaellt. Offline-Faehigkeit, lokale Caches, Conflict Resolution — alles Konzepte, die spaeter in der Cloud-Welt wieder relevant wurden.

Kapitel 4: Transport — Komplexe Domaenen

In der Transportbranche habe ich zum ersten Mal erlebt, wie komplex Geschaeftslogik sein kann. Tarifberechnung, Routenplanung, regulatorische Anforderungen, multimodale Transportketten — die Domaene ist ein Labyrinth aus Regeln, Ausnahmen und Ausnahmen von Ausnahmen.

Hier habe ich Domain-Driven Design wirklich verstanden — nicht als akademisches Konzept, sondern als Ueberlebensnotwendigkeit. Ohne klare Domaenenmodelle, Bounded Contexts und eine gemeinsame Sprache mit den Fachexperten waere jedes Projekt gescheitert.

Die wichtigste Lektion: Zuhoeren. Bevor ich eine einzige Zeile Code schreibe, muss ich verstehen, was die Fachleute mir sagen. Und “verstehen” heisst nicht “die Anforderungen gelesen haben,” sondern “die Domaene so gut kennen, dass ich Fragen stellen kann, an die die Fachleute selbst nicht gedacht haben.”

Kapitel 5: Cloud und DevOps — Automatisierung als Superkraft

Der Wechsel in die Cloud- und DevOps-Welt war der groesste technische Sprung meiner Karriere. Ploetzlich ging es nicht mehr darum, einzelne Anwendungen zu bauen, sondern darum, ganze Infrastrukturen zu automatisieren.

Terraform, Docker, Kubernetes, CI/CD-Pipelines, Infrastructure as Code — eine voellig neue Welt. Und eine, die alles vereint hat, was ich bisher gelernt hatte. Die Zuverlaessigkeits-Mentalitaet aus dem Banking. Die Echtzeit-Anforderungen aus der Logistik. Die Resilienz aus der Eventbranche. Das Domaenenverstaendnis aus dem Transport.

Was mich an Cloud und DevOps am meisten beeindruckt hat: die Hebelwirkung. Ein einzelner Entwickler, der Infrastruktur als Code verwaltet, kann Systeme betreiben, fuer die frueher ein ganzes Operations-Team noetig war. Automatisierung ist eine Superkraft, und in der Cloud kann man sie voll ausspielen.

Ich habe hier auch gelernt, was “Skalierung” wirklich bedeutet. Nicht als theoretisches Konzept, sondern als praktische Herausforderung. Wenn ein System ploetzlich zehntausend statt hundert Anfragen pro Sekunde bekommt, zeigen sich die Schwaechen gnadenlos.

Kapitel 6: KI — Das aktuelle Kapitel

Und hier bin ich jetzt. Ich baue Tools fuer KI-gestuetzte Softwareentwicklung. Atoo Studio, SiteHorse, und was auch immer als Naechstes kommt.

Was dieses Kapitel von allen vorherigen unterscheidet: die Geschwindigkeit der Veraenderung. In der Banking-Welt hat sich die Technologie in Jahren veraendert. In der KI-Welt aendert sie sich in Wochen. Modelle, die vor sechs Monaten State of the Art waren, sind heute ueberholt. Frameworks, die gestern noch nicht existierten, sind morgen der Standard.

Das erfordert eine neue Art des Denkens. Ich kann nicht mehr auf eine stabile Plattform bauen und diese jahrelang nutzen. Ich muss meine Architektur so gestalten, dass ich die KI-Komponenten austauschen kann, ohne alles neu zu bauen. Abstraktion und lose Kopplung sind keine optionalen Best Practices — sie sind ueberlebensnotwendig.

Der rote Faden

Wenn ich auf alle sechs Kapitel zurueckblicke, sehe ich einen roten Faden: Probleme mit Technologie loesen. Das war in der Bank so, in der Logistik, bei Events, im Transport, in der Cloud und in der KI. Die Technologie hat sich veraendert, die Probleme haben sich veraendert, aber die Grundhaltung ist die gleiche geblieben.

Und genau deshalb glaube ich, dass Branchenvielfalt kein Nachteil ist. Jede Branche gibt einem ein neues Set an mentalen Modellen, neuen Denkweisen, neuen Perspektiven. Und in einer Welt, die sich immer schneller veraendert, ist die Faehigkeit, sich anzupassen und aus verschiedenen Perspektiven zu denken, wertvoller als tiefes Spezialwissen in einer einzigen Domaene.

Was ich jedem empfehle

Wenn ihr die Moeglichkeit habt, die Branche zu wechseln — tut es. Nicht jedes Jahr, aber alle paar Jahre. Verlasst eure Komfortzone. Lernt neue Domaenen kennen. Arbeitet mit anderen Technologien, anderen Teams, anderen Kulturen.

Ihr werdet feststellen, dass die wirklich wichtigen Dinge — klares Denken, gute Kommunikation, die Faehigkeit, komplexe Probleme in einfache Teile zu zerlegen — ueberall gelten. Und jede neue Branche wird euch ein besserer Entwickler machen.