A migration can move every server and leave the organisation exactly where it was. The workloads now run in the cloud, but a new environment still takes three weeks and four approvals, every firewall change still waits for the Thursday change board, the infrastructure team still builds everything by hand, and the application that went live last year still has no owner beyond the project that delivered it.
This is the quiet failure of many cloud programmes. The technology can now change in minutes; the organisation still changes in months. One of two things then happens. Either the old process wins, and the business pays cloud prices for data-centre speed, or teams route around the process, and the organisation gets speed without control: unowned accounts, untagged spend and security settings nobody chose.
Neither outcome is a technology problem. Both are an operating model that did not move with the workloads. Bushbuck Brands is fictional, and its systems and figures are illustrative. Bushbuck, the distributor we follow through this series, met both outcomes within a year of its first migration wave.
Two failures, one cause
Bushbuck's IT team of 22 had run a co-location data centre for a decade, and its processes fitted that world. Environments were requested by ticket, built by the infrastructure team and approved by a monthly change advisory board. Cost was a capital decision made every few years. Projects delivered applications and handed them to an operations team that had not built them.
After the first wave, two things happened at once. The trade portal team, under pressure to add features for independent retailers, found that a new test environment took three weeks. So two developers opened accounts on a company credit card and built one themselves, outside the landing zone, with no tags and a public database endpoint. Meanwhile, the infrastructure team, determined to stay in control, insisted on reviewing every resource request individually. Its queue grew to six weeks.
The first is speed without control. The second is control without speed. They look like opposite problems, and they share one cause: governance that exists only as human approval, which cannot keep up with the rate at which the cloud lets people change things. The answer is not to remove the governance. It is to change its form, from a gate that people pass through one at a time into reusable controls that apply to everyone, automatically, every time.
From tickets to paved roads
Each data-centre mechanism existed for a good reason. The point is to keep the reason and replace the mechanism.
Self-service vending. A team requests a new account or subscription through a form or a pipeline, and it arrives already connected to the network, with identity, logging, security monitoring, budgets and tags in place. The approval that used to be a human reading a ticket becomes the design of the vending process itself. Bushbuck's vending takes under a day; the old process took three weeks.
Policy as code. Rules that a committee used to apply by reading requests are written as policy and enforced by the platform: approved regions only, no public IP addresses without an exception, mandatory tags, encryption on by default, approved machine sizes for non-production. The change board stops reviewing every resource and reviews only exceptions, the requests that need to break a rule, with a reason and an expiry date.
Paved roads. Instead of building everything, the platform team builds a small number of well-supported paths: a standard way to deploy a web application, a containerised service, a scheduled job or a managed database, with security, monitoring and cost allocation already wired in. Teams that use the paved road get speed and support. Teams that need something different can do it, but they own the extra work. Our piece on why platform engineering matters goes further into how such a team works.
A living forecast. The annual estimate stays as a budget, but the forecast is updated monthly from actual demand and unit cost, using the review set up in Part 5.
Lifecycle ownership. Every application, or group of related applications, has a product owner who remains accountable after launch for its cost, its reliability, its security posture and the decision about its future. The project ends; the ownership does not.
Safe defaults, set together
The most important design choice in a cloud operating model is who sets the defaults. If security sets them alone, they will be safe and unusable. If engineering sets them alone, they will be fast and unaffordable. If finance sets them alone, they will be cheap and fragile.
The functions that used to approve requests one at a time now agree the boundary once, together:
- Security defines identity, network exposure, encryption, logging and vulnerability standards.
- Architecture defines approved patterns, regions, services and integration rules.
- Finance defines tagging, budgets, alert thresholds and commitment policy.
- Operations defines monitoring, backup, recovery objectives and support expectations.
Inside that boundary, workload teams move without asking permission for routine change. And because the controls are automated, the evidence that teams stayed inside the boundary is produced automatically too: policy compliance reports, tag coverage, cost per team, backup status. The audit conversation changes from "show me your approvals" to "show me the policy and its results", which is a better answer to a regulator or an auditor than a folder of signed forms.
This is also where landing-zone design earns its place. A landing zone is the technical form of these agreed defaults: the account structure, network, identity and policy into which every workload is vended.
What changed at Bushbuck
Bushbuck made five changes over about four months, deliberately in this order:
- It formed a four-person platform team from the existing infrastructure team. Nobody was hired for it; the people who used to build servers by hand now build the vending process, the policies and the paved roads. Two of them needed training on infrastructure as code, which was the single largest cost of the change.
- It built account vending and a first set of policies: approved South African regions, mandatory tags, no public IP addresses or public database endpoints without an approved exception, and automatic shutdown for non-production outside working hours. The credit-card account was brought into the landing zone in the first week.
- It published three paved roads: a web application on a managed container platform, a scheduled batch job, and a managed SQL database. Between them they covered most of the applications in the next wave.
- It named a product owner for each application group. The head of logistics owns the warehouse management system and route planning; the head of trade sales owns the trade portal and the EDI order API. Each owner receives the budget alerts and the monthly unit-cost report for their group.
- It changed the change board. It now meets fortnightly, reviews exceptions and incidents only, and every approved exception carries an expiry date. Its agenda shrank from about 60 items to fewer than ten.
The results were not dramatic in any one month, which is the point. New environments arrive in under a day instead of three weeks. Tag coverage went from about 40% of spend to over 95%. The six-week queue disappeared, and with it the reason for teams to route around the platform.
The people part
Operating model changes fail more often on people than on tooling. Three things are worth saying plainly.
Roles change, and that is unsettling. An infrastructure engineer who was valued for building servers is now asked to write policy and code. Some will welcome it; some will not. Training budget and time to learn are part of the migration cost, not an optional extra. In a South African market where experienced cloud engineers are scarce and expensive, growing your own is usually cheaper than hiring, and more likely to keep the people who understand your estate.
Product ownership needs authority to mean anything. A product owner who is accountable for cost but cannot prioritise the work that reduces it is a scapegoat, not an owner. Bushbuck's owners control the backlog for their application group, including the technical debt items that the platform team identifies.
Governance people need a new way to add value. Security and architecture reviewers who used to approve requests now design the policies and review exceptions. That is a more influential role, not a lesser one, but it needs to be explained that way. Our piece on DevSecOps as culture rather than tools covers the security side of this shift.
Common mistakes
- Keeping the change board for every resource. Human review of routine change cannot keep pace with the cloud. Automate the routine; review the exceptions.
- Removing governance in the name of speed. Speed without controls produces unowned accounts, untagged spend and public endpoints nobody chose.
- Building a platform nobody asked for. Paved roads should cover the paths most teams actually need, starting with the next migration wave.
- Naming owners without giving them authority. Accountability without control of the backlog does not reduce cost or risk.
- Treating the operating model as phase two. By phase two, teams have already learned to route around the old process.
- Skipping the training budget. The people who ran the data centre are the best people to run the platform, if they are given time to learn.
A decision you can defend
We will replace Bushbuck's resource-by-resource change approval with self-service account vending, policy as code and three paved roads, run by a four-person platform team formed from the infrastructure team. Security, architecture, finance and operations will agree the default policies together, and the change board will review exceptions only, each with an expiry date. Every application group will have a product owner who receives its alerts and unit-cost reports and controls its backlog. We accept a training cost and some short-term disruption to the infrastructure team's roles. We will review the model after six months against three measures: time to a new environment, tag coverage of spend, and the number of exceptions that become permanent.
What to take from this part
Cloud speed without an operating model creates uncontrolled consumption. Teams will route around a process that cannot keep up.
Governance without automation recreates the ticket queue. Keep the control, change its form.
Set the defaults together. Security, architecture, finance and operations agree the boundary once, and the platform enforces it every time.
Ownership outlives the project. Every application needs an owner with authority over its backlog after launch.
Next in the series: Retain, repatriate or retire: correcting placement without ideology.
How CloudNala can help
We help organisations move their operating model with their workloads: designing account vending and policy as code, choosing the first paved roads from the real migration backlog, redesigning the change process around exceptions, and defining product ownership that comes with the authority to act. We work alongside existing infrastructure teams so that the people who know the estate end up running the platform.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Review or write to us at consult@cloudnala.co.za