About
Twenty years learning how software fails. Nine applying it where failure is public.
I'm Wes Sanford, an enterprise solution architect. I spent two decades in Microsoft's Developer Division, in test, release, and engineering productivity on Visual C++, Internet Explorer, Visual Studio Team Foundation, and SharePoint Online. That is where I learned what shipping software actually looks like: not the design, but the thousand ways a design meets a real system and loses.
Since 2017 I have put that to work on public-sector and healthcare programs: a statewide Architecture Review Board in New Mexico, federal Medicaid reporting for six states, solution quality through CMS certification, a Medicaid managed-care organization's first data platform outside its core warehouse, and most recently a district-wide data warehouse on Azure for a Florida school district. Today I do that work as an Enterprise Solution Architect with IBM Consulting.
The programs differ. The job is the same: design the data platform and the governance around it, make sure it will pass the audit it is going to face, and lead the people who build it.
How I work
Five habits that hold on every program
- 01
Write the decision down.
An architecture that lives in slides is a rumor. I record the decision, the options that lost, and why, so the next person can disagree with evidence instead of folklore.
- 02
Size to the budget that exists.
The best platform is the one the client can run after I leave. I would rather ship data-quality dashboards inside this year's budget than design a seven-figure licensing path nobody will approve.
- 03
Security comes from the client's directory.
Role-based access should flow from the groups the client already manages. A bespoke security model is a second system to keep in sync, and it is the one that drifts.
- 04
Translate in both directions.
A CIO needs the ten pages, not the sixty. Engineers need the real constraint, not the sanitized one. Most of my job is making sure both sides are reading the same document.
- 05
Evidence beats assurance.
Twenty years in test and release taught me that a requirement nobody can verify is a wish. Every non-functional requirement gets a definition of done and a way to prove it.
Where I am
Palm Springs area, California
I work remotely across the US on Pacific time and travel to client sites when the work calls for it. Recent programs have been in Florida, North Carolina, and New Mexico, with teams spread across every US time zone.
The right fit
What I take on, and what I don't
I'm the right person for programs where compliance, scale, and audit readiness are the hard part: state and federal data platforms, Medicaid and health and human services modernization, K-12 district analytics, and the governance that goes with them. Architecture reviews, platform design, and delivery leadership are the three things I do end to end.
I'm not the right person for consumer product work, pure staff augmentation, or a design handed over without the chance to see it through delivery.
Résumé
The full résumé, with a PDF
Every role since 1992, with the engagement detail that LinkedIn leaves out.
Working notes
wessanford.dev
Engineering notes from real problems, written for the people who build these platforms.