OPERUS / WER HIER SCHREIBT
Über mich
Ich bin Solution Architect mit Entwicklerhintergrund und jemand, der auch nach Feierabend gerne am Computer sitzt und nur schwer aufhören kann, sobald aus einer Idee ein echtes System zu werden beginnt.

Beruflich beschäftige ich mich mit Technologie, Virtualisierung, Integration und Architektur. Auch wenn ich eigentlich genug technische Dinge den Tag über auf der Arbeit mache, widme ich oft meine Abende oder auch Wochenenden meinen privaten Projekten. Man kann sagen: Es ist mein bevorzugtes Hobby. (Neben vielen anderen)
Andere fahren Motorrad, gehen angeln oder schrauben an alten Autos. Ich freue mich darauf, mich in ein technisches Problem zu vertiefen, Zusammenhänge zu verstehen und etwas zu bauen, das vorher nicht existiert hat.
Das kann eine eigene Software sein, eine neue Automatisierung für mein Smart Home, eine Verbesserung an meinem Netzwerk oder einfach ein Dienst, den ich ausprobieren möchte. In den vergangenen Jahren ist eine weitere große Spielwiese hinzugekommen: künstliche Intelligenz und die Frage, was sich mit ihr erschaffen lässt und wo sie mir einen echten Nutzen bringen kann.
Spoiler: Sie hat meine Art, Projekte zu entwickeln, grundlegend verändert.
Wie alles angefangen hat
Mein erster Computer war ein Commodore 16 mit Datasette. Ich war elf Jahre alt, und auch wenn seine Möglichkeiten aus heutiger Sicht überschaubar waren, öffnete er für mich eine völlig neue Welt.
Danach folgte ein C64 mit Floppy-Disk-Laufwerk. Damals begann ich, mehrseitige BASIC-Listings aus dem 64’er-Magazin abzutippen. Zeile für Zeile entstand auf dem Bildschirm ein eigenes Spiel oder eine kleine Anwendung – vorausgesetzt, ich hatte mich nirgendwo vertippt.
Das war manchmal mühsam, aber zugleich faszinierend: Aus gedrucktem Text wurde etwas, das sich starten, ausprobieren und verändern ließ. Wahrscheinlich entstand damals schon die Begeisterung, die mich bis heute begleitet – aus einer Idee und vielen einzelnen Bausteinen etwas Eigenständiges zu erschaffen.
Später kam der Amiga 500. An ihm faszinierte mich besonders die Demoszene. Was Entwickler und Künstler damals aus dieser begrenzten Hardware herausholten, war unglaublich: Grafik, Animation und Musik, manche Intros sogar untergebracht in nur wenigen Kilobyte.
Diese Demos waren nicht nur technisch beeindruckend, sondern auch kreativ und atmosphärisch ihrer Zeit weit voraus. Sie zeigten mir, dass gute Ergebnisse nicht unbedingt unbegrenzte Ressourcen benötigen. Entscheidend ist, wie gut man ein System versteht und wie kreativ man mit seinen Grenzen umgeht.
Gleichzeitig entdeckte ich Spiele, die mich nicht nur spielerisch, sondern auch durch ihre Atmosphäre faszinierten. Adventures wie Maniac Mansion, Zak McKracken, Indiana Jones oder Monkey Island fühlten sich damals wie interaktive Welten an.
Mit jeder neuen Generation wurden Grafik und Sound besser, die Figuren lebendiger und die Geschichten dichter. Das Zusammenspiel aus Bildern, Musik, Dialogen und Interaktion erzeugte eine Atmosphäre, die mich wochenlang beschäftigte.
Rückblickend faszinierte mich daran vermutlich dasselbe, was mich heute an guten Produkten begeistert: Nicht eine einzelne technische Leistung macht das Erlebnis aus. Es entsteht erst dann, wenn viele unterschiedliche Elemente sorgfältig ineinandergreifen und sich für den Benutzer wie ein stimmiges Ganzes anfühlen.
Auf den Amiga folgte mein erster PC, ein 486 DX mit damals wahnsinnigen 33 MHz. Und dann kam das Internet.
Als ich mich zum ersten Mal mit einem 33,6-kbit/s-Modem einwählte, begleitet von jenem unverwechselbaren Pfeifen und Rauschen, fühlte es sich an, als würde sich eine Tür zu einer völlig neuen Welt öffnen. Plötzlich war der eigene Computer nicht mehr allein. Er war mit anderen Computern, Informationen und Menschen verbunden.
Aus heutiger Sicht war alles langsam, umständlich und technisch begrenzt. Damals war es für mich schlicht fantastisch.
Vom Entwickler zum Architekten
Aus dieser frühen Begeisterung wurde schließlich mein Beruf. Ich begann als Anwendungsentwickler und konzentrierte mich zunächst darauf, fachliche Anforderungen in funktionierende Software zu übersetzen.
Ich lernte zahlreiche Programmiersprachen und verbrachte auch einen großen Teil meiner Freizeit damit, mir Dinge anzueignen, mit denen andere Menschen zu dieser Zeit noch nicht viel anfangen konnten. Ich hatte einen regelrechten Wissensdurst.
Mit der Zeit wurden die Fragen größer. Nicht mehr nur: Wie implementiere ich diese Funktion? Sondern auch: Wie fügt sich das Ergebnis in die bestehende Umgebung ein? Welche Systeme, Schnittstellen und Menschen sind davon betroffen? Wie lässt sich eine Lösung sicher betreiben, weiterentwickeln und über viele Jahre beherrschbar halten?
So übernahm ich zunehmend Aufgaben, die über die reine Softwareentwicklung hinausgingen – von Netzwerktechnik, Systemintegration und technischem Betrieb bis hin zur Architektur. Mein Blick wanderte vom einzelnen Programm immer stärker auf das Zusammenspiel ganzer Systeme.
Heute arbeite ich als Solution Architect in einem globalen Konzern. Die Anwendungsentwicklung habe ich dabei nie hinter mir gelassen. Sie bildet weiterhin das Fundament meines Denkens. Ich kenne die Perspektive des Entwicklers, denke aber ebenso an Integration, Sicherheit, Betrieb, Benutzer und langfristige Veränderbarkeit.
In meinen privaten Projekten kommen all diese Perspektiven wieder zusammen – mit einem wichtigen Unterschied: Hier bestimme ich selbst, welcher Idee ich folge, welche Technologien ich ausprobiere und wie weit ich ein Problem durchdringen möchte.
Mein Ausgleich beginnt mit einem Problem
Wenn ich sehe, dass etwas klarer, robuster oder einfach besser gehen könnte, lässt mich das selten in Ruhe. Aus einer kleinen Idee wird dann schnell ein echtes Projekt – mit Architektur, Oberfläche, Betrieb, Dokumentation und all den Entscheidungen dazwischen.
Das geschieht meistens am Wochenende, manchmal aber auch abends nach Feierabend. Ich empfinde es nicht als Verlängerung meines Arbeitstages. Es ist mein Ausgleich.
Ich kann mich stundenlang mit einer Automatisierung in meinem Smart Home beschäftigen, mein Netzwerk analysieren, Dienste in Docker betreiben oder eine eigene Anwendung entwickeln. Nicht jedes dieser Projekte muss zu einem Produkt werden oder einen für andere Menschen nachvollziehbaren Zweck erfüllen. Manchmal genügt die Frage: Kann ich das besser, einfacher oder überhaupt selbst bauen?
Genau darin liegt für mich die Freude. Ich vertiefe mich in ein Problem, entdecke Zusammenhänge und erlebe den Moment, in dem aus vielen losen Teilen etwas Funktionierendes entsteht. Etwas Eigenes zu erschaffen, macht mir einfach Spaß.
Dabei interessiert mich heute nicht mehr nur der einzelne Codeabschnitt. Früher war das vielleicht ein wenig anders: Ich konnte mich ewig mit einer einzigen Zeile beschäftigen, nur um den Code noch eleganter oder kürzer zu machen.
Inzwischen möchte ich das gesamte System verstehen: Wo liegen seine Grenzen und Abhängigkeiten? Wo trägt die Architektur – und wo nicht mehr? Wie lässt sich eine Lösung später erweitern, ohne dass dabei alles auseinanderfällt?
Eine Lösung fühlt sich für mich erst dann richtig an, wenn ihre Teile nicht nur funktionieren, sondern zusammenpassen.
Zwischen Ingenieur und Produktmensch
Ich denke gern in Architekturen. Aber Architektur ist für mich kein Selbstzweck. Sie muss einem Produkt dienen, verständlich bleiben und den Menschen unterstützen, der damit arbeitet.
Deshalb kann ich mich genauso intensiv mit einer fachlichen Grenze beschäftigen wie mit einem unruhigen Button, einem missverständlichen Begriff oder einem Ablauf, der technisch korrekt ist, sich aber trotzdem nicht richtig anfühlt.
Backend, Frontend, Datenbank, Sicherheit und Betrieb sind für mich keine getrennten Welten. Gemeinsam zeigen sie, wie sorgfältig ein System gedacht wurde.
Ich mag klare Modelle, belastbare Entscheidungen und Software, die nicht bei der ersten echten Anforderung ihre Eleganz verliert. Gleichzeitig weiß ich, dass gute Systeme selten im ersten Anlauf entstehen. Sie werden hinterfragt, verworfen, vereinfacht und manchmal vollständig neu gedacht.
Automatisierung als roter Faden
Automatisierung begleitet mich schon lange. Mich interessiert nicht nur, ob eine Aufgabe technisch gelöst werden kann, sondern auch, ob ein System sie künftig selbstständig, zuverlässig und nachvollziehbar übernehmen kann.
Eine gute Automatisierung soll für mich nicht einfach möglichst viel tun. Sie soll mir wiederkehrende Arbeit abnehmen, auf klaren Regeln beruhen und kontrollierbar bleiben. Ich möchte verstehen, was im Hintergrund geschieht, Entscheidungen nachvollziehen können und jederzeit die Kontrolle über das System behalten.
Mit künstlicher Intelligenz eröffnen sich dabei völlig neue Möglichkeiten. Systeme können nicht mehr nur starre Abläufe ausführen. Sie können Sprache und Inhalte verstehen, Zusammenhänge erkennen und mit Situationen umgehen, die sich nicht vollständig im Voraus durch feste Regeln beschreiben lassen.
Das bedeutet für mich jedoch nicht, dass plötzlich alles KI benötigt.
So deterministisch wie möglich
Trotz meiner Begeisterung für künstliche Intelligenz möchte ich nicht jedes Problem mit KI lösen.
Alles, was sich mit klaren Regeln zuverlässig abbilden lässt, setze ich bevorzugt deterministisch um. Solche Abläufe sind wesentlich schneller, reproduzierbar und nachvollziehbar. Bei identischen Eingaben liefern sie identische Ergebnisse – und wenn etwas nicht funktioniert, lässt sich die Ursache gezielt untersuchen.
KI kommt bei mir nur dort zum Einsatz, wo sie einen tatsächlichen Mehrwert bietet: wenn Sprache verstanden, unstrukturierte Informationen eingeordnet, Zusammenhänge erkannt oder Entscheidungen vorbereitet werden müssen, die sich nicht sinnvoll in starre Regeln übersetzen lassen.
Der stabile Kern einer Anwendung bleibt dabei möglichst konventionell. Datenhaltung, Berechtigungen, Validierung, Zustände und kritische Abläufe sollen nicht von der spontanen Interpretation eines Sprachmodells abhängen. Die KI übernimmt gezielt die Aufgaben, für die ihre besonderen Stärken gebraucht werden – eingebettet in ein System, das ihre Ergebnisse prüft, begrenzt und kontrollierbar macht.
Wo klassische Software die bessere Lösung ist, würde ich keine KI einsetzen.
Für mich bedeutet moderne Softwareentwicklung nicht, möglichst viele Funktionen mit einem Modell zu verbinden. Sie bedeutet, für jedes Problem das passende Werkzeug auszuwählen.
So deterministisch wie möglich. So viel KI wie nötig.
KI – aber möglichst unter eigener Kontrolle
Viele der heute sichtbaren KI-Projekte verfolgen einen anderen Ansatz. In Videos und Showcases wird gezeigt, welche beeindruckenden Ergebnisse sich mit den leistungsfähigsten Frontier-Modellen in der Cloud erzeugen lassen.
Das ist spannend und oft inspirierend. Mich interessiert jedoch eine andere Frage:
Was passiert, wenn aus einer beeindruckenden Demonstration eine Anwendung werden soll, der ich meine eigenen Daten anvertrauen würde?
Genau dort beginnt für mich die eigentliche Herausforderung.
Ich möchte KI nicht nur vorführen, sondern in Systeme integrieren, die im Alltag dauerhaft einen Nutzen haben: Anwendungen, die meine Dokumente durchsuchen, persönliche Informationen verarbeiten, Aufgaben automatisieren oder als intelligenter Dienst beziehungsweise Agent in meinem eigenen Netzwerk arbeiten können.
Dabei verfolge ich einen Local-first-Ansatz. Wo immer es sinnvoll möglich ist, sollen Modelle, Daten und Verarbeitung auf meiner eigenen Hardware bleiben. Die Cloud kann ein Werkzeug sein, aber sie soll nicht automatisch die Voraussetzung für jede Funktion werden.
Es geht mir dabei nicht um eine grundsätzliche Ablehnung der Cloud. Leistungsfähige Cloud-Modelle helfen mir schon heute beim Denken, Entwickeln und Prüfen. Beim fertigen System möchte ich jedoch bewusst entscheiden können, welche Daten mein eigenes Netzwerk verlassen – und welche nicht.
Ich möchte Anwendungen bauen, die auch dann einen Wert besitzen, wenn keine persönlichen Dokumente, Gespräche oder internen Informationen an einen externen Dienst übertragen werden. Systeme, deren Datenwege ich kenne, deren Verhalten ich nachvollziehen kann und über die ich selbst die Kontrolle behalte.
Das ist technisch häufig schwieriger als ein schneller Cloud-Showcase. Lokale Modelle sind kleiner, die verfügbare Hardware ist begrenzt und viele Aufgaben erfordern mehr Architektur, Optimierung und eigene Infrastruktur.
Gerade das macht diese Projekte für mich interessant.
Mich fasziniert nicht nur, was mit dem größten verfügbaren Modell möglich ist. Mich fasziniert die Frage, wie viel sich mit guter Architektur, spezialisierten Modellen, Automatisierung und der richtigen Aufgabenteilung auf der eigenen Hardware erreichen lässt.
Agenten als neuer Hebel
Besonders fasziniert mich der Gedanke, mehrere spezialisierte Agenten zu orchestrieren, ihnen unterschiedliche Aufgaben zu übertragen und ihre Ergebnisse zu einem gemeinsamen Ganzen zusammenzuführen.
Ein Agent kann eine Fragestellung untersuchen, ein anderer an der Umsetzung arbeiten und ein weiterer mögliche Schwächen, Fehler oder Widersprüche prüfen. Dabei geht es nicht darum, Verantwortung an eine KI abzugeben. Es geht darum, Aufgaben sinnvoll zu zerlegen und verschiedene Fähigkeiten gezielt miteinander zu verbinden.
Für mich ist das ein enormer Hebel. Bei manchen Aufgaben kann ich heute gefühlt zehnmal schneller arbeiten – möglicherweise sogar noch schneller.
Der eigentliche Gewinn besteht dabei nicht darin, in kürzerer Zeit möglichst viel Code zu erzeugen. Ich kann Ideen früher ausprobieren, mehrere Lösungswege untersuchen, Fehler schneller erkennen und Projekte in einer Tiefe verfolgen, die in meiner begrenzten Freizeit sonst kaum erreichbar wäre.
KI ist für mich keine Spielerei, bei der man einen Prompt schreibt und ein fertiges Produkt zurückbekommt. Das mag in Einzelfällen funktionieren. Ich erlebe KI jedoch als ein neues Werkzeug, mit dem ich viele Schritte verbessern und beschleunigen kann – und zunehmend als echten Denkpartner.
Das funktioniert nur, wenn man selbst die Richtung vorgibt: Anforderungen präzisiert, Aufgaben sinnvoll zerlegt, Ergebnisse hinterfragt und Widersprüche nicht einfach hinnimmt. Aus einer plausiblen Antwort wird erst durch Prüfung, Einordnung und Weiterentwicklung eine tragfähige Lösung.
Die Geschwindigkeit kommt von der KI. Richtung, Urteil, Daten und Verantwortung sollen so weit wie möglich bei mir bleiben.
Warum Operus existiert
In meinen Abend- und Wochenendprojekten entstehen ständig Erkenntnisse, die im fertigen Ergebnis nicht mehr sichtbar sind. Sie stecken in Fehlversuchen, Diskussionen mit der KI, Architekturentscheidungen und in den kleinen Momenten, in denen aus einer komplizierten Lösung plötzlich eine klare wird.
Operus ist mein Versuch, diese Arbeit sichtbar zu machen. Nicht als beruflich inszeniertes Portfolio, nicht als Sammlung austauschbarer Tutorials und nicht als Bühne für nachträgliche Perfektion.
Es ist mein Hobby – und ich möchte dich daran teilhaben lassen.
Operus ist mein technisches Journal über Systeme, die in meiner Freizeit tatsächlich entstehen: mit ihren Ideen, Entscheidungen, Umwegen und gelegentlichen Neuanfängen.
Ich möchte nicht nur fertige Ergebnisse präsentieren. Mich interessiert, wie aus einer Idee ein Projekt wird, warum bestimmte Entscheidungen getragen haben, welche Alternativen nicht funktioniert haben und was ich beim nächsten Mal anders machen würde.
Was du hier erwarten kannst
Ich schreibe über technische Themen, Softwareentwicklung, Architektur, Smart Home, Netzwerke, Automatisierung, künstliche Intelligenz und die Entstehung eigener Produkte. Vor allem schreibe ich aber auch über die Entscheidungen dazwischen.
Die Themen werden unterschiedlich sein, aber sie haben einen gemeinsamen Ursprung: die Freude daran, Technik zu verstehen, miteinander zu verbinden und etwas Eigenes daraus zu bauen.
Operus soll weder laut noch beliebig sein. Ich möchte Dinge mit Substanz festhalten – ehrlich genug, um auch über Irrwege zu sprechen, und konkret genug, damit andere daraus etwas für ihre eigenen Projekte mitnehmen können.
Wenn mich dabei ein Gedanke begleitet, dann dieser:
Gute Systeme entstehen nicht dadurch, dass man möglichst viel Technik verwendet. Sie entstehen, wenn Neugier, Erfahrung und Sorgfalt lange genug an demselben Problem arbeiten.
Damit weißt du nun eine ganze Menge über mich und meine Motivation hinter Operus. Jetzt freue ich mich darauf, dir hier die Projekte, Ergebnisse und Erfahrungen zu zeigen, die aus dieser Begeisterung entstehen.
Vielleicht kommen später noch weitere Formate hinzu. Im Mittelpunkt bleibt jedoch das, worum es mir von Anfang an ging: Dinge zu erschaffen, meine Erfahrungen ehrlich zu teilen und andere auf diesem Weg mitzunehmen.
Viel Spaß beim Lesen!
Oliver