Name the six interrogative columns of the Zachman Framework and, for a single row (say, the Logical/Architect perspective), give a concrete example artifact for each. Why does Zachman insist each cell hold a 'primitive,' single-variable model rather than a composite diagram mixing several columns together?

## The six columns The six columns of the Zachman Framework are **What, How, Where, Who, When, and Why** - respectively data, function, network/location, people/organization, time/events, and motivation/rules. To make these concrete rather than abstract, it helps to fix a single row and walk across all six columns within it, because that's exactly the exercise that reveals what each column is actually asking for. Take the Architect row - the Logical/System Logic perspective, one level below the business-facing Conceptual row and one level above the technology-bound Physical row. ## One row, six artifacts - **What** - at this row the artifact is a logical data model: entities with defined attributes and relationships, normalized according to standard data-modeling discipline, but still independent of any specific database product - an `Order` entity with `OrderDate` and `Status` attributes and a defined one-to-many relationship to Line Items, expressible equally well in a relational or document-oriented implementation. - **How** - a logical process or data-flow model, something like a business-process model (comparable to a BPMN diagram) that shows the sequence of activities transforming inputs to outputs, again without specifying which system or technology executes each step. - **Where** - a logical distribution model: which logical business locations or nodes need to perform which functions, and how they connect - e.g., 'Order Entry happens at any Regional Office and must synchronize with Central Inventory' - without naming actual data centers or network protocols. - **Who** - a logical work-flow or role model: which roles (Sales Representative, Warehouse Clerk, Approving Manager) perform which steps in the How column's process, and what handoffs occur between them - abstracted from any specific org chart or system's user-role table. - **When** - a logical event or dependency model, often a state-transition diagram, showing the business events that trigger process steps and their sequencing constraints - e.g., 'an Order cannot move to Shipped until Payment Confirmed has occurred' - without reference to actual scheduled jobs or cron triggers. - **Why** - a logical business rule model, tying specific rules (a discount rule, a credit-limit check) to the process steps or data constraints they govern, expressed as business logic rather than as code. ## Primitive versus composite The deeper and more interview-relevant point is Zachman's insistence that each of these six cells hold a **primitive** model - one that varies along exactly one of the six independent variables - rather than a **composite** artifact that blends several together. For example: - a typical UML sequence diagram, for example, often mixes process (How), timing (When), and sometimes roles (Who) into a single picture; - a typical entity-relationship diagram with swim lanes might mix What and Who. ## Why a composite is architecturally fragile Zachman's argument is that this kind of composite artifact, while sometimes convenient for a presentation, is architecturally fragile, because it encodes multiple independent variables in one representation: 1. you cannot change one variable (say, reorganize which role performs a step) without redrawing or re-deriving the whole composite; 2. and you cannot easily audit whether a given variable (say, Who) has actually been modeled at all if it only ever appears embedded inside other diagrams. A composite artifact can hide the fact that an organization has never actually produced a standalone, reviewable model of its roles-to-process mapping - it exists only implicitly, scattered across a dozen sequence diagrams, none of which is authoritative and none of which the actual role owners were asked to validate directly. ## Notations are composite views, not cells This primitive-versus-composite distinction is also why Zachman explicitly rejects the idea that popular modeling notations map cleanly onto the framework: a single UML or ArchiMate diagram is frequently a composite view assembled from several primitive cells, useful for communication, but not itself the authoritative single-variable model the framework wants filed in each cell. In well-run practice, the primitive models are maintained as the source of truth, and composite diagrams (which stakeholders often find more intuitive to read) are treated as derived, generated views for communication purposes - not vice versa. Teams that only ever produce composite diagrams and never separately maintain the underlying primitives typically discover the problem only when they try to change one variable in isolation and realize there's no independent representation to change; they have to reverse-engineer intent out of a diagram that was never designed to be decomposed.