---
title: "Cloud Team Services: vier Typen, eine Sprache"
description: "Wie das Cloud-Team seine Services strukturiert — von der Beratung über Project Enablement und Platform Services bis zu internen Fähigkeiten. Das Servicemodell als Orientierungsrahmen für alle Beteiligten."
sidebar:
  order: 4
  label: "Servicetypen"
source_url: "https://framework.stackit.cloud/de/advisory/governance/service-types/"
source_file: "docs/de/advisory/governance/service-types.mdx"
---

## 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](./files/service-typen-overview.svg)

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.

## Die vier Servicetypen

<CardGrid>
  <Card title="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.
  </Card>
  <Card title="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.
  </Card>
  <Card title="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).
  </Card>
  <Card title="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.
  </Card>
</CardGrid>

## 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).

## Auswirkungen auf die CCoE-Struktur

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).

<Steps>
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.

</Steps>

Zurück zum **[Governance-Überblick](/de/advisory/governance/)**
