Companies today source critical functions from a handful of large cloud providers. The contracts are standard terms, not negotiable, and regulation increasingly demands the ability to exit, for instance under the EU Data Act and DORA.

But the decisive question is not settled in the contract. It is settled in the technology. Whether a company can actually switch providers, or keep a function running on its own in an emergency, is determined by architectural decisions made years earlier. Whoever embeds a managed service deeply into their application today has no choice left tomorrow.

Surprisingly little is known about these decisions. Research on provider dependence looks almost exclusively at contracts and bargaining power. Architecture appears mainly as an instrument of the platform owner, rarely as a means of protection for the dependent firm.

The scope of this thesis is deliberately open. Topic, focus and method can be shaped in a personal brainstorming session with the supervisor, so that the work fits your own interests and prior knowledge. What follows are possible directions, not a fixed specification.

The overall theme: how companies can protect themselves technically against provider dependence through their IT architecture, and what that protection costs them.

Possible directions, as examples:

• A catalogue of architectural patterns and their trade-offs. Candidates include abstraction layers and anti-corruption layers, containers instead of managed services, open data formats, separation of control plane and data plane, external key custody, and dual-run or multi-cloud operation. Every one of these reduces dependence and every one of them costs something: performance, complexity, money, or giving up precisely the provider features the provider was chosen for.
• An assessment of how far so-called sovereign cloud offerings actually deliver technical independence.
• A case-based study of one or two companies that attempted to leave a provider, and what held them back.
• A focused deep dive into a single mechanism, for example what external key custody really costs in availability.

Possible approaches, depending on the direction chosen: review of research literature and practitioner documentation such as AWS Well-Architected, the Azure Cloud Adoption Framework and CNCF material; interviews with IT architects; assessment against real architectures; or a measurement setup.

The scope is adjusted to whether the work is a Bachelor's or a Master's thesis.

• Studies in information systems, computer science, or a related field
• Interest in cloud technologies and in how technical decisions produce economic consequences
• Willingness to work through technical documentation and English-language research literature
• Structured, independent way of working
• An advantage but not a requirement: hands-on experience with cloud services, container technologies, or software architecture

You do not need to bring a finished topic. Curiosity about the subject is enough. We will work out the concrete question together.

• Close, hands-on supervision. Regular meetings, quick feedback, and a supervisor who is actually reachable between appointments.
• A topic that matters. The thesis is embedded in an ongoing doctoral project on corporate digital sovereignty. Your results feed into current research rather than disappearing into a drawer.
• Room to shape it. The concrete question is developed together with you, along your interests and prior knowledge.
• A prepared starting point. Access to a curated body of literature, existing preliminary work, and an established method for the topic, so you do not start from zero.
• Support on the craft. Help with research design, structure and academic writing, not just on the content.
• Flexible working arrangements. Remote or on site, as it suits you.

Please send a short email with:

• a brief note on what interests you about the topic, a few sentences are enough
• your CV
• a current transcript of records

No motivation letter, no cover page. I care about whether the topic fits you, not about formatting.

After that we hold a short interview of about 15 minutes, in person or online. The point is not to test you. We use it to work out together which direction of the topic fits you, and whether the supervision is a good match on both sides.

The start date is flexible and can be arranged. Feel free to get in touch even if you are still unsure whether the topic is right for you, or if you would like to discuss a different angle on it. A short conversation usually clears that up faster than an email exchange.

Contact: Adrian Bohrer, adrian.bohrer@unisg.ch