I was fifteen or sixteen when I first gained experience with corporate networks. Back then, we worked with 486 PCs, MS-DOS and an IT world in which much was still easy to understand directly.
Even then, I was less interested in the individual computer than in what happened between computers.
How do you connect systems securely? What needs to remain separate? How do you make sure a network continues to work reliably when something goes wrong?
Air-gapped systems made a particularly lasting impression on me — networks deliberately isolated from public networks. In those environments, security meant knowing exactly which connections existed and which did not.
Technologically, it was a different era. The questions have remained surprisingly relevant.
Between Computer Science and Economics
My academic path led me not into computer science, but into economics at the University of Bonn.
There, I studied markets, economic decisions and how people and systems respond to information. Through my work in the university's IT service group, I also stayed closely connected to technology and to many professors. One of the memorable encounters during that time was with Nobel laureate in economics Reinhard Selten.
I wrote my diploma thesis on momentum strategies in capital markets.
The connection between economics, mathematics and technology has stayed with me ever since. I became deeply interested in automated trading systems — and still enjoy working on them in my spare time.
Financial markets have an interesting characteristic: a model can look convincing for a long time and still fail when conditions change.
You learn to distinguish between an assumption and evidence. Between a successful calculation and a sound decision.
That distinction matters just as much in IT architecture.
When Systems Work — but Nobody Has Them Under Control
In my later work with small and medium-sized businesses, I repeatedly encountered a similar pattern.
The servers were running. Applications did their jobs. Individual departments had organized their processes. Often, a great deal had been done right over many years.
And yet something was missing.
Nobody could readily explain how all the parts fitted together. Who was responsible for particular interfaces. Which dependencies had developed in the background. Or how quickly a critical business process could actually be restored after an outage.
The problem was often not a lack of technology.
What was missing was a shared understanding of the system.
Today, we can do far more than we could then. Identities, network segmentation, policy gateways and automated configuration allow us to define technical boundaries in more nuanced ways than fully isolated networks alone.
But even a modern security policy is initially just a policy. What matters is whether it actually works — and whether someone can verify its effect.
Perhaps that is the most important lesson from all these years: new technology changes what we can do. It does not remove our responsibility for the consequences.
Web3 Put This Conviction to the Test
Through Web3 and running validators, we wanted to put that thinking into practice.
Not just install systems and hope they would run. But develop infrastructure that meets demanding requirements for security, monitoring, recovery and availability.
A validator does not work office hours.
It is part of a network that keeps running around the clock. Errors, connection problems and incorrect configurations can have immediate operational consequences.
That sharpened my view of architecture once again.
We wanted to understand how far we could apply enterprise principles in an environment that is constantly changing. What could be automated. Which risks could be reduced. And where a person still needs to understand and decide.
Those experiences are more valuable than any architecture slide.
Because operations reveal which assumptions actually hold up.
And Now We Are Developing with AI
Today, I am interested in AI agents for a similar reason.
The progress is remarkable. In a short time, an agent can write code, change applications, run tests and take on tasks that previously required substantially more manual work.
That opens up enormous possibilities — including for small teams.
But I share an experience many developers are now having: a system that produces good code is not necessarily a reliable operator.
An agent can complete a task successfully while still crossing a security boundary, skipping an important check or relying on an incorrect assumption.
That is why we are working on isolated execution environments, clear permissions, separate roles, automated checks and decisions that can be traced and understood.
We want to use the speed without giving up control.
AI makes it particularly clear to me that architecture is more than the sum of individual tools.
Why This Led to ALTONJI
Over the years, these different experiences have developed into a shared way of thinking.
I call it I|S|P.
Infrastructure. Systems. Processes.
Secure infrastructure provides the technical foundation. Clear systems architecture connects applications, data and responsibilities. Reliable automation makes processes understandable and repeatable.
For me, the I|S|P principle is not a rigid method. It is a way of looking at problems before we start building solutions.
Because the most important question is often not which technology we should use next.
It is whether we have understood the real problem yet.
ALTONJI is where I want to develop and share this way of thinking, alongside the practical work that grows out of it.
That includes architecture decisions, open-source projects, experiences from infrastructure and validator operations, and the development of our own AI platform.
I also want to write about things that did not work the first time. About technical dead ends, revised judgments and the decisions behind them.
Not as a success story polished in hindsight, but as transparently as we responsibly can.
And Why Here, of All Places?
After university, my path took me as far as New York City.
At some point, though, I realized that professional opportunities and personal happiness do not necessarily exist in the same place.
My family is in the Rhineland. My friends are here. It is where I feel at home.
The Paveier sing: “Heimat es do, wo de glöcklich bes.” — home is where you are happy.
I think there is a beautiful truth in that.
I do not have to leave everything behind to build something new. I can be rooted here and still be open to the world — to new technologies, unusual ideas and people with whom we can make a difference.
Perhaps that also explains why I now prefer to follow my own path.
I want to keep learning, experimenting and building things. With the experience of three decades in IT, with an economic perspective and with the curiosity that first brought me to a 486 as a teenager.
The technology has changed. The ambition remains: understand what we build. And take responsibility for making it work.