ArchitecturePlatformAI
I design cloud platforms that hold up under real traffic and real deadlines — turning tangled legacy systems into architecture that engineering teams actually enjoy shipping on.
Daily toolkit
01Services
Whether you are exiting a data center, untangling a monolith, or trying to make deploys boring again — this is the work I get called in for.
Reference architectures, landing zones, and migration roadmaps for AWS and Google Cloud that survive audit and scale.
Breaking monoliths into services your teams can own, with a sequencing plan that keeps the business running.
Internal developer platforms, CI/CD pipelines, and IaC standards that make the safe path the fast path.
Event-driven pipelines, API strategy, and data models that keep systems in sync without nightly batch jobs.
Agent architectures, retrieval pipelines, and eval harnesses designed by a Claude Certified Architect — not a demo that breaks in production.
Zero-trust patterns, IAM design, and DR planning reviewed against real failure modes, not a checklist.
Something else?
Architecture reviews, team enablement, vendor evaluations — scoped to what you actually need.
02About
I'm Suh — a Cameroonian-born architect based in Dallas. I spend my days in whiteboard sessions with engineering leaders, translating messy business constraints into systems that scale, stay secure, and don't page anyone at 3am.
From hands-on engineering to leading architecture for regulated, high-traffic workloads on AWS and Google Cloud.
Data center exits, monolith decompositions, and internal platforms that cut deploy times from weeks to minutes.
AWS Certified Solutions Architect – Professional and Google Cloud Professional Cloud Architect, so a multi-cloud or migration decision gets weighed on both sides rather than defended from one. Plus Claude Certified Architect — Professional for production LLM systems: agent orchestration, retrieval, evals, and the guardrails that keep them shippable. Verify the Claude credential
The best design is the one the team can own after I leave the room, so I document, teach, and hand it over.
03Approach
Most of my work is a variation on one of these. Details change with the domain; the shape rarely does.
Where I usually get called
Every change ships with a held breath. The people who designed it have moved on, the test suite is decorative, and the business has stopped asking for features it assumes are impossible. I map what actually runs, find the seam that carries the least risk, and get one slice moved end to end so the team can see the pattern before committing to the rest.
The other half of the work
Everyone is solving deploys, secrets, and observability on their own, slightly differently, and the drift compounds. The fix is rarely a new tool — it is deciding which choices stop being choices. I define the paved path, make the right thing the easy thing, and leave a platform whose owners can change it without me.
04Method
Four phases, in order, every time. The deliverable is never a slide deck — it is a system your team can operate and a set of decisions they can defend.
Not the diagram on the wiki — the real call paths, the cron job on someone's laptop, the table two services both write to. Nothing gets designed until the current state is honest.
Compliance, team size, and the migration budget shape the answer more than any reference architecture does. I write the decision down, including what we deliberately chose not to do.
One real workload moved end to end, in production, before the big commitment. It either proves the pattern or exposes what the whiteboard missed — both are cheaper to learn now.
Runbooks, decision records, and a team that can change the design without calling me. An architecture only one person understands is a liability, not an asset.
AWS Certified Solutions Architect – Professional
Amazon Web Services
Google Cloud Professional Cloud Architect
Google Cloud
Claude Certified Architect — Professional
Anthropic · Verify on Credly
05Commitments
The measure of a good architect is what the team can do six months after the engagement ends.
I will tell you when the boring option is the right one. I will write down why we chose it, including the trade-off we accepted, so the next person does not have to guess. And I will not leave you with a design that only works while I am still in the room.
06Writing
The positions I keep coming back to in reviews, talks, and long Slack threads.
Decision records are not paperwork. They are the difference between a system with a rationale and a system with archaeology — and they take fifteen minutes.
Data ownership should decide your first seam. Team boundaries move every reorg; the schema does not.
Egress charges and idle capacity are not procurement problems. They are design decisions with an invoice attached.