Microsoft’s Current Model Separates Platform and Workload Ownership
Current Cloud Adoption Framework guidance describes platform teams as owning the lifecycle of the Azure landing zone and application workload teams as owning the end-to-end lifecycle of their workloads. The platform provides shared governance, security, identity, connectivity, and management capabilities; workload teams deploy and operate resources within those guardrails.
Microsoft Learn: DevOps team topologies for Azure landing zones
This is a useful starting point because it prevents two extremes: centralized IT operating every application resource, or every application team reinventing network, security, policy, monitoring, and subscription design.
The Platform Team Owns the Foundation
The exact scope varies, but platform responsibilities commonly include:
- Management-group hierarchy
- Subscription onboarding and placement
- Enterprise Azure Policy and exemption processes
- Core identity and RBAC patterns
- Shared network topology and hybrid connectivity
- Private DNS and shared name-resolution patterns
- Security and monitoring baselines
- Platform infrastructure as code and pipelines
- Shared logging and operational tooling where centralized
- Platform cost visibility and shared-service allocation
- Platform support, maintenance, and roadmap
These are capabilities that benefit multiple workloads or need consistent enterprise control. Centralizing them can reduce duplicated engineering and make governance easier to reason about.
Workload Teams Own the Business Service
Application teams should not hand operational responsibility back to the platform team merely because the resources are in Azure.
Workload ownership usually includes:
- Application architecture
- Workload-specific service selection
- Application code and deployment
- Workload identities and authorization
- Application configuration and secrets usage
- Application-level monitoring and service health
- Business recovery requirements
- Workload cost decisions
- Application documentation and support
- Compliance with the platform’s published guardrails
The platform team can provide templates, modules, monitoring services, backup capabilities, and approved network paths. The workload team still has to decide how the application uses them.
Centralize Only What Creates Clear Shared Value
Current Azure landing-zone guidance says centralized capabilities should exist where they provide clear governance, operational, or economic benefit across workloads.
Microsoft Learn: What is an Azure landing zone?
This is an important constraint. “The platform team can own it” is not the same as “the platform team should own it.”
If centralization makes every application deployment wait for a ticket, the platform has probably centralized too much or failed to automate the capability.
Networking Is a Good Example of Shared Responsibility
The platform team might own the hub, Virtual WAN, ExpressRoute, VPN, firewall, DNS Private Resolver, IPAM, and enterprise egress model.
The workload team might own its spoke VNet, subnet design, private endpoints, application NSGs, service ingress, and workload routing within published constraints.
The boundary depends on organization size and skills, but it should be explicit. “Networking owns Azure networking” is too broad to be useful.
Security Is Also Shared
The central security and platform teams might define required Defender for Cloud plans, identity baselines, public exposure controls, diagnostics, vulnerability-management expectations, policy assignments, and incident-integration requirements.
The workload team still owns the security of its application design, data flows, identities, secrets, service configuration, dependency choices, and application-specific findings.
A platform can enforce a baseline. It cannot make an insecure application architecture safe by inheritance.
Use a Responsibility Matrix for the Grey Areas
| Capability | Platform team | Workload team |
|---|---|---|
| Management groups | Own | Consume |
| Application subscription | Provision and govern | Operate workload resources |
| Enterprise policy | Own baseline | Comply / request exception |
| Shared connectivity | Own | Declare requirements |
| Application monitoring | Provide standards/tools | Own signals and response |
| Workload recovery | Provide capabilities/patterns | Own RPO/RTO and validation |
The exact entries can change. What matters is that ownership is discussed before an incident exposes the gap.
The Platform Team Should Operate Like a Product Team
Microsoft’s platform-engineering guidance emphasizes self-service, automation, and a product mindset. The platform exists to improve developer and operator outcomes within a governed framework.
Microsoft Learn: What is platform engineering?
That means the platform backlog should not be only infrastructure work. It should include user experience:
- How long does it take to get a subscription?
- Can a team understand why policy blocked a deployment?
- Are approved network patterns documented?
- Can teams discover reusable modules?
- Are common tasks self-service?
- Do teams know where platform responsibility ends?
A technically strong landing zone can still be a poor platform if consuming it requires knowing the right person to message.
Avoid Becoming a Ticket Factory
The platform team should not manually approve every resource, subnet, role assignment, log setting, or service change.
Use policy, RBAC, subscription boundaries, approved modules, pipelines, and self-service workflows to turn repeatable decisions into platform behavior.
Reserve manual review for decisions that genuinely need judgment: exceptions, unusual connectivity, regulatory requirements, material architecture deviations, or high-risk changes.
If the same request is approved the same way every week, it is probably automation waiting to happen.
Define an Escalation Path
Workload teams need to know what to do when the standard platform path does not fit.
- Who reviews architecture exceptions?
- Who owns policy exemptions?
- Who decides whether a shared service should be added?
- Who approves new connectivity patterns?
- Who resolves platform incidents versus application incidents?
Without an escalation path, teams either wait indefinitely or bypass the platform.
Measure Platform Outcomes, Not Ticket Volume
A busy platform team is not necessarily an effective platform team.
- Time to onboard a new workload
- Percentage of onboarding completed through automation
- Number and age of policy exceptions
- Number of repeated manual requests
- Platform incidents and recovery time
- Adoption of approved modules and patterns
- Workload-team satisfaction with the platform
- Cost visibility for shared services
The platform should get easier to consume as it matures.
Build the Platform Team Cross-Functionally
A landing zone touches disciplines that are often distributed across different departments. A platform team built only from infrastructure engineers can move quickly at first but still create bottlenecks when identity, security, networking, cost, or compliance decisions require another team.
Microsoft’s current platform-team guidance recommends cross-functional representation. In practice, that can include core platform engineers with established participation from security, identity, networking, operations, FinOps, architecture, and relevant business stakeholders.
Not everyone needs to sit in the same reporting line. The operating model needs clear decision rights so routine platform choices do not require a new steering meeting every time.
Define On-Call and Incident Boundaries
Ownership becomes most visible during an incident.
- If ExpressRoute fails, who leads?
- If an application cannot resolve a private endpoint, who owns the first triage?
- If an Azure Policy blocks an emergency change, who can approve an exception?
- If the central Log Analytics workspace is unavailable, who responds?
- If a workload causes a shared firewall capacity problem, who coordinates remediation?
Define platform incident ownership and workload incident ownership before a severity-one event. Shared incidents need a handoff path, not an argument about whether the issue is “the network” or “the application.”
Publish a Small Platform Service Catalog
Workload teams should be able to discover what the platform provides without reading the landing-zone repository.
A practical service catalog might describe:
- Application landing-zone subscription products
- Connectivity options
- Private DNS and private endpoint patterns
- Approved IaC modules
- Monitoring and logging services
- Security baseline and exemption process
- Backup and recovery platform capabilities
- Cost-management expectations
- Support and escalation routes
The catalog can begin as documentation. The important part is making the platform contract visible and stable enough that teams can design against it.
Revisit the Responsibility Model as Azure Adoption Changes
A small organization might centrally operate most application landing zones because workload teams do not yet have cloud skills. Later, those teams may become capable of owning more networking, IaC, monitoring, and cost decisions. The opposite can also happen when regulation or acquisitions increase central requirements.
Ownership should evolve deliberately. Review the platform/workload boundary when the organization adds new business units, regions, regulated workloads, managed services, or platform engineering capabilities.
The goal is not to preserve the original RACI forever. It is to preserve clear accountability as the operating model changes.
Give the Platform Team a Written Charter
A short charter can prevent months of ambiguity. Document the platform mission, the services it provides, the capabilities it owns, the decisions it does not own, the primary users of the platform, the escalation path, and how priorities are set. Include the boundaries between platform, security, operations, network, and workload teams.
The charter should also identify what success looks like. Examples include faster workload onboarding, fewer manual approvals, consistent policy and security baselines, reliable shared connectivity, clear ownership, and a declining number of repeated platform tickets. A platform team without a charter can easily become whichever queue receives the problem nobody else wants.
A Minimum Platform-Team Operating Checklist
Before Azure adoption accelerates, publish the platform charter, name owners for management groups, policy, shared connectivity, DNS, platform IaC, security integrations, monitoring, cost visibility, subscription onboarding, and platform incidents. Define what application teams receive as a service and what they remain responsible for after handoff.
Also establish a backlog and release process for the platform itself. Landing zones change. Policies evolve, network capabilities expand, modules are upgraded, and new workload types appear. The platform team needs a controlled way to test, communicate, deploy, and support those changes just as an application product team does.
When these basics are explicit, workload teams can work with the platform rather than discovering its ownership boundaries during delivery or incidents.
Platform-Team Warning Signs
- “The cloud team owns anything in Azure.”
- “Application teams cannot deploy without a ticket.”
- “The platform team owns monitoring, so the application team does not need alerts.”
- “Security owns policy, but nobody owns policy operations.”
- “Only one engineer understands the landing-zone repository.”
- “Every workload exception becomes a permanent platform feature.”
Define the Team Before You Need the Team
A small Azure footprint can survive informal ownership because the same few people know everything. Scale removes that advantage.
Define what the platform owns, what workload teams own, which capabilities are shared, and how exceptions move through the organization before the environment depends on unwritten knowledge.
BI Cloud Tech’s Platform Engineering expertise, Azure Operations, and Managed Services are relevant when organizations need to establish or mature an Azure operating model around the landing zone.
The platform team owns the paved road. Workload teams own where their applications need to go.
