Sovereignty without autonomy solves nothing

Digital sovereignty is a hot topic and rightly so. But if you think a European cloud or a Dutch supplier automatically delivers more freedom you are looking at the wrong problem. Because you can be fully sovereign and still be completely stuck.

The drive towards sovereignty is a healthy development. The only risk is that it creates confusion too. Because what good is a Dutch supplier if you can never leave them? What good is a European cloud if switching costs are so high, and carries so much risk, that no one seriously attempts it? That's where the difference between sovereignty and autonomy lies.

The market confuses two different problems

Sovereignty is about control. About who can exert influence over technology, data and infrastructure. Autonomy is about freedom of choice. Can you still change course if you want to leave your supplier? That may sound like a small difference, but in practice it leads to completely different choices.

An organisation can fully comply with every requirement around digital sovereignty and, at the same time, have hardly any room to manoeuvre. You see this, for example, when software, hosting, management, support and further development are sold as a single package. If everything works well, it seems efficient. But problems arise once an organisation wants to change something.

It then turns out that data is difficult to export, and integrations have to be rebuilt. To make matters worse, all the crucial knowledge sits with a single supplier, and a migration has such an impact that the existing situation is forced to remain in place. On paper, there's freedom of choice. In practice, change becomes increasingly difficult.

That's exactly why autonomy is ultimately far more important than sovereignty. After all, autonomy determines how much freedom an organisation retains.

Digital autonomy requires decoupling on three levels

Autonomy is a consequence of architectural choices. It starts with decoupling three things that are still too often entangled with one another: infrastructure, applications and service delivery.

An application that can only run in one specific cloud environment limits your room to manoeuvre. The same applies to software you can't replace without a full migration process. And service delivery, too, can become a source of dependency when management, knowledge and further development all end up with a single party. In all these situations, a huge problem arises: a change in one place has a direct impact on the rest of the landscape.

Real autonomy therefore requires an architecture in which these components can move independently of each other. As an organisation, you should be able to switch infrastructure without rebuilding your applications. Replacing an application should be possible without having to adjust dozens of other systems. And if you want to switch service providers, you don't want to immediately lose control over your technology. Only once you've arranged that does genuine freedom of choice emerge.

Convenience is autonomy's biggest enemy

No organisation deliberately chooses lock-in. Dependency arises because convenience almost always wins. It starts innocently. A supplier delivers software and offers hosting alongside it. Then management, monitoring, authentication and support get added. And why not throw in integrations and further development while you're at it.

Every individual choice is defensible. But together, these choices cause more and more parts of the landscape to get intertwined. You see this with cloud platforms, but just as much with ERP systems, CRM solutions and sector-specific software. Suppliers have an interest in delivering as large a share of the landscape as possible. It’s good for their business model after all.

The more components become linked to one another, the smaller the chance that a customer leaves. That's precisely why autonomy must be an explicit design principle.

Without decoupling, there is no autonomy

Anyone who takes autonomy seriously as a design principle soon ends up at integration. A great deal of dependency arises because systems are connected directly to one another. Every new point-to-point integration makes change harder. Over time, a landscape emerges in which no one knows anymore which systems depend on and connect to each other.

The consequence is easy to guess. Every replacement becomes a project, and migrations always carry risk. That puts a considerable brake on innovation. A good integration layer ensures that applications can be replaced without all the surrounding systems having to change along with them. That creates room for infrastructure, applications and service delivery to evolve independently of one another. And that's exactly where integration connects directly to autonomy.

You must organise autonomy in advance

“Autonomy — ah, we’ll look at that later.” For most organisations, it isn't the starting point. And that's a mistake. Autonomy can't be created after the fact. You build it in during the selection of software, in architectural choices, during tenders and when designing integrations.

That's why you shouldn't just look at what a solution can do today. What you really want to know is how much freedom remains once circumstances change. A supplier might simply raise its prices or be acquired. Or you might just want a better solution.

Confuse autonomy with sovereignty, and you run a serious risk. The technology can be great, but problems arise when one dependency is unknowingly traded for another. 

How much freedom do you really have left?

The debate about digital sovereignty is valuable and necessary. But organisations that genuinely want to reduce their dependencies need to look beyond the location of a data centre or the nationality of a supplier. How much freedom do you have left if you want to make a change tomorrow?

Ready to make autonomy concrete?

At WeAreFrank!, we help organisations make dependencies visible and build digital autonomy step by step. With the open source Frank!Framework, we create an integration layer that decouples systems so organisations retain freedom of choice, even as suppliers, technologies or strategies change.

Curious how much room to manoeuvre is left in your IT landscape? Schedule a no-obligation advisory conversation. Then we'll look together at where the dependencies lie and how you can reduce them.