Ewen Simon, Cloud Architect bei ÖBB: Lernen am Rand der Komfortzone – Azure, Cloud und der Wert des Struggelns

Einleitung: Was wir aus dieser Session mitnehmen

Titel: Ewen Simon, Cloud Architect bei ÖBB

Speaker: Ewen Simon

Company: ÖBB-Konzern

In seiner kurzen, aber pointierten Session bringt Ewen Simon das auf den Punkt, was viele Cloud-Engineers intuitiv fühlen, aber selten so klar formulieren: Wirkliches Lernen in der Cloud passiert dort, wo die Dokumentation aufhört und die Realität beginnt. Er spricht über die Faszination von Azure, die Dynamik eines sich stetig wandelnden Technologiefelds und die Kraft einer Community aus Gleichgesinnten, die gemeinsam wachsen wollen. Vor allem aber gibt er einen einfachen, treffsicheren Rat für alle, die einsteigen wollen: Finde einen Kontext, der dich herausfordert – nicht „outside the box“, aber „am Rand“.

Wir bei DevJobs.at haben besonders aufmerksam zugehört, weil hier eine Perspektive zusammenkommt, die für Entwickler:innen und Architekt:innen jedes Levels relevant ist: die Lust am Problem und die Einsicht, dass „It worked, that’s the end of it“ kein Lernmoment ist. Diese Session ist ein Plädoyer dafür, bewusste Reibungspunkte zu suchen – und genau daraus die eigenen Skills zu schärfen.

Was Ewen an Cloud und Azure liebt

Ewen benennt drei Dinge, die ihn an der Arbeit in und mit der Cloud – speziell Azure – begeistern:

• Es gibt nicht immer ein Beispiel und manchmal nicht einmal eine Dokumentation.
• Es ist ein Feld, das sich ständig verändert.
• Man arbeitet mit Gleichgesinnten, die wachsen wollen und an gemeinsamen Projekten arbeiten.

Diese Aussage ist bemerkenswert, weil sie die üblichen Frustrationen (fehlende Beispiele, Lücken in der Doku, stete Veränderung) nicht als Hindernisse versteht, sondern als Quelle von Motivation. Für Ewen steckt gerade darin der Reiz: Wenn nicht alles vorgedacht ist, sind Kreativität und Ingenieurskunst gefragt. In diesem Spannungsfeld zwischen Unvollständigkeit und Bewegung zeigt sich, wer Systeme verstehen, stabilisieren und weiterentwickeln kann.

Fehlende Beispiele als Lernmotor

Wer Cloud arbeitet, kennt den „Happy Path“: Man folgt der Dokumentation, konfiguriert Dienst A mit B, alles deployed – fertig. Ewen dreht diese Betrachtung: Wo keine Beispiele sind, beginnt die eigentliche Arbeit. Dort entstehen Fragen: Was ist die richtige Reihenfolge? Welche Annahmen treffen die Defaults? Welche Konsequenzen haben kleine Abweichungen in Netzwerk, Identity oder Storage? Genau diese Fragen forcieren nachhaltiges Verständnis.

Ständiger Wandel als Übungsfeld

„Constantly changing“ ist nicht bloß Trendhudelei. Der Wandel wirkt wie ein Metronom: Er zwingt Teams, wiederholt Prinzipien zu überprüfen und Architekturentscheidungen zu reflektieren. In Azure kann ein neuer Service, ein geändertes Quota, ein neues Feature-Flag oder ein deprecates API einzelne Bausteine aufrütteln. Wer diese Bewegung akzeptiert, lernt kontinuierlich.

Gemeinsam wachsen – die Rolle der Gleichgesinnten

Ewen betont die Arbeit „with people that are like-minded“. Für Lernkultur heißt das: Pairing, gegenseitige Code- und Design-Reviews, Post-Mortems, die sich nicht in Schuldzuweisungen erschöpfen, sondern Muster sichtbar machen. Wenn Teams das „gemeinsame Projekt“ ernst nehmen, entsteht eine Lernarchitektur: Wissensinseln werden zu Brücken, Erfahrungswissen wird explizit, Entscheidungen werden reproduzierbar.

Der wichtigste Tipp: Finde einen Kontext „am Rand“

Auf die Frage „How do you get started?“ antwortet Ewen ohne Umweg: Finde einen Kontext, der dich leicht überfordert – nicht „outside the box“, aber an der Grenze.

Der Clou liegt in der Formulierung „at the border“. Es geht nicht um künstliche Exotik, sondern um bewusst gewählte Randbedingungen, die die Komfortzone leicht überschreiten. Beispiele dafür sind in der Cloud naheliegend: etwas strengere Netzwerkregeln, ein ungewöhnlicher Authentifizierungsflow, Integrationen mit Diensten, die nicht 1:1 im Handbuch beschrieben sind. Das Ziel ist nicht, das Scheitern zu suchen, sondern die Wahrscheinlichkeit zu erhöhen, auf reale Probleme zu stoßen – und dadurch zu lernen.

Warum der „Happy Path“ zu wenig lehrt

Wenn ein „App Service und eine Website-Datenbank“ nach Dokumentation deployed werden und sofort funktionieren, ist das zwar befriedigend – aber pädagogisch fast wertlos. Lernen braucht Feedback. Fehler, Engpässe und Unklarheiten liefern dieses Feedback. Wer nie an Grenzen stößt, lernt die Grenzen nicht kennen.

Struggle als Lehrmeister – „glücklicherweise“

Bemerkenswert ist, wie Ewen den Struggle rahmt: „luckily“. Nicht trotz, sondern wegen der Schwierigkeiten lernen wir. Das ist eine Haltungsfrage. Wer Fehler als Daten versteht und Problemlösen als Kern des Berufs, der kann sich systematisch „schlau scheitern“: Hypothesen bilden, verändern, erneut testen – und Wissen dabei verankern.

Vom Impuls zur Praxis: So setzt du „Kontext am Rand“ um

Aus Ewens Aussagen lassen sich konkrete Schritte ableiten, um Lernen in Azure und der Cloud gezielt zu strukturieren – ohne künstliche Überdramatisierung, aber mit Absicht.

1) Setze eine Lernhypothese statt eines Features

• Formuliere, was du verstehen willst (z. B. Netzwerkisolation, Identitäten zwischen Diensten, Deployment-Strategien).
• Definiere, woran du das erkennst (Messgrößen, Logs, Fehlerszenarien, Durchsatzgrenzen).
• Koppel das Lernziel an ein kleines, greifbares Artefakt (z. B. eine Mini-Anwendung mit spezifischer Randbedingung).

2) Wähle eine Randbedingung, die Reibung erzeugt

• Grenze bewusst Ressourcen oder Berechtigungen ein.
• Variiere Pfade, die in der Dokumentation nur am Rande erwähnt sind.
• Vermeide Abkürzungen: Nutze die Standard-Defaults bewusst nicht, wenn du verstehst, was sie verbergen.

3) Arbeite hypothesengetrieben mit kurzen Iterationen

• Schreibe auf, was du erwartest (z. B. „Service A kann über private Endpunkte mit B sprechen“).
• Teste gezielt Fehlerszenarien (Credentials entziehen, Netzwerk abdichten, Limits provozieren).
• Dokumentiere Ursache–Wirkung: Welche Config hat welchen Effekt?

4) Benutze Dokumentation als Baseline, nicht als Endpunkt

• Lies die Doku, um Begriffe und Grundpfade zu verstehen.
• Suche den Rand: Welche Abschnitte behandeln Ausnahmen, Limits, Edge Cases?
• Ergänze mit Experimenten: Prüfe, wo die Doku unpräzise ist oder bewusst offen bleibt.

5) Lerne sozial: „Like-minded people“ einbinden

• Teilt eure Hypothesen und Ergebnisse.
• Führt Nachbesprechungen durch: Was hat überrascht? Was bleibt unklar?
• Baut wiederverwendbare Bausteine aus dem, was ihr gelernt habt (Docs, Templates, Patterns, Checklisten).

Die Pädagogik der Cloud: Lernen über Konzepte statt über Klickpfade

Ein subtiles Thema in Ewens Aussagen: Er rückt vom „Deploy nach Anleitung“ ab und hin zu konzeptionellem Verständnis. In Azure und jeder anderen Cloud reichen Klickpfade nicht aus; wer die zugrunde liegenden Konzepte versteht, kann Services austauschen, neue Versionen adaptieren und mit inkompletten Informationen zurechtkommen.

• Identität und Zugriff: Wer spricht mit wem, mit welcher Identität und welchem Scope?
• Netzwerke und Grenzen: Welche Isolationsebenen brauche ich wirklich?
• Zustände und Daten: Wie fließen Daten, wer hält Zustände, was passiert bei Ausfällen?
• Beobachtbarkeit: Wo messen wir, was „funktioniert“?
• Resilienz: Welche Degradationspfade sind akzeptabel, welche müssen verhindert werden?

Wer diese Fragen unabhängig vom konkreten Dienst beantworten kann, lernt nachhaltig – und ist den Veränderungszyklen gewachsen, die Ewen als konstituierend für die Cloud beschreibt.

„Common projects“: Lernen passiert im Produkt, nicht daneben

Ewen spricht ausdrücklich von „common projects“. Das ist mehr als „gemeinsam lernen“; es bedeutet, dass Lernen mit der Produktarbeit verwoben ist. Aus unserer Sicht als Redaktion ist das die reifste Form von Weiterbildung im Tech-Team:

• Lernen an echten Anforderungen, nicht an abstrakten Übungen.
• Relevantes Risiko: Entscheidungen haben Konsequenzen – im Kleinen gehalten, aber real.
• Gemeinsame Verantwortung: Erkenntnisse wandern direkt in Code, Pipelines und Betrieb.

Wenn Teams das verinnerlichen, entsteht ein Kreislauf aus Exploration und Konsolidierung. Edge-Experimente liefern Einsichten; diese werden in robuste Standards überführt. Genau das spiegelt Ewens Fokus auf Randkontexte wider: Nicht das Spektakel suchen, sondern die Lücken schließen, die in der Doku offenbleiben.

Warum „It worked“ kein Lernziel ist

Die Aussage ist bewusst zugespitzt: Natürlich ist es gut, wenn Dinge funktionieren. Aber als Lernziel ist „es funktioniert“ zu grob. Interessant wird es, wenn wir verstehen:

• Warum funktioniert es?
• Unter welchen Bedingungen bricht es?
• Wie beobachte ich es?
• Wie mache ich es reproduzierbar?
• Wie kommuniziere ich die getroffenen Annahmen?

Mit diesen Zusatzfragen verschieben wir Lernen von „Erfolg“ zu „Erkenntnis“. Genau das ist der Kern von „struggling, luckily“.

Ein realistischer Lernpfad für Azure-Einsteiger:innen (inspiriert von Ewens Tipp)

Ohne die Session zu überinterpretieren, lässt sich ein einfacher Pfad ableiten, der den „Kontext am Rand“ operationalisiert:

1. Wähle ein kleines Produktziel (z. B. eine einfache API).
2. Formuliere ein Lernziel (z. B. private Kommunikation ohne öffentliche Endpunkte).
3. Definiere eine Randbedingung, die Reibung erzeugt (z. B. eingeschränkte Rollen, restriktive Netzwerke, alternatives Auth-Modell).
4. Baue das Minimalprodukt – gern entlang der Doku, um die Basis zu legen.
5. Drehe an einer Stellschraube, die die Doku nicht detailliert abdeckt.
6. Logge alles: Hypothese, Änderung, Beobachtung, Ergebnis.
7. Teile die Erkenntnisse im Team und hebe sie in einen wiederverwendbaren Baustein (Readme, Template, Pattern).
8. Wiederhole mit einer neuen Randbedingung.

Dieser Zyklus ist klein genug, um neben dem Tagesgeschäft zu laufen, und robust genug, um nachhaltiges Verständnis aufzubauen.

Mentale Modelle für produktives Struggling

Ewen liefert keine Checkliste – aber seine Aussagen stützen drei hilfreiche mentale Modelle:

• Edge-orientiertes Design: Plane von den Grenzen her. Welche Annahmen könnten falsch sein? Welche Ressourcen werden knapp?
• Versuch und Beweis: Behandle jede Konfiguration als Hypothese. Wie würdest du das Gegenteil beweisen?
• Sozialer Verstärker: Nutze „like-minded people“ als Multiplikator. Gemeinsame Projekte verwandeln individuelle Einsichten in Teamkompetenz.

Diese Modelle sind universell – sie funktionieren in Azure, in anderen Clouds und in hybriden Umgebungen. Entscheidend ist die Haltung, mit der wir Unschärfe und Wandel begegnen.

Zitate, die hängen bleiben

• „There is not always an example, or not even a documentation sometimes.“
• „It’s just working in a field that’s constantly changing.“
• „With people that are like-minded, trying to grow for themselves, and also to work on common projects.“
• „The main thing that you will learn with, is by struggling, luckily.“
• „It will work … and it’s not interesting.“

Diese Sätze funktionieren wie Wegweiser: Sie zeigen auf die Stellen, an denen Lernen wirklich passiert.

Fazit: Lernen dort, wo die Doku endet

Die Session „Ewen Simon, Cloud Architect bei ÖBB“ im Kontext des ÖBB-Konzerns ist ein starkes Plädoyer für bewusstes, kontextgetriebenes Lernen in der Cloud. Azure ist für Ewen attraktiv, weil es lückenhaft sein kann, weil es sich verändert und weil es eine Community aus „like-minded people“ gibt, die gemeinsam auf echten Projekten lernen.

Der wichtigste Impuls ist einfach zu formulieren und anspruchsvoll umzusetzen: Suche den Rand. Nicht das Spektakel, sondern die Stelle, an der die Doku leiser wird. Baue dort einen kleinen, testbaren Kontext und erlaube dir, zu struggeln – „luckily“. Genau dort entsteht das Wissen, das in Projekten trägt.

Für Entwickler:innen und Architekt:innen heißt das: Nutzt den Happy Path als Start, aber macht ihn nicht zum Ziel. Das Ziel ist Verständnis. Und das findet man selten in der Mitte – fast immer am Rand.

• 

  

  Natascha Muehl, Back End Developerin bei ÖBB

  Natascha Muehl von der ÖBB redet im Interview über ihren Start in die IT, was ihre Arbeit im Back End Development beinhaltet und gibt Tipps für Beginner.

  Jetzt ansehen