Sovereign, what is that?

Actually, that is not very relevant. There is no one who expects you to build a sovereign cloud yourself. Because in its purest form, you buy hardware yourself, select Open Source software that can run on almost all hardware. You build infrastructure. Connect that to multiple ISPs to the internet, after which you run the necessary applications on it. And this is still quite simplified :).

And all suppliers are tumbling over each other to use the word sovereign in their marketing. And with that, I hint at the nonsense that AWS, Microsoft, and Google sell. They try to shift it to checkboxes in their cloud that give you "control" over the data. They even do this with European residents... Americans living in Europe, not European citizens!!!. And I am someone who keeps poking through that nonsense. And then I am approached by one of the three (out of decency, no name) so that their lawyer can explain what they mean. If a lawyer has to explain how your product works, then I am done with it. Why aren't you?

What are the challenges?

• Who can access your data?
• Where is it located?
• Is the data recoverable?
• Is the application that the data belongs to available?

It comes down to:

• Availability
• Integrity
• Confidentiality

Indeed,BIV..

Back to sovereignty. The goal is that you indeed have control over your data, but not just with a tick box. You need to ask your supplier a number of questions to know if it is OK. And if there are questions in between that you do not understand, or you do not see why that is important (I don't want to make the text too long), please put it in a comment, and I will provide an explanation. If it all seems like gobbledygook, then you should not be the person who chooses the supplier. And do not make assumptions. Because there is something to that:https://www.linkedin.com/pulse/aannames-en-ict-wat-daarmee-het-erg-hoe-voorkom-je-dat-ronald-otto/

The questions

First, the chain:

• Is the company 100% European?
• Are the sub-processors (who are they?) also 100% European?
• Do the sub-processors also have sub-processors? (this is often forgotten) and are they also 100% European?
• Are there any non-European citizens in the chain?

Back-ups:

• Who makes the back-ups?
• Who is responsible for them?
• How long are these kept?
• How many versions are there?
• Where are these stored?
• Is an air-gapped back-up possible?
• How long does recovery take (approximately)?
• How granular is the recovery? (1 file or does your entire company need to be rolled back a day?)

Continuity:

• Is there insurance against liability? If your supplier makes a mistake with another client, it should not immediately lead to bankruptcy.
• Is there an employee, software package, or supplier on which continuity depends?
• What happens if a data centre goes down?
• What still works and what does not?
• How much time are things not working?
• How much data are you losing?
• Are there policies for privacy, security, sensible use, workplaces, and management?
• You should be able to view those. If not, why not?

Strategic:

• Is IPv6 included as standard (so not IPv6 ready, but actually working)? (it says something about how serious the supplier is)
• Is there an Open Source first strategy? (better support, more control)
• If a software subscription or license expires, does the software continue to work?
• Does the supplier do things for a better internet? Building software, peering, IPv6?

Contact:

• Can you come for a coffee?
• How is support arranged? (don't assume you can call for all problems)
• What does that cost? That support?

Can you still leave?

Suppliers do everything to bind you. A single plug-in in an application can ensure that you are stuck. That's why you see a sort of two camps. One has an API based on an open standard and the other forces you to install plug-ins. You want an API or connection with an open standard.

But how do you know if you're in the right place?

That's quite simple. Ask the following question: Can I use and edit all data via an API? Is that API public? May I have the documentation? And by public, I mean, can I access it from the internet if needed? So a handy tool that you have to install in Outlook is a no-go. You MUST use Outlook to be able to use that tool. And Outlook only really works well with Microsoft products. See how easily that can go wrong?

Never make concessions.

That's difficult, it takes more time at the beginning. It saves a lot of time later and also money, but that is not always immediately visible. And then there is the next pitfall. The old hands in the field surely remember that accountant who had an Excel document full of VB scripts. The whole company relied on that. No one dared to touch that document and that accountant was king. The same is happening now with automations or low code. An employee can build numerous cool flows for business processes. The solution in which that flow is built can never be removed, or the reworking will cost more than you would like. That employee should never have built that. It needs to be a much more structured solution. Just as that Excel sheet is now in an accounting package, those flows also need to find another place.

Programmers are being replaced

Perhaps you now understand why certain companies are so focused on AI. AI is going to replace programmers... of course they want that. And if you don't realise it, it will happen, but that doesn't make it a good idea.

Employees are all quickly building nice complex things at low costs (depending on how skilled that employee is, of course). The bill comes when you can no longer leave. Am I saying that you should have custom software built? Well, I would be cautious with SaaS (Software as a Service). If you cannot run the software yourself, the price will go up when you can no longer leave. And there are exceptions, but not many. Custom software fits your business process and can be adjusted as your business process changes.

This is already far too much text for a blog post, so I'll stop here :-) I hope it provides some insight into the problem and the pitfalls.

With the above in mind, I would like to point out that the companies where I have applied this so far did not have to change anything fundamentally to adapt to the following situations:

• When the GDPR came around. 0 sub-processors was indeed a good idea :-)
• NIS2. Chain responsibility. A short chain is a good idea.
• With ISO27001 certifications
• Now that it is clear that a European cloud is a good idea.

And the fact that we are not suffering from it is thanks to a privacy-first strategy. I write about that here:https://www.linkedin.com/pulse/hoe-slim-een-cloud-first-strategie-ronald-otto/

The customers of companies with such an approach naturally have the same advantages.

Questions?Feel free to ask them.