Khalid ShamsPrincipal Solutions Architect

Playbooks · principal-level, Azure-first, platform-agnostic

How I build it. Questions first, then the build, in order.

Six playbooks covering what a principal solutions architect is actually asked to own: agentic AI, application modernization, the data and AI platform, security and governance, cloud foundations and multi-tenant SaaS, and full-stack product engineering. Each one has the same shape: the questions I ask before anything gets built, the Azure tools in the order they go in, why that order matters, what it looked like when it was real, and what I leave behind.

Start with agentic AI The method behind them
01From a demo that works to a system people depend onAgentic AIAgents, grounding, evaluation, and governance: the questions I ask, the Azure build in order, and what it looked like when it was real.Entra IDAzure AI FoundryAzure AI SearchMicrosoft FabricAzure FunctionsRead the playbook → 02Retire, rehost, replatform, or rebuild, decided on evidenceApplication modernizationAssessment, the 6R decision, migration sequencing, and the cutover that is really a change of ownership.Azure MigrateService MapAzure Landing ZonesAKSContainer AppsRead the playbook → 03A lakehouse people trust, because someone owns each layerData & AI platformMicrosoft Fabric, medallion layering, data contracts, semantic models, and the governance that makes AI safe to ground on it.Microsoft FabricOneLakeData FactoryLakehouse & WarehouseSemantic modelsRead the playbook → 04Controls that land before the workloads doSecurity, identity & governanceIdentity as the perimeter, policy as code, and detection you can afford: the questions, the Azure build in order, and what it looked like in a regulated programme.Microsoft Entra IDConditional AccessPIMAzure PolicyManagement groupsRead the playbook → 05A landing zone that can carry a thousand tenantsCloud foundations & multi-tenant SaaSThe platform underneath everything else: landing zones, tenant isolation, tiering, resilience and cost, with the questions, the Azure build in order, and what it looked like at 1,000+ tenant databases.Azure Landing ZonesManagement groupsAzure PolicyBicep / TerraformHub and spokeRead the playbook → 06Architecture advice ages badly when you stop buildingFull-stack product engineeringHow I take a product from a blank repository to something people depend on: data model, API, auth, front end, pipeline, observability and cost, with the questions, the build in order, and three products I ship myself.PythonFastAPITypeScriptReact / Next.jsPostgreSQLRead the playbook →

The questions are the assessment. The build is the plan. If a team cannot answer the questions in writing, the build is a bet.

How to use these

Read the questions first. If your team can answer them in writing, skip to the build.

The questions are the assessment. The build is the plan. The failure section is the review. If you are a leader deciding whether a programme is ready, the questions alone will tell you. If you are an engineer about to deploy, the build order is the part that saves you a quarter. If you are interviewing me, this is the process you would be hiring.

Same shape, every time

Questions, build, why, use cases, failures, deliverables. Once you know the shape you can read any of them in ten minutes and find the part you need.

Azure named, not required

The tools are Azure because that is where most of this was delivered. The order is architecture, not vendor. One of the systems described here runs on AWS and one on Anthropic's platform, and the sequence was identical.

Every playbook ends at the gates

Each one maps its failure modes to the eight gates of the SHAMS Method, so a finding in any playbook has a sign-off it has to pass.