Technology
What two decades between research labs and a company have taught me about the systems I build.
Teams
Since my first years in research I have tried to build strong teams of very talented people around me. That has not changed at Nearby Computing: a solid team of architects and developers with a mix of skills are now my partners, co-founders of the company, and together we run its core.
I believe teams are the soul of any project. Without a balance of attitudes and profiles, technology does not become impactful, however good it is.
Where should this run?
Almost everything I have worked on comes back to one question: where should a piece of work run, and when, so that shared infrastructure does what it was meant to? I asked it first about application servers, then about mixed batch and transactional workloads, MapReduce jobs, GPUs for learning, and today about AI models spread across clouds, edge sites and GPU factories.
The workloads change every few years. The question does not, and I have come to think it is never answered once: it has to be answered again, continuously, as demand, failures and prices move.
Say what you want, let software keep it true
I prefer systems where people state the outcome they want and software keeps it that way. People are good at deciding intent; they are bad at keeping thousands of sites consistent by hand, at three in the morning, during an incident.
That idea runs from the autonomic computing work I did with IBM Research to the reconciliation loops in today’s platforms. What has changed is the reach: it now has to extend from the data centre to the network and to the device at the edge.
Infrastructure is distributed again
For twenty years computing concentrated in large data centres. Now it is spreading out again, to factories, stores, cell sites and sovereign regions, because latency, data, regulation and energy say it must.
I do not think the answer is to manage each of those places separately. A distributed estate should be operated as one system, with one view of what runs where and why, whatever the vendor underneath.
AI is a systems problem
Models get the attention, but in my experience the hard part of AI in an organisation is not the model. It is placement, connectivity, identity, isolation and cost: the same distributed systems problems, with tokens and GPUs added.
My research ran the other way round, using machine learning to help run data centres. Both directions matter now: AI to operate infrastructure, and infrastructure that can run AI safely wherever it has to be.
Control stays with whoever owns the data
I am European, and I care about who controls the data and the models. Organisations should be able to decide where their AI runs, see what leaves their perimeter, and change suppliers without starting again.
Open standards and open-source building blocks are how that becomes practical rather than a policy document. Sovereignty is an engineering property, not a label.
From the lab to production
Research taught me to measure before believing anything about performance. Building a company taught me something research rarely does: the real work is making an idea dull and dependable on somebody else’s infrastructure, years after the paper.
I still think the best technology comes out of that loop, with ideas tested in production and production problems sent back to research.