enjoy IT GmbH

Etablierte Firma

Alle Videos anzeigen

Thomas Hintersteiner, Software Architect bei enjoy IT

Thomas Hintersteiner von enjoy IT erzählt im Interview über seinen Weg – angefangen von der HTL bis hin zu seiner aktuellen Arbeit – und gibt Tipps für Personen die selbst mit dem Programmieren anfangen möchten.

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

Video Zusammenfassung

In "Thomas Hintersteiner, Software Architect bei enjoy IT" schildert Thomas Hintersteiner seinen Weg von der EDV-HTL über die ersten, visuell motivierenden Webprojekte hin in Studium und Praxis. Bei enjoy IT konzipiert er Lösungen, die bestehende Kundensysteme mit den Zielbildern verbinden, und adressiert dabei Integration, Datenverarbeitung, Sicherheit sowie die Einbindung der Beteiligten. Sein Rat: spielerisch starten (z. B. mit Lego-Robotern), Spaß und Interesse in den Mittelpunkt stellen und über Erfahrung mit vielen Systemen vom Entwickler zum Architekten wachsen – unabhängig von HTL, Studium oder Lehre.

Vom Backend-Frust zur Web-Leidenschaft: Was wir von „Thomas Hintersteiner, Software Architect bei enjoy IT“ (enjoy IT GmbH) über den Weg in die Software-Architektur lernen

Ein Einstieg, der nicht nach Bilderbuch klingt – und genau deshalb relevant ist

Wir bei DevJobs.at haben in „Thomas Hintersteiner, Software Architect bei enjoy IT“ eine Laufbahngeschichte gehört, die für viele Entwicklerinnen und Entwickler überraschend vertraut klingt: Der Funke springt nicht immer beim ersten „Hello, World!“ über. Thomas Hintersteiner beschreibt seinen Start in einer EDV-HTL, wo zunächst vor allem Backend-Programmierung am Stundenplan stand. Seine ehrliche Einschätzung: Das fühlte sich am Anfang nicht nach dem an, was ihn begeistern würde – es fehlte ihm das Visuelle.

Am Anfang habe ich mir gedacht, das ist nicht unbedingt das, was mich interessieren wird, weil wir hauptsächlich Backend-Programmierung gemacht haben und man hat nichts Visuelles dabei.

Dann kam der Wendepunkt: Das Internet wurde größer, zugänglicher und damit für Thomas erst richtig spannend. Aus überschaubarem Aufwand wurde plötzlich Reichweite – Webseiten, die mit relativ einfachen Mitteln gebaut werden konnten, eröffneten ihm eine neue Perspektive auf Software.

Mit wenig Aufwand ein großes Auditorium zu erreichen – das war der spannende Teil.

Dieser Übergang von „keine visuelle Rückmeldung“ zur unmittelbaren Wirkung einer Webseite ist mehr als eine Anekdote. Er ist eine konkrete Erinnerung daran, wie wichtig Feedbackschleifen für Motivation sind: Sichtbarkeit, Wirkung, Resonanz – ein Dreiklang, der Thomas’ Weg maßgeblich geprägt hat.

Vom Klassenzimmer in die Praxis – wo es „wirklich spannend“ wurde

Der Weg führte nach der Schule weiter ins Studium und in die Praxis – und dort, so beschreibt es Thomas, wurde es „wirklich spannend“. Ohne zusätzliche Ausschmückung lässt sich daraus ein zentrales Muster ableiten, das wir immer wieder beobachten:

Praxis verstärkt Relevanz: Wenn echte Systeme, echte Nutzerinnen und Nutzer und echte Anforderungen ins Spiel kommen, verändern sich Prioritäten und Lernkurven.
Ambiguität statt Lehrbuch: An der Schnittstelle zwischen Theorie und realen Randbedingungen entstehen die Entscheidungen, die einen Entwickler zu einem Architekten reifen lassen.

Thomas’ Erzählung bleibt bewusst pragmatisch: Sie dreht sich nicht um Tech-Glanzstücke, sondern um den Kontext, in dem Technologie wirken soll. Genau das führt uns zu seiner heutigen Rolle.

Der Arbeitsalltag als Software-Architekt bei enjoy IT GmbH: Vom Ist-Zustand zum Zielbild

In seiner Rolle als Software-Architekt bei der enjoy IT GmbH beginnt die Arbeit häufig mit einem klaren Spannungsbogen: Kundinnen und Kunden kommen mit Anforderungen. Es gibt ein Zielbild (wie soll es aussehen?) und einen Startpunkt (was ist vorhanden?). Die Aufgabe: eine Lösung aus dem Vorhandenen ableiten und so mit dem Ziel verbinden, dass das Ergebnis im Frontend die richtigen Informationen liefert.

Wir haben ein Ziel – wie soll das ausschauen – und einen Startpunkt – was ist schon vorhanden? Als Architekt geht es darum, basierend auf dem, was da ist, eine Lösung zu überlegen und mit dem Ziel zu verknüpfen.

Thomas skizziert drei zentrale Herausforderungen, die in dieser Brücke zwischen Ist und Soll regelmäßig auftreten:

1) Systemintegration: Wie integriert man bestehende Systeme so, dass am Ende das herauskommt, was im Frontend angezeigt werden soll? Die Realität ist selten grün von Grund auf neu, sondern bunt gemischt – mit Schnittstellen, Datenquellen, Altlasten und neuen Anforderungen.

2) Datenverarbeitung: Daten müssen verarbeitet, transformiert, zusammengeführt werden – damit das Frontend nicht nur etwas anzeigt, sondern das Richtige, im richtigen Kontext, zur richtigen Zeit.

3) Sicherheit: Nicht jeder soll Zugriff auf Backend-Systeme haben. Dieser scheinbar simple Satz steht stellvertretend für Authentifizierung, Autorisierung und die Frage, wie man Schutzmaßnahmen so gestaltet, dass sie Sicherheit und Nutzererlebnis zugleich respektieren.

Dabei betont Thomas, dass die Arbeit als Architekt vielfältig ist – technisch und menschlich. Technologie allein baut keine tragfähigen Lösungen.

Neben dem technischen Teil ist es wichtig, die Leute mit an Bord zu haben und sie bestmöglich zu integrieren.

Mit anderen Worten: Architektur heißt auch Alignment. Menschen, Teams und Stakeholder so zu verbinden, dass technische Entscheidungen getragen werden – und Wirkung entfalten.

Warum Visualität motiviert – und was das für Lernpfade bedeutet

Die „visuelle Lücke“ am Anfang seiner Ausbildung und die spätere Begeisterung fürs Web sind mehr als biografische Details. Sie zeigen, wie stark Motivation von spürbaren Ergebnissen lebt. In den Worten von Thomas: Mit relativ einfachen Mitteln eine Webseite bauen und damit viele erreichen – das war der Klick-Moment.

Aus dieser Beobachtung lassen sich für Lernpfade klare Schlüsse ziehen:

Früh Feedback sichtbar machen: Wer lernt, braucht Erlebnisse, die sich „anfühlen“, nicht nur „funktionieren“.
Projekte statt Problemlisten: Ein Web-Frontend, das Daten ausgibt, wirkt motivierender als eine rein abstrakte Übungsaufgabe.
Reichweite als Motivator: Zu wissen, dass ein Ergebnis gesehen und genutzt wird, gibt Energie – gerade in frühen Phasen.

Thomas’ konkreter Rat für den Einstieg unterstreicht diese Idee.

Einstieg heute: spielerisch, zugänglich, neugierig

Wenn Kinder (oder Einsteiger) heute mit Programmierung beginnen, sieht Thomas eine große Vielfalt an Zugängen: von Lego-Robotern, die sich programmieren lassen, bis zu einfachen Spielen, mit denen man sich Schritt für Schritt herantasten kann.

Es gibt heute viele Möglichkeiten: Lego-Roboter, einfache Spiele – so kann man sich herantasten.

Für Fortgeschrittene gilt für ihn ein klarer Kompass: Spaß. Freude an der Sache ist nicht Beiwerk, sondern Grundlage für nachhaltiges Lernen und Dranbleiben.

Das Wichtigste ist, dass man Spaß hat an dem, was man macht. Durch Spaß Interesse wecken – das trägt.

Interessant ist auch, wie Thomas die typische Entstehung der Architektenrolle beschreibt: oft ein organischer Übergang aus der Entwicklung heraus. Wer verschiedene Systeme gesehen hat und beginnt, Lösungen zu konzipieren, wächst in die Architektur hinein – unabhängig davon, ob der Weg über eine HTL, ein Studium oder eine Lehre führt.

Ob HTL, Studium oder Lehre – egal. Wichtig sind Interesse und Freude an dem, was man macht.

Diese Haltung entlastet: Es gibt keinen goldenen Bildungsweg. Es gibt Neugier, Praxis und die Bereitschaft, Verantwortung für Lösungen zu übernehmen.

Aus Anforderungen werden Lösungen: ein Leitfaden aus Thomas’ Praxisbild

Was können wir aus Thomas’ Beschreibung für unseren eigenen Architekturalltag ableiten? Aus seiner knappen, aber pointierten Skizze entsteht ein robuster Leitfaden, den wir so zusammenfassen:

1) Startpunkt und Zielbild schärfen

Was ist vorhanden? Systeme, Daten, Schnittstellen, Prozesse.
Wie soll das Ergebnis aussehen? Nicht nur UI, sondern auch Verhaltensweise und Datenflüsse.
Welche Lücke muss überbrückt werden? Technisch, fachlich, organisatorisch.

2) Integration vor Perfektion

Integration bestehender Systeme ist selten „sauber von Null“. Akzeptiere Realitäten.
Definiere die minimale, zuverlässige Verbindung, die das gewünschte Frontend-Ergebnis ermöglicht.
Optimiere später iterativ; der erste Schritt ist Sichtbarkeit und Korrektheit.

3) Daten richtig denken

Datenverarbeitung ist Kern, nicht Nebensache.
Lege klar fest, welche Daten wann, wo und wie transformiert werden.
Behalte das Frontend-Ergebnis als Test: Kommt wirklich das Richtige an?

4) Sicherheit ist Default, nicht Add-on

Nicht jeder darf auf Backend-Systeme zugreifen – das ist Prinzip, nicht Einzelfall.
Entwirf Zugriffspfade so, dass Schutz und Nutzererlebnis in Balance sind.
Denke in Rollen und Grenzen: Wer darf was, wo und wann?

5) Menschen mitnehmen

Architekturentscheidungen werden von Menschen getragen.
Erkläre das Zielbild in Bildern, die für alle verständlich sind.
Hole Teams früh in den Prozess; Integration ist auch sozial.

Die unsichtbare Arbeit: Erwartungen moderieren, Komplexität verständlich machen

Zwischen „Startpunkt“ und „Zielbild“ liegt viel unsichtbare Arbeit: Erwartungen sortieren, Begriffe klären, Risiken benennen. Thomas benennt das nicht ausufernd, aber seine Stichworte – Integration, Daten, Sicherheit, People – zeigen, wie breit das Feld ist. Wir sehen darin drei wiederkehrende Kommunikationsaufgaben:

Übersetzen: Fachliche Ziele in technische Schritte übersetzen – und zurück.
Priorisieren: Was muss zuerst gelöst werden, um das gewünschte Frontend-Ergebnis sichtbar zu machen?
Grenzen benennen: Was verhindert derzeit, dass das Ergebnis sicher und zuverlässig erreichbar ist?

Wer diese drei Aufgaben ernst nimmt, macht Komplexität steuerbar – und bewahrt Teams vor Frust durch unsichtbare Hürden.

Motivation als Langstreckenfaktor: Freude, die trägt

Thomas’ Betonung von Spaß ist kein nettes Add-on, sondern ein ernsthafter Hinweis für Langstreckenkarrieren. Motivation wird nicht in Zertifikaten gemessen, sondern in Energie für die nächste Iteration. Sein eigenes Beispiel – der Wechsel zu visuell spürbaren Ergebnissen – zeigt: Es lohnt sich, Aufgaben so zu gestalten, dass sie Rückmeldung geben.

Konsequent gedacht, heißt das für Lern- und Projektplanung:

Baue frühe, sichtbare Teilergebnisse ein.
Erlaube Experimente mit kleinem Risiko und hohem Lernwert (z. B. Prototypen).
Nutze Werkzeuge, die schnelle Rückmeldungen ermöglichen – ob Lego-Roboter oder ein kleines Webprojekt.

In die Architekt:innenrolle hineinwachsen: ein Muster, das trägt

Thomas beschreibt Architektur als natürliche Fortsetzung der Entwicklung: Zuerst baut man, dann sieht man verschiedene Systeme, dann konzipiert man Lösungen. Dahinter steckt ein Muster, das sich verallgemeinern lässt:

Breite vor Tiefe (zunächst): Verschiedene Systeme sehen, Stärken und Schwächen erkennen.
Vom Baustein zum Bauplan: Nicht nur Komponenten bauen, sondern Verbindungen gestalten.
Verantwortung übernehmen: Entscheidungen treffen, die mehrere Beteiligte betreffen – technisch und organisatorisch.

Daraus folgt: Wer Architekt:in werden will, sollte aktiv Situationen suchen, in denen Integration, Datenflüsse und Sicherheit eine Rolle spielen – und dabei Menschen mitnehmen.

Konkrete Handlungsimpulse – abgeleitet aus Thomas’ Aussagen

Um die Brücke zur Praxis zu schlagen, hier ein Bündel an Impulsen, die direkt aus den Motiven der Session hervorgehen:

Formuliere dein Zielbild als „Frontend-Ergebnis“. Frage: Was soll sichtbar und nutzbar sein?
Zeichne das, was vorhanden ist. Welche Systeme, Datenquellen, Rechte, Schnittstellen?
Definiere den ersten integrierten Pfad: von einer Quelle bis zur Anzeige – korrekt, sicher, nachvollziehbar.
Setze Sicherheit bewusst vor die Kurve: Wer darf was? Wie wird das durchgesetzt?
Organisiere eine Demo so früh wie möglich, um Feedback sichtbar zu machen.
Erkläre die Lösung so, dass alle Beteiligten – Technik und Fachseite – folgen können.
Pflege die Motivation: Wähle Aufgaben, die spürbare Ergebnisse liefern und Freude ermöglichen.

Für unterschiedliche Karrierestufen: Was wir mitnehmen

Einsteiger:innen: Suche Lernmittel mit schneller Rückmeldung – Lego-Roboter, einfache Spiele, kleine Webprojekte. Je schneller du Wirkung siehst, desto leichter bleibst du dran.
Junior- bis Mid-Level-Dev: Schau bewusst über Komponentenränder. Wie fließen Daten? Welche Systeme sind beteiligt? Wo sind Sicherheitsgrenzen?
Auf dem Weg zur Architektur: Übernimm Verantwortung für das Verbinden von Ist und Soll. Starte bei dem, was vorhanden ist, und definiere den minimalen, aber tragfähigen Weg zum Zielbild.
Unabhängig vom Bildungsweg: HTL, Studium oder Lehre – wähle, was zu dir passt. Entscheidend sind Interesse und Freude.

Ein nüchterner, wirksamer Blick auf Architektur

Was die Session so wertvoll macht, ist ihr nüchterner Ton. Keine Heldengeschichte, sondern eine klare Beschreibung dessen, was zählt: Startpunkte erkennen, Zielbilder klären, Integration ermöglichen, Daten verarbeiten, Sicherheit ernst nehmen – und Menschen auf dem Weg mitnehmen. In dieser Kürze liegt Präzision.

Für uns ist das ein Reminder: Architektur ist weniger eine Sammlung exotischer Muster als die konsequente Gestaltung von Übergängen – vom Vorhandenen zu dem, was gebraucht wird.

Fazit: Architektur beginnt dort, wo Wirkung sichtbar wird

„Thomas Hintersteiner, Software Architect bei enjoy IT“ zeigt: Motivation entsteht, wenn Ergebnisse sichtbar werden. Karriere entsteht, wenn man Verantwortung für die Verbindung von Ist und Soll übernimmt. Und nachhaltige Lösungen entstehen dort, wo Sicherheit und Menschlichkeit denselben Stellenwert bekommen wie Technologie.

Baue früh sichtbare Ergebnisse.
Respektiere das, was vorhanden ist – und entwirf den Weg zum Zielbild.
Denke Daten und Sicherheit von Anfang an mit.
Nimm Menschen mit auf die Reise.
Bewahre dir die Freude am Tun – sie ist der längste Hebel für Qualität und Ausdauer.

In diesem Sinne liefert die Erzählung von Thomas Hintersteiner einen klaren Kompass für Entwicklerinnen und Entwickler, die in die Architektur hineinwachsen wollen: Fang bei dem an, was da ist. Definiere, was sichtbar werden soll. Gestalte die Brücke – technisch sauber und menschlich tragfähig. Der Rest ist Iteration.

Weitere Dev Stories