AWS Cloud Center of Excellence (CCoE): Effektive Einbindung externer Partner

Von Benedikt Muschong, Rene-Martin Tudyka, Markus Wenzel 

Im ersten Teil dieser Blog-Serie haben wir das Cloud Center of Excellence (CCoE) als etabliertes Framework für erfolgreiche Cloud-Transformationen vorgestellt. Das CCoE ist eine Blaupause, die beschreibt, wie Organisationen die Cloud steuern und interne Arbeitsweisen verändern können, um Mehrwert zu schaffen.

In vielen Fällen wird das CCoE mit internen Ressourcen besetzt. Eine andere Konstellation bei Kunden ist die Nutzung eines externen IT-Dienstleisters als Partner für das Cloud Platform Engineering (CPE), die zusätzliche Anforderungen an das Management stellt. Dieser Artikel geht auf die Besonderheiten und Empfehlungen dazu ein, um u.a. folgende Fragen zu beantworten: Was ist der Mindestumfang des internen Teams, um den Dienstleister effektiv zu steuern? Was sind geteilte Verantwortlichkeiten und welche Kompetenzen müssen intern bleiben, um Entscheidungen treffen zu können? Was sind Werttreiber für langfristigen Erfolg?

Warum einen externen Partner nutzen?

Die Entscheidung, Cloud Platform Engineering an einen Partner zu vergeben, kann durch verschiedene Faktoren, oder eine Kombination, motiviert sein:

Fehlende interne Ressourcen: Erfahrene Cloud-Ingenieure sind schwer zu rekrutieren und langfristig zu binden. Wenn Kunden aus einem Outsourcing Betriebsmodell in die Cloud wechseln, steigt die Häufigkeit für die Nutzung eines Dienstleisters: Zum einen fehlt aus der Vergangenheit oft internes Personal, zum anderen positionieren sich die bestehenden Outsourcing Dienstleister als Betriebsteams für die Cloud, da diese die Kundenumgebung gut kennen.

Schneller Anlauf und Skalierbarkeit: Ein Partner bringt sofort einsatzbereite Expertise mit und verkürzt die Anlaufphase erheblich, kann damit auch punktuell zur Ergänzung von Expertise genutzt werden. Zudem können externe Teams flexibel skaliert werden – je nach Projektphase und Anforderung.

Die Nutzung eines Partners kann dauerhaft, aber auch temporäres Modell sein, das mit zunehmender Reife verändert wird und externes durch internes Personal ersetzt.

Welche Aufgaben übernimmt der Dienstleister?

Bei Betrachtung des Frameworks erscheinen zwei Cluster relativ klar: Das Cloud Leadership Team (CLT) bleibt beim Kunden, da die Strategie- und Organisationsausrichtung Kernkompetenzen sind, die intern gehalten werden müssen. Das CPE wird beim Managed Service Provider (MSP) sein, wobei es einige geteilte Verantwortlichkeiten auf detaillierter Fähigkeitsebene gibt – dazu später mehr. Die interessante Ebene ist das Cloud Business Office (CBO).

Basierend auf Erfahrungen wird der MSP Teile des CBO-Clusters übernehmen. Nehmen wir das Produktmanagement als Beispiel. In einem Setup ohne MSP würde die gesamte Prozesskette vom Demand Management bis zur funktionalen Aufgliederung von einem internen Team durchgeführt. Mit einem MSP im Platform Engineering werden das Delivery Management des CPE und die funktionale Aufgliederung vollständig auf MSP-Seite sein. Engineering Support und Roadmap bleiben eine geteilte Verantwortung, die klare Mechanismen und etablierte Arbeitsweisen erfordert. Demand Management, d.h. die Anforderungen aus dem Business und die Priorisierung (inkl. Koordination der Entwicklungsteams) bleiben vollständig beim Kunden.

Betrachten wir auch das CPE genauer. Der Großteil liegt beim MSP, und die detaillierte Verwaltung der Fähigkeiten liegt dort; Umfang und Lieferqualität werden vertraglich definiert. Dennoch haben wir Fähigkeiten identifiziert, die noch in geteilter Verantwortung liegen und Zusammenarbeit auf operativer Ebene erfordern, z.B. Service-Integration, Security Governance oder Produktionsabnahme.

Wie in der Grafik gezeigt, bleibt die „People & Organization“-Dimension größtenteils intern, während es in den anderen geteilte Verantwortlichkeiten gibt. Insbesondere diese geteilten Verantwortlichkeiten werden potenzielle Reibungspunkte sein und letztendlich zwischen Modellen, die erfolgreich und weniger erfolgreich sind, unterscheiden.

Herausforderungen bei geteilten Verantwortlichkeiten

Die vorherigen Abschnitte haben gezeigt, dass geteilte Verantwortlichkeiten ein prägendes Merkmal des Modells mit externem Partner sind. Genau diese Schnittstellen sind es, die über Erfolg oder Misserfolg der Zusammenarbeit entscheiden – und sie erfordern eine bewusste, strukturierte Steuerung.

Informationsasymmetrie und Kompetenzverfall: Der Partner verfügt über tiefes operatives Wissen zur Plattform, während das interne Team die strategische Perspektive hält. Ohne strukturierten Wissenstransfer entstehen blinde Flecken – und je länger das operative Geschäft beim Partner liegt, desto stärker erodiert das interne technische Verständnis. Es entsteht eine Abhängigkeit, die die Steuerungsfähigkeit selbst untergräbt.

Diffuse Verantwortlichkeiten: Bei Themen wie Security Governance oder Service-Integration liegt Verantwortung im Graubereich zwischen den Parteien. Das klassische Muster: Beide Seiten gehen davon aus, dass die jeweils andere ein Thema adressiert – bis ein Vorfall die Lücke offenbart.

Zielkonflikte: Der Partner optimiert innerhalb seines Vertragsrahmens. Investitionen in Plattformqualität, technische Exzellenz oder Wissenstransfer, die über den definierten Scope hinausgehen, haben für ihn keinen unmittelbaren Anreiz – auch wenn sie für den langfristigen Erfolg des Kunden entscheidend sind.

DevOps: Für moderne Anwendungen, gerade z.B. bei KI-Anwendungen, ist die Empfehlung „You build it, you run it!”. D.h. es müssen Teams entstehen, die sowohl weiterentwickeln als auch den Betrieb sicherstellen. Auch diese müssen dann übergreifend funktionieren und dürfen nicht an o.g. Zielkonflikten scheitern.

FinOps: Die völlige Transparenz der Cloudkosten ermöglicht es dem Kunden, genau zu erheben welcher Preisanteil auf die Cloud und welcher auf den MSP entfällt. Der MSP braucht daher ein Geschäftsmodell, das auch ohne die frühere intransparente Mischkalkulation von Hardware, Software und Dienstleistung für alle Beteiligten funktioniert. Zudem findet die Kostenoptimierung gerade auch in den DevOps Teams statt.

Steuerung als strategisches Asset

Organisationen, die ihre Partnerzusammenarbeit bewusst als Kompetenz entwickeln, erzielen messbar bessere Ergebnisse. Effektive Steuerung geht über klassisches Vendor Management hinaus:

Technische Urteilsfähigkeit erhalten: Das interne Team muss architektonische Entscheidungen bewerten, Trade-offs verstehen und Qualität beurteilen können. Dies erfordert ein Minimum an technischer Tiefe, das durch gezielte Rotation, Reviews und Wissenstransfer-Formate aufrechterhalten wird.

Outcome-orientierte Steuerungsmechanismen: Statt reiner Input-Kontrolle (Anzahl Tickets, SLA-Einhaltung) sollten Mechanismen etabliert werden, die auf Geschäftsergebnisse ausgerichtet sind: Plattformadoption, Time-to-Market neuer Services, Sicherheitsposture. Dies schafft gemeinsame Anreize und reduziert die rein transaktionale Natur der Beziehung.

Transparenz und Wissenshoheit: Alle Architekturentscheidungen, Runbooks und Plattformdokumentationen müssen dem Kunden gehören und zugänglich sein. Ein Partner, der Wissen als Machtinstrument nutzt, wird zum Risiko statt zum Enabler. Wer frühzeitig in Steuerungskompetenz investiert, bewahrt sich strategische Optionalität – sei es für Insourcing, Partnerwechsel oder Neuzuschnitt des Modells.

Erfolgsfaktoren und konkrete Empfehlungen

1. Klare Governance und Verantwortungsteilung

Der Activity Split zeigt: Die strategische Steuerung (CLT) verbleibt ausnahmslos beim Kunden. Das ist nicht verhandelbar. Architektur- und Governance-Entscheidungen im CBO werden gemeinsam getroffen, während die technische Umsetzung im CPE vollständig beim MSP liegt.

Best Practice: Nutzen Sie ein RACI-Modell (Responsible, Accountable, Consulted, Informed), um Verantwortlichkeiten auf Aktivitätsebene transparent zu machen. Ergänzen Sie dieses um Service Level Agreements (SLAs).

2. Wissenstransfer und Vermeidung von Abhängigkeiten

• Everything-as-Code: Sämtliche Infrastruktur, Policies und Prozesse als Code versioniert im Repository des Kunden.
• Kontinuierlicher Wissenstransfer: Knowledge-Transfer-Sessions, Pair-Programming und Dokumentation.

3. Integration in die CCoE-Struktur

• Teilnahme an CCoE-Boards: Der Dienstleister berichtet regelmäßig über Plattform-KPIs.
• Feedback-Loops: Application Teams geben Feedback zur Plattform-Qualität.

4. Operative Exzellenz durch standardisierte Schnittstellen

• Deployment Pipelines: CI/CD-Pipelines gemeinsam definiert – Approval Gates beim Kunden.
• Observability: Gemeinsame Dashboards und Alerting für Transparenz.
• Regular Cadence: Wöchentliche Operational Reviews, monatliche Strategic Reviews.

Fazit

Die geteilten Verantwortlichkeiten sind die Bereiche, auf die sich das Management konzentrieren sollte – Exzellenz dort wird zu einem strategischen Asset für die Cloud-Organisation und ist eine strategische Kompetenz, wenn ein MSP integraler Bestandteil des CCOE ist.

Die hier skizzierte Blaupause kann verwendet werden, um Unternehmen zu unterstützen, die ihre Partnerbeziehung aufbauen oder bereits in einem etablierten MSP-Modell sind.

Über die Autoren

	Als Senior Customer Solutions Manager berät Benedikt Muschong Unternehmen bei ihrer Cloud Transformation und wie diese den Mehrwert von Cloud Technologie für das Unternehmen steigern können. Vor seiner Zeit bei AWS hat er mehrere Jahre in verschiedenen Positionen im IT-Outsourcing, Strategieberatung, sowie der fertigenden Industrie verbracht.
	Markus Wenzel ist seit vier Jahren Jahren Senior Customer Solutions Manager bei AWS und betreut Kunden beim Auf- und Ausbau ihrer Cloudnutzung, insbesondere bei den damit einhergehenden organisatorischen Veränderungen. Zuvor war er über 20 Jahre in verschiedenen Führungspositionen in der IT-Infrastruktur und hat IT-Betriebe im In- und Outsourcing verantwortet sowie die Übergänge in neue Betriebsmodelle geleitet.
	Rene-Martin Tudyka ist Senior Customer Solutions Manager bei AWS. Er unterstützt Unternehmenskunden bei Cloud-Transformationen und steht ihnen mit Rat und Tat zur Seite. Er verfügt über langjährige Erfahrung in der Entwicklung hochleistungsfähiger IT-Organisationen und in der erfolgreichen Einführung von Cloud-Lösungen in großem Maßstab.