Celebrating the 10^th Anniversary of the Business Rules Manifesto^[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #8 Question: Why aren’t rules found in any of the cells of the latest Zachman Framework? The Manifesto says clearly (principle 1.1) that rules should be considered a first-class citizen of the requirements world. Yet rules cannot be found in any of the cells of the latest Zachman Framework. Contradiction? No. For an artifact to appear in a cell of the Framework it must represent a primitive. An artifact that references multiple primitives is considered a composite.  Rules are intrinsically composite. Even atomic rules can address multiple primitives. (Atomic means “can’t be reduced into two or more rules without losing meaning.”) An example: An accounting must be given by the CFO in Delaware on March 15, 2015. This rule refers to a thing (‘accounting’), a person (the CFO), a place (Delaware), and a date (March 15, 2012). Simply because an artifact is composite, however, doesn’t necessarily make it unimportant. Consider what Zachman calls integration relationships – the connections tying the six primitives together. Integration relationships serve to configure the enterprise at any given point in time. No integration relationships, no enterprise. To illustrate, Zachman frequently rolls the Framework into a cylinder and looks through it like a telescope. The primitives must be tied together through that empty cylinder by integration relationships. What can serve in that role? Traditionally, integration relationships have been implemented by procedural means – hardcoded into application programs. Unfortunately, that’s like setting the business in concrete. It also plays havoc with process as the simple, straightforward primitive it should really be. A much better alternative is rules. Rules, by comparison, are far easier to change. So consider rules as the first-class candidate to achieve configuration agility for the enterprise  

There is much confusion in the Enterprise Architecture space over some of the most fundamental words in the English language: what, how, where, who, when, why. I’m afraid to say there’s some very loopy thinking out there. Zachman anticipated all this and brilliantly provided six generic models for the 6 question words. Here they are roughly as follows (and possibly needing to be adjusted slightly in his new 3.0): What:  thing-relationship-thing How:  input-process-output Where:  site-link-site Who:  role-workproduct-role When:  event-cycle-event (moment-state-moment) Why:  ends-means-ends For me, it’s hard to argue that these are not what each question is about from an architectural point of view. The only thing missing is how you relate instances of the 12 elements to comprehensively configure an enterprise at any given point in time. (Zachman calls these “integration relationships”. They’ve always been there, but only on the schematic in 3.0.) IMO, the best, most dynamic (agile) way to support the ‘integration relationships’ is business rules. What could possibly be better?