What is an enterprise bus matrix, and how does a team use it to plan a warehouse?

## What the artefact is The enterprise bus matrix is deliberately low-tech: a single grid, usually one page, that an architect and business stakeholders can fill in together in a workshop. - **Rows = business processes.** Not departments, not reports, not source systems - the measurable events the business performs. Order taking, shipping, returns processing, inventory snapshotting, purchase ordering, claims handling. Each row is a candidate fact table. - **Columns = dimensions.** The descriptive entities that give those events context: date, product, customer, store, employee, promotion, supplier, ship-from location. - **Cells = a tick** where that process is meaningfully described by that dimension. ```text Date Product Customer Store Employee Promotion Retail Sales X X X X X Returns X X X X Inventory Snapshot X X X Purchase Orders X X X Shipments X X X X ``` The name comes from the analogy with a computer's backplane bus: the conformed dimensions are the shared bus, and each fact table is a card that plugs into it. ## Reading it down the columns A column tells you how widely a dimension is shared. Date is ticked in every row; product in nearly every row; employee in two. That ranking is the conformance work plan. The dimensions with the most ticks are the ones where drift hurts most and where investment in a single owned, properly modelled dimension pays back across the whole estate. A column with one tick is a private dimension for one process and needs no cross-team negotiation at all. This is a genuinely useful prioritisation, because conforming a dimension is expensive - it means agreeing a durable business key, a master attribute set and a classification rule across teams that currently disagree. Doing that for date and product first, and deferring it for a dimension only one process uses, is how the work stays tractable. ## Reading it across the rows A row is a one-line design sketch for a star: this fact table, surrounded by these dimensions. It does not yet declare the grain or the measures - that is the next step of design - but it fixes the dimensional footprint and makes the fact table's scope explicit. Rows are also the delivery increments. You implement one business process at a time and ship it, rather than attempting an enterprise-wide model before anything reaches a user. Each new row reuses the conformed columns already built, so the second star costs less than the first and integrates by construction. That incremental, process-at-a-time delivery held together by shared dimensions is the core of Kimball's approach. ## What it prevents Without the matrix, marts get commissioned one at a time by whoever asks loudest, each team invents its own customer dimension, and integration becomes a retrofit project years later. The matrix surfaces the collision early and cheaply - on a whiteboard, before any table exists - by making it visually obvious that four processes all need a customer dimension and therefore need to agree on what a customer is. It is also a communication artefact. Business stakeholders who cannot read a star schema can read this grid, spot a missing process, and argue about whether their notion of a customer really is the same as the other department's. That argument is the valuable output; having it in a workshop is far cheaper than having it in production. ## What it is not The matrix does not declare grain, does not list measures, does not specify attributes and does not say anything about physical implementation. It is a map, not a design. It also is not a status board of what has been built, although teams often shade the cells to track progress - a common and harmless extension. A frequent mistake is to fill the rows with departments (Finance, Marketing) or with report names (Weekly Sales Dashboard) instead of business processes. Departments produce mart-per-team silos, which is the outcome the matrix exists to prevent; report names produce fact tables that are obsolete the moment the report changes. The discipline is that a row must be something the business *does*, repeatedly, that leaves a measurable record. ## Keeping it alive The matrix is worth revisiting as the business changes: a new process is a new row, a newly shared entity may turn a private dimension into a conformed one. Teams that keep it current use it in planning conversations - "which row are we building next, and does it need a column we have not conformed yet" - which is a far more useful question than a backlog of report requests.