Welcome, dear architects, strategists, and decision-makers. You have arrived in an era where the rules are being rewritten. The utopia of a borderless internet, where one-click deployments were possible in any location in the cloud, is slowly dissolving. The IT galaxy is becoming more complex, more political, and, yes, a bit more uncomfortable. But don’t worry: DON’T PANIC.

We have long lived in a kind of utopia. National borders didn’t matter to us. Our infrastructure was global, and deployments could be distributed across the globe with a single click. The location was just a variable in a configuration file.

That era is coming to an end. The topic of sovereignty is unfortunately not just an abstract buzzword but a real challenge. The impact on us as the IT industry is hard to foresee. After all, we all had the same access to technology, no matter where we were in the world and almost regardless of the available budget. The “democratization of innovation and technology” has made us significantly more agile. Personally, I’m more of a “learning by doing” guy, so the impact this will have on my way of learning, for example, remains to be seen.

DON’T PANIC

Actually, the topic of sovereignty is not new. We have always discussed it as “in-house value creation” in the innovation process; keywords like “Make or Buy” or the in-sourcing trend immediately come to mind. In the current political climate, we must actively manage it like any other risk. Not just in the context of strategic discussions or product development, but in almost all areas of a business.

Is this also available as a sovereign solution?

This is a bit tricky because while definitions for sovereignty certainly exist, they are usually sociological or legal. In IT, there is no clear definition that allows us to measure the degree of sovereignty of a solution.

In our discussions (i.e., we in this bubble), we have always been able to agree on three core dimensions: data, technology, and operational sovereignty. I believe this is a good starting point for defining sovereignty in your own context, as this is where the real challenge begins. Depending on the industry, value system, and corporate strategy, these dimensions can vary, and, in particular, additional dimensions may be added. I have a paper here in which a client describes their understanding of sovereign IT services, and it goes far beyond the three. By the way, I don’t see this as a problem but as a real advantage for them in the market. If the paper has also been socialized in their own company, there has been a lot of discussion and informed decisions. They are ready to tackle the issue in a structured way.

First, it is important to define, demand, or develop the right metrics for our organization. It’s about creating strategic guidelines (“guardrails”). Attention: Like any strategic consideration, these must be continuously reviewed and adjusted as needed.

For inspiration, here is my simple definition of the three basic dimensions:

  • Data Sovereignty: I want control over my data.
  • Technology Sovereignty: I want control over the technology used.
  • Operational Sovereignty: I want to be able to do it myself.

The journey is the destination. Once the dimensions are defined for your context, you can flesh them out in detail.

In the next step, we will focus on quality. What could a scale for data sovereignty look like? It’s best to document this directly. The scale could range from:

  • Level 0 (“I don’t care; I just want to be able to store and retrieve data”) to
  • Level 3 (“I want to know where my data is stored at all times and be able to extract and delete it if necessary”) to
  • Level 5 (“I want to have my data exclusively with me. If data must be given outside my sphere of influence for processing, it must be done sparingly and encrypted”).

Each of these levels is conceivable and valid. Discuss this extensively and document your ideas - do informed decisions.

Once these considerations are complete, you can create a grid and, for example, determine: “Technology sovereignty must not fall below Level 3, and for business-critical applications, at least Level 4 must be applied.”

Boom! While you still can’t compare market offers with this, you have a basis for articulating and measuring how sovereign technical solutions must be and are within your value system. (This is also an excellent basis for evaluating offers from service providers and partners.)

And behold, what we have devised are “completely normal” non-functional requirements. We can manage them in the same way. (Preferably S.M.A.R.T. ;-))

Architects know the game: almost all non-functional requirements contradict each other and require a balance or compromise. These are exactly the discussions we want to have and document our findings and decisions.

Please let me know what you think about this. Imagine if we could standardize dimensions and scales and use them to label products…