Last updated on
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.
Type A: Consulting Services
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.
Type B: Project Enablement
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.
Type C: Platform Services
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).
Type D: Internal Cloud Activities
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.
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).
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).
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.
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?
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.
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