Zum Inhalt springen
Beta

Cloud Team Services: vier Typen, eine Sprache

Zuletzt aktualisiert am

Warum das Cloud-Team eine gemeinsame Sprache für seine Services braucht

Abschnitt betitelt „Warum das Cloud-Team eine gemeinsame Sprache für seine Services braucht“

Ein Cloud-Team erbringt viele verschiedene Dienstleistungen — von der strategischen Beratung einzelner Teams bis zum Betrieb zentraler Plattformkomponenten. Ohne eine gemeinsame Sprache entstehen Missverständnisse: Teams erwarten operative Unterstützung, das Cloud-Team leistet Governance-Beratung. Oder umgekehrt: Das Cloud-Team betreibt einen Service, den niemand in Anspruch nimmt, weil er nie kommuniziert wurde.

Servicetypen Übersicht

Die Einführung eines einheitlichen Servicetypen-Modells schafft Klarheit auf beiden Seiten: Das Cloud-Team weiß, was es bietet. Anwendungsteams wissen, was sie anfordern können. Die Führungskräfte verstehen, wie das Cloud-Team strukturiert ist und welche Art von Unterstützung realistisch ist.

Typ A: Beratungsleistungen

Klar definierte Support-Angebote für spezifische Fragen rund um die Cloud-Einführung und -Nutzung. Der Einstieg für Teams, die sich schnell orientieren müssen — ohne langfristige Bindung. Beratungsleistungen sind bedarfsorientiert, decken strategische und technische Themen ab und geben direktes Feedback. Sie reichen von der konzeptionellen Begleitung bis zur praktischen Unterstützung bei spezifischen Herausforderungen.

Typ B: Project Enablement

Einbindung des Cloud-Teams in Projekte, um gemeinsam mit dem Projektteam Cloud-Lösungen umzusetzen. Cloud-Teammitglieder oder Kapazitäten werden für die Dauer des Projekts zugewiesen und unterstützen in allen Phasen: Analyse, Planung, Architektur, Implementierung, Betrieb und Optimierung. Die Gesamtverantwortung bleibt beim Projekt- oder Applikationsteam — das Cloud-Team stellt die Einhaltung von Governance-Anforderungen und Plattform-Standards sicher.

Typ C: Platform Services

Standardisierte, zentral bereitgestellte und betriebene Dienste, die Anwendungsteams als vorgefertigte Fähigkeiten konsumieren können. Platform Services sind wiederverwendbar, werden automatisch bereitgestellt und stellen die konsistente Einhaltung von Architektur-, Sicherheits- und Betriebsstandards sicher. Der Verbrauch erfolgt über Self-Service oder standardisierte Serviceanfragen. Die Serviceverantwortung liegt beim CCoE (was), die Umsetzung beim Plattform-Team (wie).

Typ D: Interne Cloud-Aktivitäten

Alle Cloud-Team-Aktivitäten, die nicht als konsumierbare Services verfügbar sind, aber für die Grundlage aller anderen Servicetypen unerlässlich sind. Dazu gehören: Governance und Beaufsichtigung der Cloud-Einführung, Implementierung und Durchsetzung von technischen und organisatorischen Standards und die Entwicklung der Kernfunktionen der Plattform. Diese Aktivitäten können nicht von Anwendungsteams angefordert werden — sie sind dauerhafte Kernaufgaben des Cloud-Teams.

Service Portfolio vs. Service Katalog: zwei verschiedene Perspektiven

Abschnitt betitelt „Service Portfolio vs. Service Katalog: zwei verschiedene Perspektiven“

Eine wichtige Unterscheidung, die in der Praxis häufig verwischt wird:

Das Service Portfolio umfasst alle Cloud-Team-Services — auch solche, die sich noch in Planung oder Entwicklung befinden. Es bietet strategische und interne Transparenz darüber, welche Fähigkeiten das Cloud-Team aufbaut, anbietet oder in den Ruhestand versetzt. Das Service Portfolio ist ein Management-Tool für das Cloud-Team und die Führung.

Der Servicekatalog enthält nur aktiv konsumierbare Services. Er ist der operative Zugangspunkt für Anwendungsteams — was kann ich wie und mit welchem Ergebnis anfordern? Der Servicekatalog ist ein Kommunikationsinstrument für Anwendungsteams.

Die Verschmelzung der beiden schafft entweder unrealistische Erwartungen (die Teams glauben, dass geplante Services bereits verfügbar sind) oder unnötige Verwirrung (die Teams müssen sich durch interne Planungsdokumente bewegen, um herauszufinden, was sie verwenden können).

Das Servicetypen-Modell hat direkte Auswirkungen auf die Organisation des Cloud-Teams:

Die Typen A und B erfordern die Fähigkeit zur direkten Interaktion mit Anwendungsteams und Projekten — dies sind die Enablement-Rollen im CCoE. Typ C erfordert Kapazitäten für die Entwicklung, den Betrieb und die Weiterentwicklung von Plattformkomponenten — dies sind die technischen Rollen im Plattform-Team. Typ D ist über das gesamte Cloud-Team verteilt — Governance und Standarddefinition (CCoE) sowie Plattformbetrieb (Plattform-Team).

  1. Serviceportfolio dokumentieren: Welche Services erbringt das Cloud-Team aktuell? Ordnen Sie sie jeweils den Typen A bis D zu. Diese Bestandsaufnahme macht Lücken sichtbar und schafft eine gemeinsame Sprache.

  2. Servicekatalog pflegen: Nur aktiv erbringbare Leistungen in den Katalog aufnehmen. Klare Beschreibung: Was beinhaltet die Leistung, wie wird sie angefordert, was ist das erwartete Ergebnis?

  3. Kommunizieren: Anwendungsteams über den Servicekatalog informieren. Viele Teams wissen nicht, was das Cloud-Team leisten kann — und fragen daher nicht nach Unterstützung, die ihnen wirklich hilft.

  4. Regelmäßig aktualisieren: Dienste werden weiterentwickelt, neue hinzugefügt, alte werden in den Ruhestand versetzt. Der Servicekatalog ist ein lebendes Dokument, kein einmaliges Projekt.

Zurück zum Governance-Überblick