Build vs. Buy: Umverteilung von Verantwortung

Das tiefste Argument dieser Website steckt in einem Begriff: Umverteilung von Verantwortung. Er ist das Prisma, das das scheinbare Paradox auflöst, warum Europa über wettbewerbsfähige Cloud-Infrastruktur verfügt (in manchen Benchmarks ein um den Faktor 4,8 besseres Preis-Leistungs-Verhältnis) und dennoch nur 15 % seines heimischen Cloud-Markts hält.

Hyperscaler verkaufen Integration; europäische Anbieter verkaufen Infrastruktur

Hyperscaler bündeln die Integration und den Betrieb von Hunderten von Diensten in einem einzigen Vertrag. Die Kundinnen und Kunden zahlen einen Aufschlag und erhalten ein fertiges Produkt. AWS, Azure und Google Cloud liefern nicht nur Rechenkapazität und Speicher — sie liefern verwaltete Datenbanken, Observability, Identity, KI/ML-Plattformen, serverlose Orchestrierung, Sicherheitswerkzeuge und den Integrationsklebstoff zwischen all diesen Diensten. Die Aufgabe der Kundschaft besteht darin, ihre Anwendung zu schreiben; die Cloud kümmert sich um das operative Fundament.

Europäische Anbieter — OVHcloud, Scaleway, STACKIT, Hetzner — verkaufen Infrastruktur. Rechenkapazität, Speicher, Netzwerk, grundlegende verwaltete Dienste und eine schlankere Integrationsschicht darüber. Der Integrationsklebstoff liegt in der Verantwortung der Kundschaft, bereitgestellt durch eigene Ingenieurinnen und Ingenieure oder durch einen eigens beauftragten Systemintegrator.

Das ist kein Qualitätsunterschied. Es ist eine andere ökonomische Verteilung.

Warum dies Europas strukturellen Vorteil ausspielt

Europa besitzt einen unbestrittenen Vorteil, den diese Website bereits angesprochen, aber noch nicht operationalisiert hat: eine höhere technische Talentdichte pro Kopf als die USA oder China. ETH Zürich, EPFL, TU Delft, KU Leuven, die französischen grandes écoles, die deutschen Technischen Universitäten — diese Institutionen bilden Ingenieurtalente in einem weltweit seltenen Maßstab aus, und Europas gesamte Technologiebeschäftigung wuchs 2025 auf 4,6 Millionen.

Dieses Talent ist im aktuellen Cloud-Einkaufsmuster zum Teil unterbeschäftigt. Es arbeitet an Projekten, aber die tiefe operative Expertise — Aufbau und Betrieb von Produktionssystemen, Integration verteilter Datenbanken, Betrieb von Kubernetes im großen Maßstab, Entwurf von Observability-Lösungen — wird über das Produkt des Hyperscalers konsumiert, nicht im eigenen Haus aufgebaut.

Eine Migration zu einem europäischen Anbieter verteilt den Wert dieses Talents um. Statt eines Aufschlags für das operative Team des Hyperscalers bezahlt die Organisation ihre eigenen Ingenieurinnen und Ingenieure, um die Infrastruktur aufzubauen und zu betreiben. Die Kostenstruktur verschiebt sich von „Anbietermarge" zu „internem Gehalt"; die strategische Position verschiebt sich von „Konsument eines integrierten Produkts" zu „Betreiber der eigenen Plattform."

Konkret: Eine typische mittelgroße europäische Organisation, die nicht-triviale Workloads von einem Hyperscaler zu OVHcloud oder Scaleway verlagert, muss in den ersten 18 Monaten 2–4 Vollzeit-DevOps/SRE-Ingenieurinnen und -Ingenieure einstellen. Bei europäischen Gehaltsniveaus (€70–110k Vollkostenbelastung pro Person) sind das €140–440k pro Jahr. Gemessen an einer typischen Hyperscaler-Rechnung in ähnlicher oder höherer Größenordnung geht die Rechnung häufig auf — und die zusätzlichen Beschäftigten erzeugen internes Know-how, das der Organisation gehört, nicht dem Anbieter.

Das Build-vs-Buy-Spektrum ist nicht binär

Der obige Rahmen ist bewusst schematisch gehalten. In der Praxis ist die Wahl ein Spektrum, keine Entweder-oder-Entscheidung. Die meisten Organisationen landen irgendwo in der Mitte:

• Reines Buy: vollständig beim Hyperscaler, intensive Nutzung proprietärer Dienste (Lambda, SageMaker, Power Platform). Geringster Vorabaufwand, höchste Ausstiegskosten, tiefste Anbieterbindung.
• Reines Build: auf Bare-Metal- oder einfacher VM-Infrastruktur, alles selbst aufgebaut. Höchster Vorabaufwand, geringste Anbieterbindung, erfordert erhebliche Teamfähigkeiten.
• Hybrides Pragmatismus-Modell: der realistische Modus für die meisten Organisationen im Jahr 2026. Workloads, bei denen der europäische Katalog ausreicht (VM, Objektspeicher, verwaltetes Kubernetes, verwaltetes PostgreSQL, grundlegendes Observability), werden zu europäischen Anbietern verschoben; Workloads, die von tiefen proprietären Diensten abhängen, verbleiben bei Hyperscalern — mit vertraglichen Ausstiegsklauseln, die die DORA-Anforderungen an die Ausstiegsstrategie erfüllen.

Das hybride Pragmatismus-Modell ist das, was die 24-Monats-Roadmap operationalisiert — nicht als Präferenz, sondern als realistischsten Weg für eine Organisation, die Handlungsspielraum aufbauen will, ohne den laufenden Betrieb zu stören.

Wann reines Buy die richtige Antwort ist

Es lohnt sich, ehrlich zu sein: Nicht jede Organisation sollte Verantwortung umverteilen. Reines Buy bei einem Hyperscaler ist die richtige Antwort für Organisationen, die:

• über geringe oder keine interne IT-Betriebskapazität verfügen
• in regulierten Umgebungen tätig sind, in denen die Zertifizierungen des Hyperscalers mehr zählen als die Architektur
• Geschäftsmodelle haben, bei denen Anbieterbindung akzeptabel ist, weil der Workload nicht strategisch ist
• aus Gründen der Personalgewinnung oder des Standorts kein 2–4-köpfiges DevOps/SRE-Team aufrechterhalten können

Anzuerkennen, wann reines Buy rational ist, gehört zur Disziplin. Das Umverteilungsmodell ist kein moralisches Gebot; es ist eine Option, die für Organisationen mit dem nötigen Talent, der nötigen Größe und dem nötigen Zeithorizont sinnvoll ist.

Was das für die Beschaffung bedeutet

Daraus ergeben sich drei Konsequenzen für die Beschaffung:

1. Vertragsbedingungen sind genauso wichtig wie die Katalogauswahl. Unabhängig davon, was wo angesiedelt ist, schafft die vertragliche Checkliste (nächstes Kapitel) Handlungsspielraum und Ausstiegsoptionen.
2. Die Gesamtbetriebskosten sind die richtige Vergleichsgröße, nicht der Listenpreis. Eine Hyperscaler-Rechnung von €10k/Monat ist nicht direkt vergleichbar mit €5k/Monat bei einem europäischen Anbieter zuzüglich €25k/Monat für zusätzliche Ingenieurinnen und Ingenieure. Sobald diese Rechnung jedoch korrekt aufgestellt wird, ist die Umverteilung oft finanziell wettbewerbsfähig — und bringt Fähigkeiten hervor, die das reine Buy-Modell nicht erzeugt.
3. Das Team aufbauen, bevor migriert wird — nicht währenddessen. Das häufigste Scheitermuster ist, den operativen Investitionsbedarf zu unterschätzen, zu migrieren und dann angesichts der operativen Komplexität in Panik zu geraten. Die 24-Monats-Roadmap begegnet dem durch sequenzierte Schritte, bei denen der Fähigkeitsaufbau der architektonischen Veränderung vorausgeht.