The Enterprise Architect's Interview Framework: From Business Problem to a Design You Can Defend

A city planner, not a builder

A builder is asked to put up one house on an empty plot. A city planner is asked to add a new district to a city that already has roads, water pipes, a power grid, a council with rules and a budget, and residents who cannot be moved out while the work is done.

A consumer system-design interview ("design YouTube") is the builder's question. An Enterprise Solutions Architect interview is the planner's question. The roads are the integration layer, the pipes are data flows, the council is compliance and finance, and the residents are the systems and teams already running. This guide is the framework for answering the planner's question. Where the analogy stops: a city is planned for decades, while an enterprise roadmap is usually re-planned every year, so your design must be easy to change, not just correct.

In 30 seconds, as an architect would frame any enterprise question: "Before I draw anything, I want to understand the business outcome, who the stakeholders are, and what already exists. Then I will turn that into measurable requirements, compare two or three options including buying instead of building, recommend one, and show the target architecture, its security and recovery model, and how we get there in stages without stopping the business. I will be explicit about what each choice costs and what would make me change it."

The rest of this guide expands that paragraph. Every case study on this site, starting with the payment system, follows the same shape.

1. How the enterprise round differs

The consumer building blocks still matter: caching, queues, replication and consistency appear inside every enterprise design. But an answer made only of building blocks, with no stakeholders, current state, cost or migration, reads as an engineer's answer, not an architect's.

2. The landscape you are designing into

Consumer system-design questions start from an empty page. Enterprise questions almost never do. Your design lands in a landscape that already has an ERP, a CRM, a legacy system nobody wants to touch, an integration layer, a data platform and shared security services. Draw this picture, or the client's version of it, before you draw your own components.