Cloud Design Principles

Warum Leitprinzipien?

Frameworks geben Struktur. Grundsätze geben Orientierung. Wenn zwei Optionen technisch machbar und wirtschaftlich vertretbar sind, entscheidet ein Grundsatz — bevor die Diskussion zur politischen Verhandlung wird.

Die acht Prinzipien dieses Rahmenwerks sind keine philosophischen Aussagen. Es sind Entscheidungsregeln, die täglich angewendet werden: bei der Auswahl eines Providers, beim Aufbau einer Abrechnungsstruktur, bei der Reaktion auf einen Security Incident. Jeder Grundsatz enthält daher eine explizite Konsequenz — was es eigentlich heißt, wenn der Grundsatz wirklich gilt.

Prinzip 1 — Cloud First

Bei jedem neuen IT-Kapazitätsbedarf kommt als Erstes die Cloud in Betracht. Eine Ausnahme erfordert eine aktive Begründung — nicht umgekehrt.

Was das heißt: Cloud First ist kein Dogma. Es handelt sich um eine Beweislastumkehr. In einer Organisation ohne Cloud-First-Prinzip bedarf die Cloud-Option einer Begründung; On-Premises ist die Standardeinstellung. Cloud First dreht das um: Wer einen Workload lokal laufen lassen will, muss erklären, warum die Cloud in diesem Fall nicht die bessere Option ist. Dadurch werden keine schlechten Entscheidungen getroffen, sondern schlechte Gewohnheiten vermieden.

Typischer Anwendungsfall: Eine Sparte fordert neue Serverkapazität an. Anstatt automatisch ein On-Premises-Ticket zu eröffnen, wird zunächst die Cloud-Option bewertet: Wie lauten die Anforderungen an Latenz, Compliance, Verfügbarkeit und Kosten? Nur wenn diese Bewertung zu einem klaren Ergebnis zugunsten von On-Premises führt, wird diese Option weiterverfolgt.

Folge für die Organisation: Beschaffung, Budgetplanung und Architekturprozess müssen Cloud-Optionen als Standardfall behandeln. Gegen diesen Grundsatz arbeiten Beschaffungsprozesse, die Cloud-Services als Sonderfall behandeln.

Prinzip 2 — API First

Jeder Dienst, jede Plattformfunktion und jede Datenschnittstelle ist von vornherein so ausgelegt, dass sie über eine definierte Schnittstelle angesprochen werden kann — unabhängig davon, ob diese Schnittstelle heute genutzt wird.

Was das bedeutet: API First ist die technische Voraussetzung für Automatisierung, Integration und Skalierung. Ein Service, der nur über eine grafische Oberfläche bedient werden kann, ist nicht automatisierbar. Eine Datenquelle ohne API ist nicht integrierbar. In einer Cloud-Umgebung mit Hunderten von Diensten stellt sich nicht die Frage, ob eine Automatisierung notwendig ist, sondern wann.

Typische Anwendung: Ein internes Team entwickelt ein neues Freigabeportal. Anstatt dieses als eigenständige Webanwendung nur über den Browser bedienbar zu bauen, wird von vornherein eine REST-API mitgestaltet — auch wenn keine externe Integration geplant ist. Diese Entscheidung kostet beim initialen Build wenig und spart bei jeder weiteren Integration erheblichen Aufwand.

Folge für die Organisation: API-Design wird zur Qualitätsanforderung, keine nachträgliche Erweiterung. Damit sind API-Dokumentation, API-Versionierung und API-Governance als feste Bestandteile des Entwicklungsprozesses gemeint.

Prinzip 3 — Automation First

Jeder manuelle, wiederholbare Prozess ist ein Kandidat für die Automatisierung. Manuelle Ausführung ist die Ausnahme, nicht der Standard.

Was das bedeutet: Manuelle Prozesse sind langsam, fehleranfällig und personenabhängig. In einer Cloud-Umgebung, die auf Skalierung und Geschwindigkeit ausgelegt ist, untergräbt die manuelle Ausführung beide Versprechen der Cloud. Automation First bedeutet nicht, alles sofort zu automatisieren, sondern sich bei jeder manuellen Tätigkeit zu fragen: Warum ist das immer noch manuell und was würde es kosten, es nicht zu sein?

Typische Anwendung: Ein Sicherheitsteam prüft monatlich manuell, ob alle Cloud-Ressourcen korrekt getaggt sind. Automation First fragt: Kann diese Prüfung automatisch bei jeder Ressourcenanlage in Echtzeit durchgeführt werden? Die Antwort ist fast immer Ja — und die Umsetzung ist aufwändiger als ein manueller Scan, aber günstiger als ein Jahr manueller Reviews.

Folge für die Organisation: Infrastructure-as-Code, CI/CD-Pipelines und Policy-as-Code sind keine technischen Extras, sondern die operative Umsetzung dieses Prinzips. Organisationen, die diesen Grundsatz ernst nehmen, investieren in Tools und Fähigkeiten, bevor der operative Druck zu hoch wird.

Prinzip 4 — You Build It, You Run It

Das Team, das einen Service entwickelt, trägt die volle operative Verantwortung. Entwicklung und Betrieb sind keine separaten Lebensphasen eines Systems, sondern parallele Aufgaben desselben Teams.

Was dies bedeutet: YBIYRI ist die organisatorische Konsequenz aus Automation First und Cloud First. Wenn Teams ihre eigene Infrastruktur bereitstellen, ihre eigene Deployment-Pipeline betreiben und den Pager nachts tragen, wenn ihr Dienst ausfällt, bauen sie bessere Systeme auf. Nicht, weil die Entwickler disziplinierter sind, sondern weil die Konsequenzen von Fehlentscheidungen sichtbar werden.

Typischer Anwendungsfall: Ein Produktteam migriert seinen Service in die Cloud. Nach der Migration bleibt es für die Überwachung, Alarmierung, Reaktion auf Vorfälle und die Kapazitätsplanung verantwortlich. Es erfolgt keine „Übergabe an den Betrieb“. Das Team entscheidet selbst über SLOs, wählt seine Observability-Tools und besitzt die Kosten für seinen Service.

Folge für die Organisation: YBIYRI ist der schwierigste Kulturwandel in diesem Rahmen. Es erfordert, dass Teams ausreichende Plattform-Kompetenz aufbauen, dass das Cloud Center of Excellence als Befähiger und nicht als zentrale Ausführungsinstanz fungiert und dass das mittlere Management den Teams die Autonomie gibt, die dieses Prinzip erfordert.

Prinzip 5 — Internet First

Der Systemzugriff ist für den Betrieb über das öffentliche Internet ausgelegt — standardmäßig mit starker Authentifizierung und Verschlüsselung. Als Ausnahme werden Netzwerktopologien behandelt, die ausschließlich auf interne Verbindungen angewiesen sind.

Was das bedeutet: Internet First ist die technische Antwort auf eine Welt, in der Mitarbeitende, Partner und Systeme von überall arbeiten. Eine Sicherheitsarchitektur nach dem Konzept „Drinnen ist sicher, draußen ist gefährlich“ ist in einer Cloud-Umgebung strukturell falsch. Wenn jede Verbindung — auch interne — als potenziell kompromittiert behandelt wird, erzwingt sie eine Sicherheitsarchitektur, die tatsächlich Bestand hat.

Typischer Anwendungsfall: Ein neues Self-Service-Portal für Mitarbeitende versteckt sich nicht hinter einem VPN, das das Arbeiten aus der Ferne umständlich macht. Stattdessen wird es über das Internet erreichbar gemacht — mit MFA, kurzlebigen Token und einer Zero-Trust-Zugriffskontrolle, die jeden Zugriff unabhängig von der Netzwerkherkunft prüft.

Folge für die Organisation: Internet First erfordert eine konsequente Abkehr vom Perimeter-Sicherheitsmodell. VPNs als primäres Sicherheitstool werden durch starke Identitätskontrollen ersetzt. Das bedeutet Investitionen in IDP, MFA und Zero-Trust-Architektur — und manchmal auch Überzeugungsarbeit mit Sicherheitsteams, die das Perimeter-Modell lange als ausreichend angesehen haben.

Prinzip 6 — Souveränität durch Vorgabe

Digitale Souveränität ist kein optionales Compliance-Merkmal. Sie ist von vornherein in Architektur, Anbieterauswahl und Vertragsgestaltung verankert.

Was das bedeutet: Für deutsche Organisationen — insbesondere in regulierten Industrien — ist die Frage, wer unter welchen rechtlichen Bedingungen auf welche Daten zugreifen kann, keine theoretische Diskussion. Sovereignty by Default bedeutet: Bevor ein Provider, Service oder eine Datenhaltung ausgewählt wird, wird die Hoheitsfrage explizit beantwortet. Nicht rückwirkend.

Typischer Anwendungsfall: Ein Projektteam möchte einen neuen Analytics-Service einführen. Anstatt den Service erst umzusetzen und die Datenschutzfrage später zu klären, wird vor der Entscheidung geprüft: Wo werden die Daten verarbeitet? Welches Recht regelt den Anbieter? Gibt es eine gültige Auftragsverarbeitungsvereinbarung? Erst wenn diese Fragen beantwortet sind, beginnt die technische Umsetzung.

Folge für die Organisation: Sovereignty by Default ist kein Ausschluss von US-Hyperscalern für alle Workloads. Es ist die Anforderung, die Frage bewusst und dokumentiert zu beantworten — nicht zu ignorieren. Bei Workloads mit personenbezogenen Daten, Betriebsgeheimnissen oder regulierten Inhalten kann die Antwort dazu führen, dass europäische Anbieter oder souveräne Cloud-Modelle bevorzugt werden.

Prinzip 7 — Mensch vor Plattform

Technische Plattformen entfalten ihren Wert nur durch die Menschen, die sie verstehen und nutzen. Capability-Building, Kulturwandel und Training sind primäre Investitionen — keine begleitenden Maßnahmen.

Was dies bedeutet: Die häufigste Ursache für gescheiterte Cloud-Transformationen ist nicht ein unzureichendes Budget oder die falsche Technologiewahl — es sind Organisationen, die die Plattform kaufen und den Menschen nicht genügend Zeit und Raum geben, um damit zu arbeiten. People before Platform bedeutet: Bei der Wahl zwischen einer technisch überlegenen Plattform, für die keine Kompetenz besteht, und einer einfacheren Plattform, die das Team versteht — gewinnt das Team.

Typischer Anwendungsfall: Der CCoE plant die Einführung einer neuen Observability-Plattform. Anstatt die technisch leistungsstärkste Option zu wählen und anschließend Schulungen hinzuzufügen, wird die Entscheidung wie folgt getroffen: Welche Plattform kann das Team innerhalb von 3 Monaten produktiv nutzen? Begleitet wird die Einführung von einem Trainingsprogramm, internen Champions und einer Feedbackschleife — von Anfang an.

Folge für die Organisation: Weiterbildungsbudget ist kein Nice-to-have im Transformationsprogramm. Es ist eine direkte Investition in den Erfolg der Plattform. Organisationen, die diesen Grundsatz ernst nehmen, messen die Entwicklung ihrer Fähigkeiten genauso wie den technischen Fortschritt — und passen das Einführungstempo an die Lernkurve der Teams an.

Prinzip 8 — Inkrementelles Vertrauen

Jede Phase der Transformation muss für sich genommen wertvoll sein und Vertrauen aufbauen, bevor die nächste Phase beginnt. Big-Bang-Ansätze werden vermieden.

Was das bedeutet: Cloud-Transformationen, die „alles auf einmal“ migrieren, scheitern häufiger — nicht weil Technologie versagt, sondern weil die Organisation die Komplexität unterschätzt und das Vertrauen in die neue Plattform fehlt. Inkrementelles Vertrauen bedeutet: Jeder Schritt ist vollständig, beweisbar und reversibel. Der nächste Schritt beginnt erst, wenn der aktuelle Schritt die Erwartungen erfüllt hat.

Typische Anwendung: Eine Organisation beginnt die Cloud-Einführung nicht mit der Migration ihrer kritischen ERP-Systeme, sondern mit einem unkritischen Workload, der schnelles Lernen generiert: eine interne Entwicklungsumgebung, ein Testsystem, ein neues digitales Produkt ohne Legacy-Abhängigkeiten. Erst wenn diese Migration reibungslos verläuft und das Team Betriebserfahrung gesammelt hat, werden komplexere Systeme migriert.

Konsequenz für die Organisation: Inkrementelles Vertrauen erfordert die Bereitschaft, langsamer anzufangen, als es politisch möglich wäre. Das Führungsteam muss erklären können, warum Phase 1 bewusst klein gehalten wird — und welche Learnings sie generiert. Der Vorteil ist eine Transformation, die tatsächlich ankommt, und nicht ein Großprojekt, das mit dem Rückzug auf On-Premises endet.

Die Grundsätze im Zusammenspiel

Die acht Prinzipien verstärken sich gegenseitig — und erzeugen bewusst Spannungen. Cloud First und Sovereignty by Default kollidieren manchmal: Der beste Cloud-Service für eine Anforderung ist nicht immer der souveränste. Diese Spannung ist gewollt. Sie erzwingt eine explizite Entscheidung und nicht eine unbewusste Standardauswahl.

Internet First und Sovereignty by Default sind kein Widerspruch: Ein System kann öffentlich zugänglich sein und trotzdem souverän betrieben werden — wenn die Zugriffskontrolle robust ist und die Daten innerhalb der europäischen Infrastruktur bleiben.

YBIYRI und People before Platform sind aufeinander angewiesen: Teams können keine operative Verantwortung übernehmen, für die sie nicht geschult wurden. Die Einführung von YBIYRI, ohne in Capability Building zu investieren, überfordert die Teams und erzeugt Widerstand gegen das gesamte Transformationsprogramm.