Why I build the way I build.

My first project was a migration to a new data platform. That is where I quickly learned what vendor lock-in means in practice: your core infrastructure becomes entangled with one large vendor. Because of vendor-specific tooling, you cannot simply pack up your things and leave. The whole system has to be unravelled first and moved over piece by piece. That is why data platform migrations are painful, take years, and turn out expensive.

The fact that something meets every requirement on paper and is well argued does not mean it works for the people who have to build with it. When a platform is chosen, other interests come into play, ones that often do not match how users, developers, and even the architects handle it in practice.

Fortunately there is an alternative. In just a few years the range of open source data tools has grown enormously, and more and more of those tools are being embraced as the standard by established players. The developments follow one another gradually, but the direction is clear: open standards, workable and interchangeable.

The path runs from company-specific software toward modules you add or remove as soon as the company's needs change. The benefits are obvious. Developers converge on the same open tools, which makes the right expertise easier to find. And because the software is open source, it stays stable and maintained for years, independent of any single vendor.

I carry this development through to its logical conclusion. The building blocks of a data infrastructure should be simple to use and easy to replace. Every part of the platform should be migratable within a day. That way, what I build stays future-proof and easy to hand over. The platform is then no longer a risk, but a foundation to build on.