Walk through how the same 'What' (data) interrogative would be represented differently as you move down the Zachman Framework's rows, from the Executive/Scope perspective to the Technician/As-Built perspective.

## The rule to hold onto One of the most concrete ways to internalize what the Zachman Framework's rows actually mean is to trace a single column - most people pick 'What' (data) because it maps naturally to something engineers already know: the journey from a business idea to a running database. The key insight to hold onto throughout this walkthrough is that each row is **not** simply the row above with more detail sprinkled in; each row is produced by a different role, for a different audience, and can introduce genuine new constraints and decisions that did not exist, and could not have existed, at the row above. | Row | Its version of 'What' | |---|---| | **Executive/Scope** (Contextual) | a short list of the things important to the business | | **Business Management** (Conceptual) | a semantic model in the business's own vocabulary | | **Architect** (Logical) | a logical data model, typically normalized, still technology-independent | | **Engineer** (Physical) | a physical table with specific column types and indexes | | **Technician/As-Built** | the literal deployed reality, including drift | ## The business-facing rows Start at the top, the Executive/Scope row, sometimes called the Contextual perspective. Here, 'What' is nothing more than a short list of the things important enough to the business to be named at all - Customer, Product, Order, Invoice, Employee. There's no structure, no relationships, no attributes; it's the equivalent of an executive saying 'these are the nouns our business cares about.' This list exists to bound the scope of an initiative: if 'Supplier' isn't on the list, the initiative isn't concerned with supplier data at all. Move down to the Business Management row, the Conceptual perspective. Now a business analyst or business architect - someone fluent in the domain but not necessarily in IT - turns that flat list into a **semantic model**: Customer places an Order; an Order contains one or more Line Items; each Line Item references a Product. This model uses the business's own vocabulary and is validated by asking business stakeholders 'is this how you think about it,' not by asking whether it will run efficiently on a particular database. Crucially, this model is still entirely technology-independent; it would look the same whether the eventual system runs on a relational database, a document store, or paper forms. ## The design rows Next is the Architect row, the Logical perspective. Here a data architect translates the conceptual model into a **logical data model**, in which: - entities gain precise attributes (`Order` gets `OrderDate`, `Status`, `TotalAmount`); - relationships get cardinality (one Customer to many Orders); - and the model typically gets normalized following standard database design discipline. This model is detailed enough to design against, but still deliberately avoids committing to a specific database product - it could be implemented in PostgreSQL, Oracle, or even reshaped into a NoSQL structure without changing the logical model itself. Then the Engineer row, the Physical perspective. This is where a genuinely new kind of decision enters that didn't exist at any row above: which actual DBMS, and what physical structures. The logical `Order` entity becomes a physical 'orders' table with: - specific column types (a decimal type for `TotalAmount`, a bounded string for `Status`); - specific indexes chosen for expected query patterns; - specific foreign key constraints; - maybe a partitioning strategy. This is technology-bound in a way the row above deliberately was not, and two different engineers implementing the same logical model on the same DBMS could still make different, equally valid physical choices. ## The As-Built row, where drift lives Finally, the Technician/As-Built row - the literal, physical, deployed reality: the actual DDL that ran, the actual indexes that exist right now, including whatever emergency hotfix a DBA applied at 2am that never made it back into the logical or physical design documents. This row is notorious in real organizations for silently diverging from the rows above it, because production systems accrue patches faster than documentation gets updated - exactly the kind of drift the framework makes visible once you go looking, because there is an expected cell for 'what the database physically, actually looks like right now' and it's easy to check whether it matches the physical design. ## What skipping a row costs The reason this matters in practice, beyond being an academic exercise, is that skipping a row produces real gaps that bite later. - A team that jumps straight from a Conceptual business model to writing physical DDL, skipping the Logical row's deliberate technology-independence, often ends up baking premature technology assumptions into what should have been a portable design - for instance, denormalizing for a specific database's performance characteristics before anyone confirmed that database was even the right choice. - Conversely, a team that never produces the As-Built row's honest documentation of current production reality loses the ability to detect drift, and eventually nobody in the organization can say with confidence what the schema actually is versus what it was designed to be.