The “Mass Execution” Artifact
What it is:
At a certain scale of infrastructure deployment, narrative documents fail. The Build Matrix is the tabular extension of the Low-Level Design (LLD). It abandons paragraphs and diagrams entirely in favour of pure, row-by-row configuration data. It bridges the gap between human-readable design and machine-readable execution, often serving as the direct input variables for infrastructure-as-code or automation scripts.
What goes inside:
- Massive Configuration Tables: Huge VLAN mapping tables, switch-port allocations, and SAN LUN mappings.
- Server Build Matrices: Tabular breakdowns of exact deployment specs (e.g., Hostname, IP Address, MAC, Datastore, CPU, RAM, OS version).
- Firewall Rule Matrices: Strict, column-based access control lists detailing Source, Destination, Port, Protocol, and Action.
- Variables for Automation: Structured data designed to be ingested by deployment tools like Ansible, Terraform, or PowerShell scripts.
What NOT to put inside:
- Narrative Justifications: Explanations of why the configuration is the way it is belong in the SAD or LLD. A spreadsheet is not the place for storytelling.
- Embedded Diagrams: Do not paste Visio diagrams or network maps into Excel tabs. Keep the visual architecture separate from the tabular data.
- Passwords or Secrets: Crucial Rule: Even at the execution layer, local admin passwords, API keys, and secure credentials should never be documented in a matrix. They belong in a secure, vaulted secrets manager.
The Audience:
This artifact is consumed strictly at the execution edge. It is read by Build Engineers, Change Advisory Boards (CAB) reviewing exact implementation steps, and critically, the Automation Scripts and CI/CD pipelines that will actually provision the environment.
When to use it:
- Highly recommended for deploying infrastructure at scale: If you are building 50 servers, writing 100 firewall rules, or configuring a 48-port switch stack, a spreadsheet is vastly superior to 50 pages of Word document tables.
- Essential for automation: When your build team uses automated tooling, they need structured data arrays, not PDF paragraphs.
- Ideal for bulk Change Requests: CABs prefer to review hundreds of firewall rule changes in a clean, filterable matrix rather than scrolling through a massive Word document.
When NOT to use it:
- As a standalone design: A spreadsheet tells an engineer what is configured, but it is terrible at explaining how the pieces relate to one another or why the system was built. Handing an engineer a spreadsheet without the context of a SAD or LLD is a recipe for disaster.
- For single-component deployments: If you are deploying a single, isolated virtual machine with one IP address, creating a dedicated build matrix is overkill. Just put the table in the LLD.
