In 2026, I want less complexity and more results

If I could change one thing in 2026, it would be complexity. Seriously... it drives me crazy.

We built the digital world to make our lives easier. To work faster. Less hassle. More control. But somewhere along the way, that goal got buried under layer upon layer upon layer. It seems as if we've come to believe that “complicated” is synonymous with “professional.” As if opacity is a sign of maturity. As if every extra step adds safety, quality, or certainty. In reality, we mainly add friction.

Complexity is the silent cost that no one owns. It's not in one tool, one team, or one decision. It grows because everyone optimizes locally and no one dares to simplify the whole. It grows because we are afraid to take anything away. Because we want to cover everything, measure everything, be able to do everything, automate everything.

And in the meantime, we forget the simple question: does it still work for the people who have to use it?

What complexity really does is steal our pace. It makes change more expensive than it should be. It makes incidents more likely than they need to be. It makes knowledge scarce, because no one can see the whole picture anymore. And it makes organizations dependent: on specific suppliers, specific specialists, specific tricks.

And all of that can, no, must be reduced and preferably stopped by 2026.

If we want to move forward in 2026, we must not stack things even more ‘smartly’. We must be bold enough to cut things out. Not as minimalism for show, but as a strategy. Complexity is not a law of nature. It is a choice. And so we must also choose differently.

Abstraction as a goal does not make your system mature

A lot of abstraction feels mature. Until you have to work with it.

A practical example: I analyzed a logistics project where a DBA had conceived a plan to disconnect everything from the database version and the technical data model. The goal sounded good: to be able to perform upgrades and modify the data model without having to change the application. Fewer dependencies. Less maintenance. More freedom.

However, freedom does not come for free.

To ‘prove’ this decoupling, a structure of views upon views upon views was created. Every change was wrapped in yet another layer, so that the outside remained the same. Elegant on paper. In practice, the database became a maze. One without a map.

And databases have one great superpower: optimization. They are built to view a query, make smart choices, utilize indexes, weigh paths, and deliver quickly. But if you hide the logic behind a stack of abstraction layers, the optimizer no longer sees the intention. Only fog. And then it starts guessing. With predictable results.

In that practical example, the queries didn't just become “a little slower.” They became absurdly slow. Not “go get some coffee” slow. But “take a week's vacation” slow. The software did exactly what it was supposed to do, but the answer came too late to be of any value. The DBA had really done his best, but the backfire turned out to be unexpectedly large.

Look, portability can be useful sometimes. Especially if you really need to be able to switch platforms or suppliers. But usually it's a solution, a way to avoid having to choose. And if you don't choose, you still end up choosing: extra layers, extra complexity, extra costs, and less performance.

The point is simple: abstraction is not a virtue. It is a means to an end. Use it where it adds value and dare to leave it out where it paralyses your tools.

How to buy complexity with a “best practice”

Not having the right framework is one of the quickest ways to buy complexity instead of avoiding it.

Frameworks are not gospel. They are tools, designed for a specific type of organization, with a specific scale and a specific type of digitization. As soon as you overlook that, or fail to explain it sufficiently, you end up following a recipe that is intended for a different menu.

Take the Microsoft Cloud Adoption Framework (CAF). If you have a medium-sized cloud environment with, say, 20–50 applications, it can work very well: it aligns language, roles, and steps. But if the number of applications is lower, CAF quickly becomes a bureaucratic solution with a hefty price tag. You build processes, governance, and rituals that are heavier than the environment you are trying to manage. So you're mainly paying for “looking good.”

If you go far above that 20-50 scale, the opposite problem arises. The framework can cut your infrastructure and organization so finely that your complexity explodes. Teams lose overview, dependencies pile up, network flows become unnecessarily complicated, and the incident that initially had one cause suddenly has ten possible causes. Seriously, I've seen this happen more than once. Then you're not steering. Then you're searching.

And then there is the nature of your digitization. CAF is primarily oriented towards administrative and business processes. If you push it into areas where speed, determinism, and chain logic are crucial, you end up with a solution that looks neat but is poorly suited. The result is predictable: extra layers, extra transfers, extra costs, and less control.

The problem is rarely the framework. The problem is that we choose it as if it were a standard, rather than a tool.

Starting big: the fastest route to becoming a juggernaut

Starting too big is how you build complexity before you even deliver value.

I hear it more often than I drink coffee at project kickoffs: “It has to be able to grow to 5,000 users.” And so, from day one, we design as if those 5,000 users will be there tomorrow. Not because it's necessary, but because it feels safe. Because no one wants to be blamed later for “not being scalable.” And because no one warns about the consequences. So I do.

The consequence is predictable to me. We roll out a Kubernetes landscape that can scale in all directions, while there is no product yet that is worth scaling. We are building a four- or five-layer architecture “for separation” even before there are any real dividing lines. We are inventing APIs, events, links, and integration patterns “that we will definitely need later,” even though later is still just a hypothesis.

And so, instead of a modern system, we end up with a cumbersome juggernaut. Lots of moving parts, little speed. Lots of components to manage, little functionality that really matters. The architecture becomes the project. The complexity becomes the planning. And performance becomes something you solve “later.” If everything runs stably at all.

The better route is painfully simple: start small, but don't be naive. First build a compact version that does what it needs to do. Not as a prototype that you throw away, but as a foundation that you understand. Measure. Learn. See where the real pressure arises: usage, data, transactions, peaks, dependencies. And only then add complexity, step by step, in places where it demonstrably delivers value.

Scaling up is not a virtue. It's timing. Too late is expensive. Too early is ‘deadly’. Those who build for 5,000 from the outset often end up with 50 users... and 5,000 problems. And that's not even mentioning the invoice...

Time to eliminate complexity

It is the beginning of 2026. Complexity does not disappear on its own.

You can learn to live with it. You can put dashboards on it. You can add another layer of governance on top of it.

But then you will pay for it, not only in euros, but also in speed, peace of mind, and agility.

If you want to reduce or prevent complexity, you have to do one thing: dare to make choices again. What should be included? What can be left out? What is really necessary for your scale, your processes, and your risks?

At Sciante, we have been doing this for more than 15 years. We help organizations make systems understandable again, drastically reduce costs, get performance in order, and give teams back control over their own IT. Not with an extra framework on top, but by adding just enough structure and cutting away the rest.

Want to know where most of your complexity is leaking and what is the fastest route to simplicity?

Schedule a no-obligation appointment with me!

In 30 minutes, you will have a clear picture of where you are unnecessarily piling things up, what choices you can make, and what you need to eliminate first in order to pick up the pace again. Those 30 minutes will most likely bring you more than you expect: in addition to insights, you will also see immediate savings opportunities.