Cloud Consulting als Kunst des Verbindens: Jörg Herzinger, Cloud Consultant bei ByteSource – vom TU-Wien-Server zum großen Ganzen

Warum diese Entwicklergeschichte heraussticht

Wir haben die Session „Jörg Herzinger, Cloud Consultant bei ByteSource“ mit großem Interesse verfolgt. Was uns sofort aufgefallen ist: Hier erzählt kein Theoretiker aus einer Folienwelt, sondern jemand, der den Weg in die Cloud-Beratung über praktisches Systemdenken gefunden hat. Jörg Herzinger von der ByteSource Technology Consulting GmbH beschreibt seine Laufbahn als eine kontinuierliche Bewegung – von der ersten „Spielwiese“ im Studium hin zur Arbeit an komplexen Kundensystemen. Der rote Faden? Teile verbinden, bis ein funktionierendes Ganzes entsteht.

Dabei bleibt er konsequent nah an der Realität: Anforderungen sind mitunter widersprüchlich; Sicherheit, Budget und Geschwindigkeit konkurrieren; und doch soll am Ende ein Produkt stehen, „das die Kundenanforderungen erfüllt“. Sein Pragmatismus ist erfrischend. Er spricht von vielen kleinen Elementen – eigener Software der Kunden, Open-Source-Produkten und Services eines Cloud-Providers – und einem klaren Ziel: alles so „hinbiegen“, dass es miteinander interagiert. Genau diesen Blick brauchen Teams, die cloudbasierte Systeme bauen, betreiben und kontinuierlich verbessern wollen.

Die Anfänge: Eine Spielwiese an der TU Wien

Herzingers Faszination begann nicht in einem klassischen Informatikstudium, sondern in der Praxis. Während seiner Zeit an der TU Wien hat er – so schildert er – der Studienvertretung geholfen, „einfach ihre Server und ihre Infrastruktur zu verwalten“. Rückblickend nennt er diese Umgebung eine „totale Spielwiese“. Freiheiten ohne Ende, kaum harte Vorgaben – eine Kombination, die Experimente erlaubt und Lernen beschleunigt. Er sagt offen, dass er diese Freiheit heute manchmal vermisst, gerade weil sie den Einstieg so wirkungsvoll gemacht hat.

Das Bild, das er zeichnet, ist ein zutiefst technisches – und zugleich zutiefst menschliches: Er hat „den einen Server“ aufgesetzt, Dienste ans Laufen gebracht, weil es konkret gebraucht wurde: „Wir brauchen einen Mail-Server, wir brauchen dieses, wir brauchen jenes.“ In dieser Phase hat er gelernt, Einzelteile, „die eigentlich nicht direkt miteinander reden können“, so zu konfigurieren, dass sie „miteinander interagiert“. Aus losen Komponenten entsteht ein System, das „insgesamt miteinander spricht“ – bis hin zur Mail-Verkettung.

Diese frühe Systemarbeit ist mehr als Nostalgie. Sie prägt eine berufliche Haltung. Wer erlebt hat, wie ein einzelner Server durch kluges Kombinieren disparate Anforderungen erfüllt, lernt zwei Dinge: Erstens, dass Integration eine praktische, schrittweise Tätigkeit ist. Zweitens, dass Anforderungen oft unscharf starten – und dass es Handwerk braucht, um daraus etwas Funktionierendes zu bauen.

Vom Basteln zur Haltung: Systeme denken und bauen

Herzinger beschreibt seine ersten Schritte als eine Mischung aus Freiheit, Notwendigkeit und Neugier. Es ist kein Selbstzweck. Vielmehr geht es ihm darum, „Sachen zum Laufen zu bringen“. Aus unserer Sicht zeigt sich hier ein Kernelement erfolgreicher Cloud- und Infrastrukturarbeit: Eine Sache zählt – ob das System funktioniert und die Aufgabe erfüllt. Die Fähigkeit, zwischen Komponenten Brücken zu schlagen, ist im Kern nicht neu. Neu sind heutige Größenordnungen, Automatismen und Erwartungen an Skalierbarkeit – aber das Grundmuster bleibt.

Dieses Motto kondensiert eine verantwortungsvolle Entwicklerhaltung. Nicht die Technologie steht im Vordergrund, sondern das Ergebnis. Wer so denkt und arbeitet, ist später in der Cloud-Beratung im Vorteil – gerade, wenn Kundenanforderungen heterogen sind.

Übergang in den Beruf: Automatisierung als roter Faden

Nach dem Studium blieb Herzinger dem Thema treu. Er berichtet, dass er „auch während Studium kleinweise gearbeitet“ hat und „in die Automatisierungen gleich wieder reingekommen“ ist. Automatisierung markiert für viele Entwicklerinnen und Entwickler den Übergang von manueller Administration zu reproduzierbaren, zuverlässigen Abläufen. Die Überschrift könnte lauten: Was einmal händisch funktioniert, lässt sich auch systematisch machen.

Wichtig ist, wie Herzinger die Kontinuität hervorhebt: Die Faszination blieb dieselbe. Vom ersten Mail-Server bis zur modernen Cloud-Integration – es bleibt die Aufgabe, viele kleine Teile zu etwas Größerem zu verbinden. Das Selbstverständnis dahinter ist elementar: nicht jede Komponente muss perfekt sein; entscheidend ist, dass das Gesamtsystem die Anforderungen erfüllt.

Heute: Cloud Consulting als Integrationsaufgabe

Im Berufsalltag als „Cloud Consultant“ wirkt dieses Muster in konzentrierter Form weiter. Herzinger beschreibt die Landschaft, in der er arbeitet, mit knappen, präzisen Begriffen:

• „Viele, viele kleine Elemente“
• kundeneigene „Custom-Software“
• „irgendeine Open-Source-Software“ oder ein „Open-Source-Produkt“
• und „der Cloud-Provider, der seine Services hat“

Die Aufgabe: „Ich muss die alle miteinander nehmen und muss sie zu einem großen verbinden, zu einem großen Produkt, das im Endeffekt die Kundenanforderungen erfüllt.“ Diese Formulierung ist bemerkenswert bescheiden – und zugleich anspruchsvoll. Sie benennt die drei Realitätsebenen moderner IT:

1) Was der Kunde schon hat (Custom-Software)

2) Was die Community beisteuert (Open Source)

3) Was die Infrastruktur-Seite bereitstellt (Cloud-Services)

Die Kunst besteht darin, den kleinstmöglichen Eingriff zu wählen, der die größtmögliche Wirkung entfaltet. Herzinger spricht davon, „da und dort an ein paar Parametern“ zu schrauben oder „eine neue kleine Software dazwischen stellen“ zu können. Das klingt pragmatisch – und ist es auch. Es vermeidet übermäßige Komplexität, konzentriert sich auf funktionale Kopplungspunkte und hält das Ziel im Blick: „Am Schluss kommt hoffentlich das raus, was der Kunde genau haben will.“

Das Spannungsdreieck: Sicherheit, Budget, Geschwindigkeit

Besonders deutlich wird Herzinger, wenn er die Realitäten von Projekten adressiert. Jede Organisation hat andere „Vorgaben“ und „Schwierigkeiten“. Mal steht „Security“ im Vordergrund, ein anderes Mal ist das „Budget“ die zentrale Größe. Und manchmal hat Zeit absolute Priorität: „Wir müssen es einfach nur möglichst schnell fertig haben.“

Diese drei Kräfte – Sicherheit, Kosten und Geschwindigkeit – erzeugen ein Spannungsfeld. Projekte scheitern nicht, weil eine Dimension unwichtig wäre, sondern weil sie nicht ehrlich priorisiert wird. Herzingers Botschaft zwischen den Zeilen: Cloud Consulting ist nicht nur Technik. Es ist auch Erwartungsmanagement und das fortlaufende Abgleichen von Rahmenbedingungen mit einem angestrebten Ergebnis.

Das erfordert Übersicht, Erfahrung und die Bereitschaft, Kompromisse bewusst zu treffen. Die Meta-Kompetenz, die daraus erwächst, ist systemisches Denken: Es reicht nicht, eine Komponente zu optimieren, wenn dadurch das Gesamtsystem sein Ziel verfehlt.

Arbeitsweise: Parameter, Zwischenkomponenten, Ergebnisorientierung

Ein wiederkehrendes Motiv in Herzingers Erzählung ist die fokussierte Veränderung. Statt das System großflächig umzubauen, werden gezielt Parameter angepasst oder kleine Zwischenkomponenten eingeführt. Diese Haltung hat mehrere Konsequenzen:

• Sie reduziert Implementierungsrisiken, weil kleinere Schritte beherrschbar sind.
• Sie bewahrt vorhandene Investitionen, indem Bestehendes integriert statt ersetzt wird.
• Sie beschleunigt die Lieferung von Mehrwert – eine wichtige Antwort auf den Zeitdruck, den Herzinger explizit erwähnt.

Damit steht sein Vorgehen für einen Stil, der in der Cloud-Ära besonders wertvoll ist: iterativ, kompatibilitätsorientiert, und jederzeit an der Schnittstelle zwischen Kundenbedarf und Systemlogik. Ein „großes Ganzes“ entsteht nicht durch Big-Bang-Projekte, sondern durch fortlaufendes Ausrichten und präzise Verbindung.

Offene Wege in die Cloud: Kein zwingendes Studium

Ein wichtiger Teil von Herzingers Geschichte ist sein Zugang zur Profession. Er legt ausdrücklich nahe, dass niemand ein bestimmtes Studium „braucht“, um einzusteigen: „Es gibt keine groben Voraussetzungen. Man muss nicht das eine oder das andere studiert haben. Ich habe auch nicht Informatik studiert.“

Seine Empfehlung ist klar: Interesse, Faszination und die Bereitschaft, Neues zu lernen. Wer offen ist und „immer wieder was Neues lernen will“, kann gut dabei sein. Besonders betont er die Selbstständigkeit in der Motivation: „Sie müssen selbstständig irgendwie Faszination und Interesse zeigen.“ Daraus ergibt sich seine optimistische Schlussfolgerung: „Dann kommt alles von selbst, wenn man es gern macht.“

Diese Haltung ist ermutigend. Sie schafft Zugänge gerade für Quereinsteigerinnen und Quereinsteiger und betont die Bedeutung von Praxis: Lernen durch Tun, getrieben von Neugier und Zielorientierung. In unserer Wahrnehmung ist das nicht nur ein Ratschlag an Einzelne, sondern auch ein Impuls an Teams, Lernräume zu schaffen – Freiheiten, die Herzinger an seiner TU-Wien-Spielwiese so schätzte.

Was wir als Redaktion mitnehmen

Aus der Session „Jörg Herzinger, Cloud Consultant bei ByteSource“ destillieren wir fünf zentrale Einsichten:

1) Systemsicht schlägt Stückwerk. Wer das Ganze sieht, trifft bessere Entscheidungen über die Teile. Herzinger denkt konsequent vom Ziel her: eine Lösung, die „die Kundenanforderungen erfüllt“.

2) Kleine, wirksame Eingriffe sind Gold wert. Parameter verändern, gezielte Zwischenkomponenten einsetzen, statt alles neu zu bauen – so entsteht belastbare Integration.

3) Prioritäten ehrlich machen. Sicherheit, Budget, Geschwindigkeit – in Projekten gewinnen nicht alle drei gleichzeitig. Klarheit über die aktuelle Priorität ist der Schlüssel.

4) Lernen ist ein Habitus, kein Projekt. Herzingers Weg zeigt: Kontinuität in der Faszination erzeugt Tiefe in der Kompetenz, unabhängig vom formalen Studienweg.

5) Praxisnähe ist der beste Lehrmeister. Ein Mail-Server, der wirklich laufen muss, lehrt mehr über Verantwortung und Integration als theoretische Beispiele.

Konkrete Hinweise für Entwicklerinnen und Entwickler

Ohne über die Aussagen des Speakers hinauszugehen, lassen sich aus seiner Erzählung konkrete, praxisnahe Schritte ableiten:

• Denke in Systemen: Beschreibe zuerst das gewünschte Verhalten des Gesamtsystems. Frage dich, wie Teile miteinander interagieren müssen, statt einzelne Komponenten zu perfektionieren.
• Starte klein: Setze zunächst die minimal notwendigen Dienste auf, die den Kernzweck erfüllen. Stabilisiere, beobachte, erweitere erst dann.
• Verbinde statt zu ersetzen: Prüfe, ob eine kleine Zwischenkomponente oder angepasste Parameter reichen, um inkompatible Teile arbeitsfähig zu koppeln.
• Nimm Rahmenbedingungen ernst: Kläre mit Stakeholdern, ob bei der aktuellen Lieferung Sicherheit, Budget oder Geschwindigkeit dominiert – und handle konsequent danach.
• Pflege Neugier: Plane regelmäßig Zeit ein, um neue Werkzeuge und Konzepte zu verstehen. Offene Haltung schlägt komplette Planbarkeit.
• Dokumentiere Integrationspunkte: Halte fest, wo und warum du Schnittstellen so konfiguriert hast, damit spätere Anpassungen gezielt erfolgen können.
• Lerne aus Betriebserfahrungen: Beobachte, wo das System unter Last oder bei Ausfällen seine Schwachstellen zeigt, und leite daraus pragmatische Verbesserungen ab.

Diese Schritte sind bewusst generisch formuliert – so, wie Herzinger seine Arbeit auf die Grundprinzipien zurückführt. Sie bieten eine verlässliche Orientierung, auch wenn die konkrete Technologieauswahl von Projekt zu Projekt variiert.

Was Teams und Unternehmen daraus lernen können

Die Geschichte legt nahe, wie Teams ihren Arbeitsmodus gestalten sollten:

• Räume für Experiment und Verantwortung: Die „Spielwiese“ von damals war kein Luxus, sondern ein Katalysator. Teams profitieren von sicheren Experimentierfeldern mit realem Nutzen.
• Ergebnisorientierte Kultur: Belohnt wird, was funktioniert. Das fördert pragmatisches Denken und hält den Fokus auf Kundennutzen.
• Bewusste Priorisierung: Sicherheit, Kosten, Tempo – jede Iteration braucht eine klare Leitgröße. Das verhindert konflikthafte Zielüberlagerungen.
• Integrationskompetenz als Kernfähigkeit: Die Fähigkeit, heterogene Komponenten zusammenzuführen, wird zur Schlüsselkompetenz – über Tools hinaus.
• Lernen ermöglichen: Karrierewege, die nicht vom formalen Studium abhängen, fördern Vielfalt und Resilienz im Team.

Eine Haltung, die bleibt: „Am Schluss kommt hoffentlich das raus…“

Herzingers Schilderung wirkt deshalb so glaubwürdig, weil sie ohne Pathos auskommt. Sein Ziel ist schlicht und anspruchsvoll zugleich: „Am Schluss kommt hoffentlich das raus, was der Kunde genau haben will.“ Zwischen Anfang und Ende liegen Dutzende Entscheidungen, kleine Parameteränderungen, die Wahl einer unauffälligen Zwischenkomponente, das Abwägen zwischen Sicherheit, Budget und Geschwindigkeit.

Was uns überzeugt, ist die Konstanz: Vom ersten Server in der TU-Wien-Studienvertretung über frühe Automatisierungen bis zur Beratungspraxis in der Cloud – es ist derselbe Denkstil. Einzelteile, die nicht direkt miteinander sprechen, werden verbunden, bis ein System entsteht, das trägt. Dieses Selbstverständnis ist die leise Stärke von „Cloud Consulting“ – und der Kern einer Entwicklerkarriere, die aus Neugier, Pragmatismus und Verantwortungsgefühl wächst.

Schlussgedanke: Das große Ganze im Blick behalten

„Jörg Herzinger, Cloud Consultant bei ByteSource“ zeigt eine Entwicklung, die viele von uns kennen – und doch selten so klar benennen: Technologie ist Mittel, nicht Zweck. Entscheidend ist, Systeme zu bauen, die reale Anforderungen erfüllen. Wer gelernt hat, aus Widrigkeiten ein funktionierendes Ganzes zu machen, der wird auch in neuen Technologiewellen bestehen. Und wer den Mut hat, mit Faszination zu starten – unabhängig vom Studiengang – findet seinen Weg. Genau diese Haltung macht den Unterschied, wenn aus Komponenten Kundenlösungen werden.

• 

  

  Manuel Lindner, Senior Consultant bei ByteSource

  Senior Consultant von ByteSource Manuel Lindner umreißt im Interview die Organisation der Teams sowie die verwendeten Technologien und spricht darüber, wie das Recruiting abläuft.

  Jetzt ansehen