I'm Suh Fangmbeng, a Principal Solutions Architect in Dallas
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.
How I help engineering teams
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.
Cloud architecture
Reference architectures, landing zones, and migration roadmaps for AWS and Azure that survive audit and scale.
Legacy modernization
Breaking monoliths into services your teams can own, with a sequencing plan that keeps the business running.
Platform engineering
Internal developer platforms, CI/CD pipelines, and IaC standards that make the safe path the fast path.
Data & integration
Event-driven pipelines, API strategy, and data models that keep systems in sync without nightly batch jobs.
AI & LLM systems
Agent architectures, retrieval pipelines, and eval harnesses designed by a Claude Certified Architect — not a demo that breaks in production.
Security & resilience
Zero-trust patterns, IAM design, and DR planning reviewed against real failure modes, not a checklist.
Something else?
Architecture reviews, team enablement, vendor evaluations — if it touches the platform, start a conversation.
Get in touch
Who's behind all this great work?
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.
Cloud and platform architecture
From hands-on engineering to leading architecture for regulated, high-traffic workloads on AWS and Azure.
Migrations and platform builds
Data center exits, monolith decompositions, and internal platforms that cut deploy times from weeks to minutes.
Claude Certified Architect, Professional
Credentialed to design production LLM systems — agent orchestration, tool use, retrieval, evals, and the cost and safety guardrails that keep them shippable. Verify on Credly
Mentor first, architect second
The best design is the one the team can own after I leave the room, so I document, teach, and hand it over.
The two problems I get
called in to solve
Most of my work is a variation on one of these. Details change with the domain; the shape rarely does.
The system nobody wants to touch
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.
Ten teams, ten different answers
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.
Three signals it is an architecture problem, not a sprint problem
Releases have become events
When shipping needs a bridge call and a rollback plan, the architecture is telling you something.
Two services own the same truth
Duplicated state is the tax you keep paying for a boundary drawn in the wrong place.
The bill grew faster than traffic
Spend curves that outpace usage are usually a design problem wearing a finance costume.
How an engagement actually runs
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.
Full history on LinkedInCertifications
Claude Certified Architect — Professional
Anthropic · Verify on Credly
Map what actually runs
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.
Design for the constraint
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.
De-risk with a thin slice
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.
Hand off the keys
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.
What you can hold
me to
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.
What I will argue about over coffee
The positions I keep coming back to in reviews, talks, and long Slack threads.
An undocumented decision is a decision the next team gets to make again
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.
Stop splitting the monolith along the org chart
Data ownership should decide your first seam. Team boundaries move every reorg; the schema does not.
The cloud bill is an architecture review in disguise
Egress charges and idle capacity are not procurement problems. They are design decisions with an invoice attached.