Excerpted with permission from Building Business Solutions:  Business Analysis with Business Rules (2^nd Ed.), by Ronald G. Ross with Gladys S.W. Lam, Business Rule Solutions, LLC, 2015, 308 pp.  URL:.  http://www.brsolutions.com/bbs

The Zachman Architecture Framework is the classification scheme, or ontology, created by John Zachman for engineering things of complexity.

Zachman's basic premise is that whenever you engineer anything of complexity, no matter what — a complex machine, a skyscraper, a microchip, a spacecraft, a product, a business (an enterprise), or some part of a business (a business capability) — there are two basic aspects that need to be addressed.  These two aspects correspond to the columns and rows of the Framework.

• The columns represent the primitives of engineering problems and correspond to the six interrogatives (business engineering questions) what, how, where, when, who, when, and why.  (The order doesn't matter.)  If an artifact is not primitive, then it's a composite and inevitably more complex and resistant to change.
  
  
• The rows represent reifications in the sense of MWUD^[1] [reify]:  convert mentally into something concrete or objective : give definite content and form to : MATERIALIZE.  In engineering, an object is created for a particular audience with a certain perspective, set of needs, and agenda.  The Framework recognizes six such reifications or audiences.  (Their order does matter.)

Six primitives times six reifications (audiences) equals 36 cells in the Framework.  You can think of those 36 cells as covering the universe of discourse for engineering things of complexity, a fundamental scheme for understanding and assessing completeness.  Graphic depictions of the Framework naturally focus on the primitives for these cells.

Common Myths about the Framework

• Myth #1.  The Framework requires you to create an artifact for each and every cell.  Wrong.  It's not a methodology, it's a classification scheme.  Different methodologies emphasize problems of different kinds, so in practice some cells are likely to play a less prominent role than others.
  
  
• Myth #2.  The Framework can be applied only at the enterprise level.  Wrong.  It can be applied for an engineering problem of any size (scope) deemed meaningful.
  
  
• Myth #3.  The Framework discourages or precludes prototyping.  Wrong.  Again, the Framework isn't a methodology.  Much can be learned about the best solution for any given audience by prototyping alternative approaches.
  
  
• Myth #4.  The rows (i.e., reifications or audiences) in the Framework are about increasing level of detail.  Wrong.  Each successive row represents a transform of the previous reification into a new reification.  The new reification serves a new purpose for a distinct audience.

Any artifact in any row can be pursued to excruciating levels of detail (as Zachman puts it) if deemed useful and productive.  The fundamental idea is to make the next audience's job in creating the next reification that much easier.

• Myth #5.  The Framework doesn't recognize there are connections between the primitives.  Wrong.  A key question, in fact, is how the primitives are 'tied together' (configured) at any point in time to create a complete and workable solution. 

Tying together (configuring) primitives is the purpose of integration relationships.  The effectiveness of their configuration determines the degree of business agility you achieve.

Two basic choices to support integration relationships are:  procedural (processes) and declarative (business rules).  Traditional processes with their hidden semantics are a poor choice (think business rules being hard-coded into software).  Business rules, in contrast, support direct, business-friendly configuration, as well as rapid, traceable, continuous re-configuration.

• Myth #6.  The Framework somehow induces complexity.  Wrong.  Engineering problems are inherently complex, with business engineering being perhaps the most complex of all (as Zachman contends.)  In other words the complexity already exists, the trick is to engage with it most effectively.
  
  
• Myth #7.  The Framework slows you down.  Wrong.  That's not our experience at all.  Asking the right questions of the right audiences at the right times in the right ways doesn't slow you down, it speeds you up (or avoids costly dead ends).

Remember, the cost and time needed for rework does not rise linearly for each subsequent reification, it balloons.  Overall acceleration is what you want, and not just for the build activity.  You also want it for the inevitable, myriad changes to business rules you can expect after the business rules are deployed.

Such solutions don't happen by accident — they require deliberate engineering.  Zachman simply points out, like it or not, what such 'deliberate engineering' necessarily involves.

For further information, please visit BRSolutions.com      

References

[1]  Merriam-Webster Unabridged Dictionary  

# # #