How would you choose between a Kimball-first and an Inmon-first build for a new analytics platform?

## Reframe the question The interviewer is not looking for a favourite. Announcing one signals that you would apply a template to a situation you have not measured. The defensible framing is that both schools answer the same underlying question — **how much integration happens before anything is published** — and that the answer is a dial set from evidence about the organization in front of you. ## The inputs that actually decide it **How much do the sources disagree?** This is the dominant input. If four systems describe the same customers with different identifiers, different lifecycle states and overlapping history, then reconciliation *is* the project, and doing it once upstream is cheaper than doing it in every mart. If each subject area has one authoritative source, an integration layer is largely moving data between two models for no adjudication benefit, and a thin cleaning step feeding stars is the honest design. **How many consumers, and for how long?** A model that three teams will build on for five years justifies investment that a single analyst's question does not. Count the intended consumers, not the ones who ask loudest. **What is the delivery pressure and the state of sponsorship?** A new platform with fragile sponsorship must produce a credible answer to a real business question early or it loses its budget and the departments start building private extracts anyway. That is not a reason to skip integration; it is a reason to sequence a publishable slice first. **Is there governance authority?** An integrate-first build requires someone empowered to rule on what a customer is when two departments disagree. Without that, the enterprise model does not get built slowly — it gets built never, because the disagreements have nowhere to resolve. Assess this honestly before promising the approach that depends on it. **How volatile are the sources and the requirements?** Frequently changing sources reward a layer designed to absorb change. Frequently changing reporting requirements reward keeping the volatile part in a thin, cheap-to-rebuild publication layer. **What can the team actually operate?** An architecture nobody on the team can maintain in eighteen months is a bad architecture regardless of its merits on a diagram. ## The plan I would actually propose A thin vertical slice, then thicken: 1. **Land raw and retain it.** This is unconditional. It makes every later modelling mistake a reprocessing job rather than a data-loss incident, and it is what makes early publication safe. 2. **Plan the shared dimensions across the roadmap before building the first mart** — which entities are shared, their grain, their keys, their owners. Build only the ones the first mart needs. Planning is cheap; retrofitting a shared entity across published fact tables is not. 3. **Publish one business process end to end**, with the grain declared and the numbers reconciled to a source the business already trusts. Credibility comes from matching a number someone can check. 4. **Widen the integration layer as each subsequent process arrives**, doing the reconciliation the new process actually forces rather than the reconciliation a reference architecture predicts. 5. **Enforce the dependency.** Marts read the integration layer; a mart that reads a source directly is a defect, not a shortcut, or the divergence returns. ## What I would tell a sponsor Two failure modes, stated plainly. Publish-first without shared-dimension planning produces fast dashboards that disagree by the fourth one, and the reconciliation cost lands on models people already depend on. Integrate-first without a delivery slice produces months of invisible modelling, lost sponsorship, and departments routing around the platform. The plan above is designed to avoid both, and its main risk — a middle layer that becomes ceremony — is checked by a standing question: does this layer reconcile anything? ## Signals I would revisit the decision on - The same business rule appears in two marts: the integration layer is too thin. - The integration layer only renames source tables: it is too thick for the conflict present. - Definition disputes escalate with no one able to decide: the governance gap is the blocker, not the modelling. - Marts routinely bypass the layer to hit a deadline: the delivery cadence, not the architecture, needs fixing. ## Answering in an interview Refuse the false binary explicitly but briefly, name the inputs you would measure, give a concrete sequencing plan, and state the two failure modes it is designed to avoid. Naming what would make you change your mind is the part that separates a principal answer from a confident one.