Ich war fünfzehn oder sechzehn, als ich meine ersten Erfahrungen mit Firmennetzwerken sammelte. Damals arbeiteten wir mit 486er-Rechnern, MS-DOS und einer IT-Welt, in der vieles noch unmittelbar nachvollziehbar war.
Schon damals interessierte mich weniger der einzelne Computer als das, was zwischen den Computern geschah.
Wie verbindet man Systeme sicher miteinander? Was muss voneinander getrennt bleiben? Wie stellt man sicher, dass ein Netzwerk auch dann zuverlässig funktioniert, wenn etwas schiefgeht?
Besonders geprägt haben mich sogenannte Air-Gap-Systeme – Netzwerke, die bewusst von öffentlichen Netzen isoliert wurden. Sicherheit bedeutete dort, sehr genau zu wissen, welche Verbindungen existierten und welche nicht.
Technologisch war das eine andere Zeit. Die Fragen sind erstaunlich aktuell geblieben.
Zwischen Informatik und Volkswirtschaft
Mein akademischer Weg führte mich nicht in die Informatik, sondern in die Volkswirtschaftslehre an der Universität Bonn.
Dort beschäftigte ich mich mit Märkten, wirtschaftlichen Entscheidungen und der Frage, wie Menschen und Systeme auf Informationen reagieren. Durch meine Arbeit in der universitären IT-Service-Gruppe hatte ich gleichzeitig weiterhin engen Kontakt zur Technik und zu vielen Professoren. Zu den besonderen Begegnungen dieser Zeit gehörte auch der Wirtschaftsnobelpreisträger Reinhard Selten.
Meine Diplomarbeit schrieb ich über Momentum-Strategien am Kapitalmarkt.
Die Verbindung von Wirtschaft, Mathematik und Technologie hat mich seitdem nicht mehr losgelassen. Ich beschäftigte mich intensiv mit automatisierten Handelssystemen – und tue das bis heute gern in meiner Freizeit.
Finanzmärkte haben eine interessante Eigenschaft: Ein Modell kann lange überzeugend aussehen und trotzdem unter veränderten Bedingungen scheitern.
Man lernt, zwischen einer Annahme und einem Nachweis zu unterscheiden. Zwischen einer erfolgreichen Berechnung und einer tragfähigen Entscheidung.
Diese Unterscheidung ist auch für IT-Architektur entscheidend.
Wenn Systeme funktionieren – aber niemand sie beherrscht
In meiner späteren Arbeit mit mittelständischen Unternehmen begegnete mir immer wieder ein ähnliches Muster.
Die Server liefen. Anwendungen erfüllten ihre Aufgaben. Einzelne Abteilungen hatten ihre Prozesse organisiert. Oft wurde über Jahre hinweg sehr viel richtig gemacht.
Und trotzdem fehlte etwas.
Niemand konnte ohne Weiteres erklären, wie alle Teile zusammenhingen. Wer für bestimmte Schnittstellen verantwortlich war. Welche Abhängigkeiten im Hintergrund entstanden waren. Oder wie schnell sich ein kritischer Geschäftsprozess nach einem Ausfall tatsächlich wiederherstellen ließe.
Das Problem war häufig nicht fehlende Technologie.
Es fehlte ein gemeinsames Verständnis des Systems.
Heute können wir wesentlich mehr als früher. Mit Identitäten, Netzwerksegmentierung, Policy-Gateways und automatisierter Konfiguration lassen sich technische Grenzen differenzierter gestalten als mit vollständig isolierten Netzwerken allein.
Aber auch eine moderne Sicherheitsregel ist zunächst nur eine Regel. Entscheidend ist, ob sie tatsächlich wirkt – und ob jemand ihre Wirkung überprüfen kann.
Vielleicht ist das die wichtigste Erkenntnis aus all diesen Jahren: Neue Technologie verändert unsere Möglichkeiten. Sie nimmt uns nicht die Verantwortung für ihre Folgen ab.
Web3 hat diese Überzeugung auf die Probe gestellt
Mit Web3 und dem Betrieb von Validatoren wollten wir genau das praktisch erproben.
Nicht nur Systeme installieren und hoffen, dass sie laufen. Sondern Infrastruktur entwickeln, die hohen Anforderungen an Sicherheit, Monitoring, Wiederherstellung und Verfügbarkeit gerecht wird.
Ein Validator arbeitet nicht nach Bürozeiten.
Er ist Teil eines Netzwerks, das rund um die Uhr weiterläuft. Fehler, Verbindungsprobleme und falsche Konfigurationen können unmittelbare operative Konsequenzen haben.
Das hat meinen Blick auf Architektur noch einmal geschärft.
Wir wollten wissen, wie weit wir Enterprise-Prinzipien in einer Umgebung anwenden können, die ständig in Bewegung ist. Was sich automatisieren lässt. Welche Risiken sich reduzieren lassen. Und an welcher Stelle ein Mensch weiterhin verstehen und entscheiden muss.
Solche Erfahrungen sind wertvoller als jede Architekturfolie.
Denn im Betrieb zeigt sich, welche Annahmen tatsächlich tragen.
Und jetzt entwickeln wir mit KI
Heute beschäftigen mich KI-Agenten aus einem ähnlichen Grund.
Die Fortschritte sind bemerkenswert. Ein Agent kann innerhalb kurzer Zeit Code schreiben, Anwendungen verändern, Tests ausführen und Aufgaben übernehmen, für die früher erheblich mehr manuelle Arbeit notwendig war.
Das eröffnet enorme Möglichkeiten – auch für kleine Teams.
Aber ich teile eine Erfahrung, die viele Entwickler inzwischen machen: Ein System, das guten Code erzeugt, ist noch lange kein zuverlässiger Operator.
Ein Agent kann eine Aufgabe erfolgreich abschließen und dabei trotzdem eine Sicherheitsgrenze übergehen, eine wichtige Prüfung auslassen oder eine falsche Annahme übernehmen.
Deshalb beschäftigen wir uns mit isolierten Ausführungsumgebungen, klaren Berechtigungen, getrennten Rollen, automatisierten Prüfungen und nachvollziehbaren Entscheidungen.
Wir wollen die Geschwindigkeit nutzen, ohne die Kontrolle aufzugeben.
Gerade bei KI wird für mich deutlich, dass Architektur mehr ist als die Summe einzelner Werkzeuge.
Warum daraus ALTONJI entstanden ist
Aus diesen unterschiedlichen Erfahrungen ist über die Jahre eine gemeinsame Denkweise entstanden.
Ich nenne sie I|S|P.
Infrastructure. Systems. Processes.
Sichere Infrastruktur schafft die technische Grundlage. Klare Systemarchitektur verbindet Anwendungen, Daten und Verantwortlichkeiten. Verlässliche Automatisierung sorgt dafür, dass Abläufe nachvollziehbar und wiederholbar werden.
Das I|S|P-Prinzip ist für mich keine starre Methode. Es ist eine Art, Probleme zu betrachten, bevor wir anfangen, Lösungen zu bauen.
Denn oft ist die wichtigste Frage nicht, welche Technologie wir als Nächstes einsetzen.
Sondern ob wir das eigentliche Problem schon verstanden haben.
ALTONJI ist der Ort, an dem ich diese Denkweise weiterentwickeln und teilen möchte. Gemeinsam mit der praktischen Arbeit, die daraus entsteht.
Dazu gehören Architekturentscheidungen, Open-Source-Projekte, Erfahrungen aus dem Infrastruktur- und Validator-Betrieb und unsere Entwicklung einer eigenen KI-Plattform.
Ich möchte dabei auch über Dinge schreiben, die nicht auf Anhieb funktioniert haben. Über technische Sackgassen, veränderte Einschätzungen und die Entscheidungen dahinter.
Nicht als nachträglich geglättete Erfolgsgeschichte, sondern so nachvollziehbar, wie es verantwortungsvoll möglich ist.
Und warum ausgerechnet hier?
Nach meinem Studium führte mich mein Weg bis nach New York City.
Irgendwann wurde mir aber klar, dass berufliche Möglichkeiten und persönliches Glück nicht zwangsläufig am selben Ort liegen.
Meine Familie ist im Rheinland. Meine Freunde sind hier. Es ist der Ort, an dem ich mich zu Hause fühle.
Die Paveier singen: „Heimat es do, wo de glöcklich bes.“
Ich finde, darin steckt eine schöne Wahrheit.
Ich muss nicht alles hinter mir lassen, um etwas Neues aufzubauen. Ich kann hier verwurzelt sein und trotzdem offen für die Welt bleiben – für neue Technologien, ungewöhnliche Ideen und Menschen, mit denen sich etwas bewegen lässt.
Vielleicht erklärt das auch, warum ich heute lieber meinen eigenen Weg gehe.
Ich möchte weiter lernen, experimentieren und Dinge bauen. Mit der Erfahrung aus drei Jahrzehnten IT, mit wirtschaftlichem Denken und mit der Neugier, die mich schon als Jugendlichen vor einen 486er gesetzt hat.
Die Technik hat sich verändert. Der Anspruch ist geblieben: Verstehen, was wir bauen. Und Verantwortung dafür übernehmen, dass es funktioniert.