---
title: "Cloud Team Services: Four Types, One Language"
description: "How the Cloud Team structures its services — from consulting to project enablement, platform services and internal capabilities. The service model as an orientation framework for everyone involved."
sidebar:
order: 4
label: "Service Types"
source_url: "https://framework.stackit.cloud/advisory/governance/service-types/"
source_file: "docs/advisory/governance/service-types.mdx"
---
## Why the Cloud Team needs a common language for its services
A Cloud Team delivers many different services — from strategic consulting for individual teams to operating central platform components. Without a common language, misunderstandings arise: teams expect operational support while the Cloud Team delivers governance consulting. Or vice versa: the Cloud Team operates a service that nobody consumes because it was never communicated.
Introducing a standardised service type model creates clarity on both sides: the Cloud Team knows what it offers. Application teams know what they can request. Leaders understand how the Cloud Team is structured and what kind of support is realistic.
## The four service types
Clearly defined support offerings for specific questions around cloud adoption and usage. The
entry point for teams that need quick orientation — without long-term commitment. Consulting
services are demand-driven, cover strategic and technical topics, and deliver direct feedback.
They range from conceptual guidance to hands-on support for specific challenges.
Involvement of the Cloud Team in projects to implement cloud solutions jointly with the project
team. Cloud Team members or capacities are assigned for the duration of the project and support
across all phases: analysis, planning, architecture, implementation, operations, and
optimisation. Overall responsibility remains with the project or application team — the Cloud
Team ensures compliance with governance requirements and platform standards.
Standardised, centrally provided and operated services that application teams can consume as
ready-made capabilities. Platform services are reusable, automatically provisioned, and ensure
that architecture, security, and operational standards are consistently maintained. Consumption
occurs via self-service or standardised service requests. Service ownership lies with the CCoE
(what), implementation with the Platform Team (how).
All Cloud Team activities that are not available as consumable services but are essential for
the foundation of all other service types. This includes: governance and oversight of cloud
adoption, implementation and enforcement of technical and organisational standards, and the
development of core platform capabilities. These activities cannot be requested by application
teams — they are ongoing core responsibilities of the Cloud Team.
## Service Portfolio vs. Service Catalog: Two different perspectives
An important distinction that is frequently conflated in practice:
The **Service Portfolio** encompasses all Cloud Team services — including those still in planning or development. It provides strategic and internal transparency about which capabilities the Cloud Team is building, offering, or retiring. The Service Portfolio is a management tool for the Cloud Team and leadership.
The **Service Catalog** contains only actively consumable services. It is the operational access point for application teams — what can I request, how, and with what outcome? The Service Catalog is a communication tool for application teams.
Conflating the two creates either unrealistic expectations (teams believe planned services are already available) or unnecessary confusion (teams must navigate internal planning documents to find out what they can use).
## Implications for CCoE structure
The service type model has direct implications for how the Cloud Team is organised:
Types A and B require capacity for direct interaction with application teams and projects — these are the enablement roles in the CCoE. Type C requires capacity for developing, operating, and evolving platform components — these are the engineering roles in the Platform Team. Type D is distributed across the entire Cloud Team — governance and standard definition (CCoE) as well as platform operations (Platform Team).
1. **Document the service portfolio:** What services does the Cloud Team currently deliver? Assign each to Types A through D. This inventory makes gaps visible and creates a common language.
2. **Maintain the service catalog:** Only include actively deliverable services in the catalog. Clear description: what does the service include, how is it requested, what is the expected outcome?
3. **Communicate:** Inform application teams about the service catalog. Many teams don't know what the Cloud Team can deliver — and therefore don't ask for support that would genuinely help them.
4. **Update regularly:** Services evolve, new ones are added, old ones are retired. The service catalog is a living document, not a one-time project.
Back to the **[Governance Overview](/advisory/governance/)**