Blyde Financial Services, the fictional South African financial-services group this series has followed, learned most of this series the expensive way. It started with four empty Azure subscriptions, rebuilt them as a platform landing zone with four application landing zones, ran the result as a product and encoded its standards in modules. Only then did it extend the foundation for data, AI and agents. Asked what it would do if it started again, its platform team of four described a different year: one that a mid-sized organisation can run alongside its day job, with dozens of workloads rather than hundreds and a board that wants to see AI this year.
This final part sets out that year as a 12-month roadmap. The durations are illustrative estimates for an organisation of Blyde's size, not commitments. Your own will depend on your estate, your skills and how much of the foundation already exists. What should not change is the order, and the rule that each phase starts only when the previous one has evidence, not a status report.
The year at a glance
The phases overlap, because a platform team does not stop improving the foundation when the first workload arrives. But no phase skips the one before it. The year ends with an agent that recommends and does not act. That is deliberate. Authority comes after the evidence, not with the first release.
Months 0 to 2: discovery
Discovery answers four questions before anything is built.
- What exists? Every subscription or account, who owns it, what runs in it and how it is connected. Most organisations find more than they expected, including shadow AI pilots with their own keys.
- What must be kept? Identity providers, network links to data centres, logging contracts and security tooling that the platform must integrate with rather than replace.
- What are the obligations? Data protection under POPIA, sector requirements for financial institutions, record-keeping and the board's risk appetite. Get legal and compliance in the room early. This is general information, not legal advice.
- Which workload goes first? Pick one that matters, is not the most sensitive system you have and has a team willing to be the first customer. In Blyde's replanned year that is document processing, which already had a cloud pilot and a clear owner.
The output is a short current-state report, a decision on the cloud platform or platforms, and a named product owner for the landing zone. Choose the workload before the cloud and Hybrid and multicloud without architecture theatre help with the platform decision.
Months 1 to 4: a minimum viable platform foundation
The minimum viable platform landing zone is the smallest foundation that is safe for one real production workload. It covers the six design areas from part 2 at their simplest:
- an account or subscription structure with separate places for platform, production and non-production workloads;
- identity integrated with the workforce directory, with privileged access controlled;
- hub connectivity, egress control and DNS (see Enterprise landing-zone networking);
- baseline policy as code, central logging and security monitoring;
- backup and a tested restore;
- cost tags and budgets from the first resource.
Build it from the vendor's reference implementation rather than from scratch: Azure landing zones, AWS Control Tower or the Landing Zone Accelerator, or Google Cloud's landing-zone guidance. Deploy it through code, using the modules described in part 5. Resist adding everything the reference shows. Anything the first workload does not need can wait for the backlog.
Gate 1: the platform baseline is live. The evidence is policies enforced, logs arriving centrally and a restore that has actually been performed.
Months 3 to 6: the first application landing zone
The first application landing zone proves the platform on a real workload. It is also the first test of the boundary from part 3: the platform team issues the space and its guardrails, and the document-processing team builds and runs inside it.
Expect friction, and treat it as the most valuable output of the phase. Every request the workload team has to raise by ticket is a candidate for the platform backlog. Landing zones are products, not one-off projects explains how to run that backlog.
Gate 2: the first workload is onboarded. The evidence is a second application landing zone issued in days, not months, using the same templates.
Months 5 to 9: the data landing zone, for two data products
Do not try to govern the whole data estate. Pick the two data products the next AI workload needs. For Blyde these were scanned claims documents and the policy library for the knowledge assistant. Build the governance plane around them, as described in part 6:
- a catalogue entry with a named owner and steward;
- classification at publication, including special personal information;
- quality tests on each load, with results published;
- lineage to source systems;
- access by purpose through the platform's identity service;
- a retention rule with a monitored deletion job.
Gate 3: data products have owners. The evidence is two products with contracts, classifications and quality results that another team is consuming.
Months 7 to 11: the AI landing zone
Extend the foundation for AI only once trusted data exists. The sequence from part 7 applies:
- route the existing AI pilot through a shared gateway, so cost and usage are visible;
- publish the approved model catalogue and the policy that blocks unapproved deployments;
- move prompts into a registry and write the first evaluation set with the workload team;
- switch grounding to the published data products;
- set a release threshold with the risk function.
Gate 4: evaluation gates release. The evidence is a threshold that has actually blocked a prompt or model change. A threshold that has never stopped anything has not yet been tested.
Months 10 to 12: a recommend-only agent pilot
The year ends with an agent, but not an agent that acts. Blyde's arrears-support agent from part 8 runs in recommend-only mode. It retrieves evidence and drafts options, and the adviser does everything else. This phase builds the agentic landing zone's skeleton while the stakes are low:
- an agent identity and named sponsor;
- a draft authority grant, with actions, scope, limits, duration and sponsor, reviewed by the business owner and compliance;
- policy enforcement and credential brokering in place, even though the grant is read-only;
- tracing and whole-task evaluation on labelled cases;
- a kill switch, tested.
Gate 5: the authority matrix is signed. The evidence is a signed grant and a kill switch that has been pulled in a test. Only then should the agent be allowed to take its first low-risk action, in year two.
If you already have part of the foundation
Few organisations start from nothing. Most have a cloud estate built project by project, a data platform and at least one AI pilot. Do not restart the roadmap. Treat each gate as an audit question instead.
- Can you show the evidence for Gate 1 today? If not, the platform landing zone is the first piece of work, whatever else is running.
- Does every existing AI pilot read published data products, with owners and classifications? If not, Gate 3 comes before any new AI workload.
- Does any agent already act in a business system? If so, Gate 5 is urgent. Give that agent its own identity, a sponsor, a signed grant and a tested kill switch before it is allowed to do more.
Work from the lowest gate you cannot evidence, and run the later phases only as fast as the earlier gates allow. The roadmap then becomes a remediation plan with the same order, rather than a second programme competing with the first.
Ownership and adoption, all year
The bottom row of the roadmap is the one that decides whether the rest survives. From the first month the landing zone needs:
- a product owner with a backlog and the authority to prioritise it;
- a support route that workload teams actually use;
- measures reported monthly: time to issue an application landing zone, policy compliance, restore tests passed, support demand and, later, data products with owners and AI changes blocked by thresholds;
- a responsibility map, such as the one in part 9, agreed by platform, data, AI, risk and business owners.
As an illustrative estimate, a platform team of four to six people with access to security, network and data specialists can run this roadmap for an organisation of Blyde's size. Fewer people means a longer year, not fewer gates.
What to cut when the year gets shorter
Most roadmaps lose time. When that happens, cut scope inside a phase, never the phase itself.
| Under pressure to... | Cut this | Never cut this |
|---|---|---|
| Show AI sooner | The number of AI workloads in year one | The data products and the evaluation threshold under the first one |
| Finish the platform faster | Optional services, extra regions, nice-to-have automation | Identity, central logging, policy and a tested restore |
| Reduce data work | The number of data products | Owners, classification and access by purpose for the ones you publish |
| Launch the agent | The number of tools and actions | Agent identity, the grant, policy before action and the kill switch |
| Save headcount | The pace of the roadmap | The product owner and the monthly measures |
Key points
- The order is fixed: discovery, platform foundation, first application landing zone, data extension, AI extension, recommend-only agent. The durations are illustrative estimates.
- Each phase starts only when the previous gate has evidence, such as a restore that worked, a workload onboarded quickly, owned data products, a threshold that blocked a change and a kill switch that was pulled.
- Extend data and AI only for the workloads in front of you, never for the whole estate at once.
- End the year with an agent that recommends, not one that acts. Authority comes in year two, on evidence.
- Ownership and measures run all year, and they are what keep the foundation alive after the project team leaves.
That is the series in one sentence per layer. Govern the environment first. Govern the data next. Govern the intelligence before trusting it. Govern the authority before allowing it to act.
This is part 10, the final part, of Cloud Foundations, Explained End to End. Previous: One enterprise, four landing zones. To start from the beginning, read the series page or part 1, A cloud landing zone is a serviced estate, not an empty subscription.
How CloudNala can help
CloudNala builds landing-zone roadmaps with mid-sized organisations that need to move to cloud, data and AI without a large platform team. We run the discovery, size each phase against your estate and skills, and choose the first workload with you. We define the evidence for each gate and set up the product ownership and monthly measures, so that the plan survives contact with the rest of the year.
Background reading: Microsoft, Azure landing zones; AWS, Landing Zone Accelerator on AWS; Google Cloud, Landing zone design; NIST, AI RMF.
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.
Book a Landing Zone Review or write to us at consult@cloudnala.co.za