Okay, what are we talking about?
I previously wrote a blog post about Digital Sovereignty. In it, I explored what constitutes a good definition of the concept. The European Commission provides an excellent starting point for this. This “Cloud Sovereignty Framework” is very useful. In my opinion, the European Commission is demonstrating leadership in this area. The key point is that Digital Sovereignty is much more than just Data Sovereignty. As Gartner points out, there is
- Technological Sovereignty,
- Data Sovereignty,
- Operational Sovereignty
Incidentally, in most organizations, the discussion is limited to data sovereignty. This became clear during two roundtable discussions I had the opportunity to lead. This overlooks the most difficult part: our dependence on U.S. technology, both hardware and software. I think the topic of data sovereignty warrants its own blog post.
What also surprises me, by the way, is that these are apparently viewed as three unrelated topics. In my opinion, you can’t achieve Data Sovereignty if you’re technologically dependent. Likewise, “Operation Sovereignty” is an illusion if you don’t have “Data Sovereignty” in place. I’m increasingly convinced that it all comes down to “Technological Sovereignty”—specifically, dependence on U.S. technology. And yes, that applies to both hardware and software.
What did I learn during the roundtable discussions? A telecom provider from a northern country mentioned that, in the event of an invasion, they would also want to be able to retrieve their data from the cloud. I hadn’t considered this aspect before. The question that immediately came to mind was: even if you get your data back, how do you know it’s been removed from the cloud? Is it even possible to determine that?
Risk Mitigation
From an architectural standpoint, this entire discussion is about risk mitigation. We’ve always done that, but a geopolitical risk has now been added to the mix. Namely, our dependence on American tech. The Netherlands is completely dependent on Microsoft Office, for example. I can’t complete a project without coming into contact with it. Try avoiding it as a professional—good luck with that. Incidentally, the alternatives all come from the U.S. as well. Personally, I use Apple hardware, Google, Microsoft, and AWS. This risk diversification therefore has a weak point: it’s all U.S. tech.
The exception to this is my old MacBook running Ubuntu. While the hardware is based on American technology, the software is not. My Proton account is also fairly free of American technology. But my employer doesn’t allow me to use any of it. It’s not secure and isn’t managed. This is in contrast to my Windows laptop, which is completely locked down. That one is considered secure, even though the BitLocker keys have since been handed over to the FBI.
But as I said, it’s all about risk mitigation. From an architectural standpoint, I wonder: exactly which geopolitical risk are you trying to mitigate? We’re always dependent on something, but are you free to choose which dependencies to cut? Or do you accept a dependency because you don’t want to go through the pain of breaking free from it? I’ve sometimes compared it to drugs—you have to go cold turkey to get rid of them. But then you’ve regained your freedom.
Hardware and Software Dependencies
It seems to me that it would be very difficult to find alternatives to U.S.-based hardware. They do exist, though—for example, my employer is developing its own computer chips. There’s also an interesting twist to our dependence on U.S.-based hardware: the machines used to manufacture those chips come from the Netherlands. Anyway, I don’t see this changing anytime soon.
When it comes to software, there’s more to be gained. There are many open-source alternatives to U.S.-based software. I’m not going to make a list of alternatives—one already exists. The alternatives might not be as polished and may take some getting used to. But they do work. This way, you remain in control of the functionality and its availability. In other words, operational sovereignty. And open-source software also comes with open standards. These open standards ensure that you remain in control of your own data—an important aspect of data sovereignty. In my opinion, open-source software lets you kill two birds with one stone.
However, implementing open-source software successfully does require sufficient knowledge and experience. You won’t be guided step by step; you’ll have to figure out a lot on your own. This touches on the capabilities of the IT organization. I’ve written about this before, but this topic also deserves its own blog post.
So that's not what we're talking about here
Once again, we see the value of open-source software. And yet this is rarely, if ever, discussed. The European Commission, however, is once again addressing the issue. It aims to promote commercial open-source software. Various organizations are working on alternatives to their U.S.-based software. France, for example, has opted for an alternative to Zoom. And once again, this isn’t about cost. Companies are perfectly willing to pay for software. It’s about the freedom to make their own choices.
For me, it’s a “trip down memory lane.” Back then, I was involved in the Antonius Open project. In that project, St. Antonius Hospital in Utrecht/Nieuwegein was trying to introduce open-source software into its IT infrastructure. We encountered a lot of resistance, but technically, it was all feasible. Years have passed since then, and perhaps our motivation is even stronger now?
