About this series. This series follows fakey.xyz — a fictional 400-person Wellington fintech — from the day it receives its cloud mandate through a full year of building and running an Azure landing zone. The company is not real. Every problem in it is. If you are a cloud or solutions architect, a DevOps engineer, or a delivery lead, you will recognise most of it.
Monday, 3 February. 9:15am. Level 4, The Terrace, Wellington.
Fakey McFakerson, Head of Engineering at fakey.xyz, reads the email twice before she believes it.
It is from Barry Bigboss, CEO, following up on Friday’s board meeting:
Fakey — following board discussion, we have approved the three-year technology strategy, including the datacentre exit. You will lead the cloud platform workstream. We need the Azure foundation in place this financial year, and the first product migration before FY26 close. The board’s risk committee has asked specifically how we will meet our obligations to the Reserve Bank and our clients’ security reviews. Come prepared to the next exec meeting with an approach. Two weeks.
Three sentences. Fakey reads a fourth meaning between the lines: no budget has been discussed. No team has been discussed. And if this goes wrong, it is yours.
She puts the laptop down and thinks about who to talk to first. That instinct — who, before what — is the single decision that most determines whether this landing zone survives.
The Two Ways This Story Goes
Here is what Fakey could do, and what many real teams do:
Version A: The Rush. She assigns her strongest engineer, Robbie Deployment, to “get Azure stood up.” Robbie finds the ALZ reference implementation, deploys the accelerator in a fortnight, presents a working management group hierarchy at the exec meeting. Everyone applauds. Fourteen months later the platform is fighting the business on every front — wrong subscription boundaries, unattributable costs, a network design the app teams hate, and a security review it cannot pass. Nobody can explain why any of it is the way it is.
Version B: The Scoping. Fakey spends the two weeks not deploying anything, but establishing the three things a landing zone needs before a single line of IaC: a sponsor with money, a team with a mandate, and a written statement of problems it must solve.
fakey.xyz takes Version B. Here is what that actually looks like, day by day — because this is the part of the story that never gets written down.
Week One, Day 1: Find Out If the Sponsor Is Real
Fakey’s first meeting is not with engineers. It is with Penny Pockets, CFO — because the question that shapes everything is not technical.
Fakey: “Is this funded, or is this approved?”
Penny: “The board approved the strategy. The budget comes out of your divisional envelope for this FY. There is no new headcount until the next annual plan.”
This is a crucial, very NZ moment. The mandate is real, the funding is not new money, and there is no new headcount until the next FY planning round — roughly nine months away. Fakey now knows the hardest constraint before writing a single requirement: her platform team will come from re-tasking existing engineers, not hiring.
Lesson 1 — Establish funding reality before anything else. “Approved” and “funded” are different words, and the gap between them is where landing zones die. Write down, on day one: what money exists, what people exist, and what date the next funding decision happens. These three numbers constrain every design decision to follow.
Fakey also asks Penny one more question, which sounds like a finance question and is actually an architecture question:
“When the board asks for a cost breakdown by product line — can finance produce one today?”
The answer is no. fakey.xyz’s finance reporting runs on product codes; cloud spend, once it exists, will need to map to them. Fakey writes this down. It will become, months from now, the backbone of the subscription strategy — but today it is just a note.
Week One, Day 3: Name the Real Drivers — All of Them
Fakey books thirty minutes with Serge Secure, fakey.xyz’s Security and Risk Lead, and gets the regulatory picture, which in a NZ licensed fintech is sharper than most.
Serge lays out four drivers, and this is where the landing zone’s true requirements document starts to form:
RBNZ outsourcing and cyber resilience (BS11 and related). fakey.xyz is RBNZ-supervised. Serge needs demonstrable security capability and third-party accountability — meaning the platform must produce evidence (logging, access records, control attestations) as a byproduct of operation, not as a manual quarterly project. Where Australian-regulated counterparties or group entities are in play, APRA CPS 234 evidence expectations may also land on the same design, without being the same rulebook.
Client security questionnaires. fakey.xyz’s two largest enterprise clients have both escalated their vendor due-diligence this year. Serge: “We have had two questionnaires sit unanswered for six weeks because we could not evidence where data lives or who accessed what. That is a revenue risk, not just a security one.” Fakey notes this — it means governance is not a cost centre in this story; it will later become sales enablement.
Privacy Act 2020. fakey.xyz processes a lot of personal information — payment and identity data. Serge’s concerns: breach detectability (the notifiable-breach clock under the Privacy Act means you must be able to detect), and cross-border clarity on where data actually resides.
The datacentre exit itself. fakey.xyz’s primary site is a colo facility in Petone, with hardware reaching end-of-support across FY26–27. The exit is a hard business driver with a hard business date.
Fakey now has something most landing zone teams never have: four named business drivers, each with a named stakeholder who cares about them. She writes a one-page document titled — plainly — “What is this platform for?” It will outlive every architecture diagram she produces.
Lesson 2 — The requirements document for your landing zone is a list of drivers with names attached, not a reference architecture. “RBNZ BS11 evidence — Serge” is a requirement. “Hub-spoke topology” is a design guess until it is justified against one.
Week One, Day 5: The Team Question
Fakey’s team is six engineers, all fully allocated to product delivery. There is no platform team. Barry’s email said “you will lead the cloud platform workstream” — but Fakey knows that in a lean NZ organisation, a workstream with no resourced team is a workstream with a resignation in it.
She negotiates — hard, and in this order:
- One senior engineer, 100% allocated. She picks Robbie Deployment, her strongest infrastructure engineer — with one condition attached, which we will see in Part 3.
- Herself as part-time platform lead (roughly 40%), explicitly reducing her product delivery load, not stacking it on top.
- A shared-services arrangement: the existing security engineer (reporting to Serge) spends 20% on platform security controls, and finance assigns Tessa Spreadsheet 10% for cost attribution design.
- A written note to Barry: the platform ships slower with a fractional team — here is the impact on the datacentre-exit timeline if this is not funded properly at the next annual plan. Not a complaint; a documented trade-off with a named owner.
Total dedicated capacity: about 1.6 FTE to start.
This is the realistic NZ platform team. It is small — and the entire series will show what that forces: automation instead of headcount, incremental scope instead of big bang, and pilot-partner workload teams carrying part of the validation load.
Lesson 3 — Write down the capacity number and its consequences before the exec meeting. A fractional team is a legitimate choice; an undisclosed fractional team is a schedule failure waiting to be discovered by someone else.
Week Two: The Discovery Workshops
Fakey now runs the two weeks’ payoff: three workshops in five days. Here are the agendas — steal them.
Workshop 1: The Workload Teams (half day)
Three product teams, asked five questions:
- What are you building over the next 18 months, and what does it need (latency, data, integrations)?
- How do you deploy today, and what would make that faster in Azure?
- What data do you handle, and how would you classify it?
- What has historically made environment requests painful?
- If you had a compliant environment handed to you in a day, what would you do with it?
The answers reshape assumptions: Netty Latency’s fraud platform needs sub-5ms to a payment service — the first concrete datapoint that the network design cannot be a simple hub. Another team processes identity documents, making their data classification the strictest in the company. All three teams say the same thing about today’s process: “environment requests take a month and we do not know why.”
That last answer becomes the platform’s first success metric: time from environment request to deployable, compliant environment. Target: under five working days.
Workshop 2: Finance and Commercial (one hour, and it matters)
With Penny’s analyst and Tessa Spreadsheet, Fakey maps: how fakey.xyz’s finance system records cost centres and product codes, what report the board wants to see, and how NZ tax treatment of cloud subscriptions sits with their accountants. Output: a provisional tagging model tied to fakey.xyz’s actual finance codes — not a generic standard.
Workshop 3: Security, Risk and Compliance (half day)
With Serge: a mapping exercise from the four drivers to platform-level controls. This produces the draft control inventory — what the platform must enforce, what it must log, what it must enable teams to prove. It also surfaces the decision that the platform will start every policy in audit mode (a decision Fakey will defend hard in Part 2).
The Two Weeks, Summarised: What Fakey Brings to the Exec Meeting
She brings one slide — deliberately one:
The Cloud Platform: Scope, Constraints, and First Deliverables
- Purpose (drivers): RBNZ BS11-related evidence capability (and APRA CPS 234 where group/counterparty scope requires it); client due-diligence enablement; Privacy Act alignment; datacentre exit (Petone, FY26–27)
- Constraints: no new headcount until FY+1 plan; ~1.6 FTE initial capacity; no new budget envelope this FY
- Approach: incremental delivery — first workload team onboarded within 12 weeks; production workload on-platform within 20
- Success metric: environment request → compliant deployable environment in under 5 working days
- First decision needed: approval of the pilot-partnership approach with Netty Latency’s fraud platform team
- Named owners: Platform lead — F. McFakerson; Security controls — S. Secure; Cost attribution — Finance (Penny Pockets’ office)
The exec meeting takes twelve minutes. Barry asks one question — “Why only one workload team at first?” — and Fakey answers with the reason this entire series will keep returning to: because the first team is the platform’s design partner, and a platform designed without its first customer is a guess with infrastructure attached.
The Checklist You Can Steal
Everything Fakey did in two weeks, as a checklist for your own mandate:
- Funding reality documented — what is approved, what is funded, when the next decision happens
- Four-plus business drivers, each with a named stakeholder
- NZ regulatory mapping specific to your workloads (RBNZ BS11-related? APRA CPS 234? NZISM? Privacy Act/HIPC? — name exactly which, and for which systems)
- Capacity number written down, with its schedule consequences
- Finance asked how cloud spend must map to their reporting — before the subscription strategy, not after
- Workload teams interviewed, not briefed — five questions, real answers recorded
- One success metric defined that a business person can understand (ours: 5 working days to a compliant environment)
- A one-page “what is this platform for” document that would survive a change of sponsor
If you can tick seven of eight, you are — genuinely — ahead of most landing zone initiatives in this country.
One Block · build from here
Has your organisation received “the mandate”? What did the first two weeks actually look like — and what do you wish had been written down on day one?