Architecture and cloud
Senior-led architecture work, without the firm around it
Target-state architecture, cloud strategy and migration assessment, modernisation and cost work — delivered by the person who does the thinking, on engagements sized so that stays true.
Enterprise and solution architecture
Deciding what the systems should look like in two years, and what has to change first. Most organisations do not lack a target state; they lack an agreed one, and a defensible order of work to reach it.
- Engagement
- Fixed-scope assessment, or a retained architect one to two days a week.
- Typical timeline
- Assessments run four to eight weeks. Retained work is reviewed quarterly.
What you receive
- Current-state assessment: what exists, what it costs, what it is holding up
- Target-state architecture with domain-driven decomposition and named boundaries
- Integration and API strategy, including the contracts between teams
- Architecture decision records — the reasoning, kept, so it can be revisited rather than re-argued
- Build-versus-buy analysis and structured vendor evaluation where a purchase is in question
- A governance model proportionate to the organisation, not a review board for its own sake
Cloud strategy and migration
Moving is the easy part. The expensive mistakes are made in what gets moved, in what order, and in what is quietly rehosted unchanged and then costs three times as much to run.
- Engagement
- Assessment first, always. Delivery oversight afterwards if it is wanted.
- Typical timeline
- Assessment six to ten weeks depending on estate size. Migration waves run to their own plan.
What you receive
- Landing zone design — accounts, networks, identity, guardrails and cost boundaries
- 6R assessment across the estate: rehost, replatform, refactor, repurchase, retire, retain
- Workload rationalisation, with the retire list argued rather than avoided
- Migration sequencing with dependencies, risk and rollback stated per wave
- Multi-cloud and hybrid positions, where they are genuinely warranted and not where they are not
- Exit and portability planning — what it would take to leave, costed, before you commit
Modernisation and FinOps
The second year in cloud is when the bill stops being interesting and starts being a problem. Usually the answer is not a discount negotiation; it is that nobody can say what any of it costs per unit of work.
- Engagement
- Focused review, or ongoing advisory alongside your platform team.
- Typical timeline
- Reviews run two to four weeks. Optimisation work is measured monthly against a baseline.
What you receive
- Containerisation and Kubernetes assessment — including when the answer is that you do not need it
- Infrastructure as code and platform engineering practice, with a real path off click-ops
- Observability that answers questions rather than producing dashboards
- Cost optimisation and unit economics: cost per customer, per transaction, per tenant
- Well-Architected reviews across the framework’s pillars, with findings ranked by what they are worth
How engagements run
You get the architect, not an account manager
There is no junior bench, which is a genuine constraint on how much work can be taken at once. It is stated here rather than discovered in week three. Engagements are scoped to what one senior practitioner can do properly, and where more hands are needed we will say so and help you find them.
Before you ask
How this works in practice
It starts with reading and interviews rather than workshops — existing documentation, the estate, the bill, and conversations with the people who operate the systems. Findings are drafted and tested with your team before they are presented, so nothing lands as a surprise. You receive a written current-state assessment, a target-state architecture, decision records for the significant choices, and a sequenced plan with each item costed and risk-rated. The document is written to be read by your executive and used by your engineers; if it needs a translator it has failed.
Assessment is six to ten weeks; migration itself depends entirely on what the assessment finds. The two failures that recur are the same every time. First, lift-and-shift of workloads that should have been retired, which converts a one-off decommissioning conversation into a permanent operating cost. Second, a landing zone designed after the first workloads have already moved, which means identity, network boundaries and cost allocation get retrofitted around whatever happened to land first. Both are avoided by sequencing, not by working harder later.
By classifying the data before choosing a region, not after. For most Australian workloads the answer is ap-southeast-2 (Sydney), australia-southeast1, or Azure Australia East, with the residency constraint written into the agreement rather than assumed from the region name — managed services, support access paths and backup replication all need checking individually. Where a workload is genuinely subject to a specific obligation, that obligation is named in the design and the controls are mapped to it. To be explicit: this practice holds no IRAP assessment and no government security certification. If your requirement needs one, you need a different provider for that part, and we will say so early.
That is the usual arrangement. The most useful role is generally the one nobody in-house can occupy — the person who can say no to a design without it being read as a turf question, and who is not carrying delivery pressure on the same sprint. It works when the decision rights are explicit from the start: what the architect decides, what the team decides, and what goes to your executive. That gets written down in week one.
Start with an assessment, not a proposal
Tell us what the estate looks like and what is prompting the question. If an assessment is not the right first step, we will say what is.