---
title: "Cloud Design Principles"
description: "Eight guiding principles that shape all decisions in the STACKIT Cloud Adoption Framework — as a compass, not a checklist."
sidebar:
  order: 3
  label: "Cloud Design Principles"
source_url: "https://framework.stackit.cloud/advisory/cloud-vision-and-strategy/design-principles/"
source_file: "docs/advisory/cloud-vision-and-strategy/design-principles.mdx"
---

## Why Guiding Principles?

Frameworks provide structure. Principles provide direction. When two options are both technically feasible and economically justifiable, a principle decides — before the discussion becomes a political negotiation.

The eight principles of this framework are not philosophical statements. They are decision rules applied daily: when selecting a provider, when setting up a billing structure, when responding to a security incident. Each principle therefore includes an explicit consequence — what it actually means when the principle genuinely applies.

## Principle 1 — Cloud First

For every new IT capacity requirement, the cloud is the first option considered. An exception requires an active justification — not the other way around.

**What this means:** Cloud First is not a dogma. It is a reversal of the burden of proof. In an organisation without a Cloud First principle, the cloud option needs a justification; on-premises is the default. Cloud First reverses that: anyone who wants to run a workload locally must explain why the cloud is not the better option in this case. This does not produce bad decisions — it prevents bad habits.

**Typical application:** A business unit requests new server capacity. Instead of automatically opening an on-premises ticket, the cloud option is evaluated first: what are the requirements for latency, compliance, availability, and cost? Only if this evaluation leads to a clear result in favour of on-premises is that option pursued.

**Consequence for the organisation:** Procurement, budget planning, and the architecture process must treat cloud options as the default case. Procurement processes that treat cloud services as a special case work against this principle.

## Principle 2 — API First

Every service, every platform function, and every data interface is designed from the outset so that it can be addressed via a defined interface — regardless of whether that interface is used today.

**What this means:** API First is the technical prerequisite for automation, integration, and scaling. A service that can only be operated through a graphical interface is not automatable. A data source without an API is not integratable. In a cloud environment consisting of hundreds of services, the question is not whether automation will be needed — but when.

**Typical application:** An internal team develops a new approval portal. Instead of building it as a standalone web application only operable via browser, a REST API is co-designed from the beginning — even if no external integration is planned. This decision costs little during the initial build and saves considerable effort in every subsequent integration.

**Consequence for the organisation:** API design becomes a quality requirement, not a retrospective extension. This means API documentation, API versioning, and API governance as fixed components of the development process.

## Principle 3 — Automation First

Every manual, repeatable process is a candidate for automation. Manual execution is the exception, not the standard.

**What this means:** Manual processes are slow, error-prone, and person-dependent. In a cloud environment designed for scale and speed, manual execution undermines both promises of the cloud. Automation First does not mean automating everything immediately — it means asking, for every manual activity: why is this still manual, and what would it cost not to be?

**Typical application:** A security team manually checks each month whether all cloud resources are correctly tagged. Automation First asks: can this check run automatically, at every resource creation, in real time? The answer is almost always yes — and the implementation is more effort than a manual scan, but less expensive than a year of manual reviews.

**Consequence for the organisation:** Infrastructure-as-Code, CI/CD pipelines, and Policy-as-Code are not technical extras — they are the operational implementation of this principle. Organisations that take this principle seriously invest in tools and capabilities before operational pressure becomes too high.

## Principle 4 — You Build It, You Run It

The team that develops a service takes full operational responsibility. Development and operations are not separate life phases of a system — they are parallel responsibilities of the same team.

**What this means:** YBIYRI is the organisational consequence of Automation First and Cloud First. When teams provision their own infrastructure, operate their own deployment pipeline, and carry the pager at night when their service fails — they build better systems. Not because developers are more disciplined, but because the consequences of poor decisions become visible.

**Typical application:** A product team migrates its service to the cloud. After migration, it remains responsible for monitoring, alerting, incident response, and capacity planning. There is no "handover to operations". The team decides on its own SLOs, chooses its observability tools, and owns the costs of its service.

**Consequence for the organisation:** YBIYRI is the most difficult cultural change in this framework. It requires that teams build sufficient platform competency, that the Cloud Centre of Excellence works as an enabler rather than a central execution instance, and that middle management gives teams the autonomy this principle demands.

## Principle 5 — Internet First

System access is designed for operation over the public internet — with strong authentication and encryption as the default. Network topologies that rely exclusively on internal connections are treated as the exception.

**What this means:** Internet First is the technical answer to a world where employees, partners, and systems work from anywhere. A security architecture based on the concept "inside is safe, outside is dangerous" is structurally wrong in a cloud environment. When every connection — even internal — is treated as potentially compromised, it enforces a security architecture that actually holds.

**Typical application:** A new self-service portal for employees is not hidden behind a VPN that makes working remotely cumbersome. Instead, it is made accessible on the internet — with MFA, short-lived tokens, and a zero-trust access control that checks every access regardless of network origin.

**Consequence for the organisation:** Internet First requires a consistent departure from the perimeter security model. VPNs as the primary security tool are replaced by strong identity controls. This means investment in IDP, MFA, and zero-trust architecture — and sometimes persuasion work with security teams that have long considered the perimeter model sufficient.

## Principle 6 — Sovereignty by Default

Digital sovereignty is not an optional compliance feature. It is anchored from the outset in architecture, provider selection, and contract design.

**What this means:** For German organisations — especially in regulated industries — the question of who can access which data under which legal conditions is not a theoretical discussion. Sovereignty by Default means: before a provider, service, or data repository is selected, the sovereignty question is explicitly answered. Not retrospectively.

**Typical application:** A project team wants to introduce a new analytics service. Instead of implementing the service and clarifying the data protection question later, it is checked before the decision: where is the data processed? What law governs the provider? Is there a valid data processing agreement? Only when these questions are answered does the technical implementation begin.

**Consequence for the organisation:** Sovereignty by Default is not an exclusion of US Hyperscalers for all workloads. It is the requirement to answer the question consciously and with documentation — not to ignore it. For workloads with personal data, trade secrets, or regulated content, the answer may lead to preferring European providers or sovereign cloud models.

## Principle 7 — People Before Platform

Technical platforms only realise their value through the people who understand and use them. Capability building, cultural change, and training are primary investments — not accompanying measures.

**What this means:** The most common cause of failed cloud transformations is not insufficient budget or the wrong technology choice — it is organisations that buy the platform and do not give people sufficient time and space to work with it. People Before Platform means: when choosing between a technically superior platform for which no competency exists and a simpler platform the team understands — the team wins.

**Typical application:** The CCoE plans to introduce a new observability platform. Instead of choosing the most technically powerful option and then adding training afterwards, the decision is made as follows: which platform can the team use productively within 3 months? The introduction is accompanied by a training programme, internal champions, and a feedback loop — from the beginning.

**Consequence for the organisation:** Training budget is not a nice-to-have in the transformation programme. It is a direct investment in the success of the platform. Organisations that take this principle seriously measure capability development just as they measure technical progress — and adjust the pace of introduction to the teams' learning curve.

## Principle 8 — Incremental Confidence

Every phase of the transformation must be independently valuable and build trust before the next phase begins. Big-bang approaches are avoided.

**What this means:** Cloud transformations that migrate "everything at once" fail more frequently — not because technology fails, but because the organisation underestimates complexity and lacks trust in the new platform. Incremental Confidence means: every step is complete, provable, and reversible. The next step only begins when the current step has met expectations.

**Typical application:** An organisation does not begin cloud adoption with the migration of its critical ERP systems, but with a non-critical workload that generates rapid learning: an internal development environment, a test system, a new digital product without legacy dependencies. Only when this migration runs smoothly and the team has gained operational experience are more complex systems migrated.

**Consequence for the organisation:** Incremental Confidence requires a willingness to start more slowly than would be politically possible. The leadership team must be able to explain why Phase 1 is deliberately small — and what learning it generates. The advantage is a transformation that actually arrives, rather than a large project that ends with a retreat to on-premises.

## The Principles in Interaction

The eight principles reinforce each other — and deliberately create tensions. Cloud First and Sovereignty by Default sometimes conflict: the best cloud service for a requirement is not always the most sovereign. This tension is intentional. It forces an explicit decision rather than an unconscious default choice.

Internet First and Sovereignty by Default are not a contradiction: a system can be publicly accessible and still operated sovereignly — if the access control is robust and the data remains within European infrastructure.

YBIYRI and People Before Platform depend on each other: teams cannot take on operational responsibility for which they have not been trained. Introducing YBIYRI without investing in capability building overwhelms the teams and generates resistance to the entire transformation programme.