Subscribe to the FREE Business Rules Journal Newletter


 

 

 

     LAM ARCHIVES ...
untitled

Seven Common Myths About the Zachman Architecture Framework

by Ronald G. Ross with Gladys S.W. Lam

Excerpted with permission from Building Business Solutions:  Business Analysis with Business Rules (2nd 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  return to article



standard citation for this article:
Ronald G. Ross with Gladys S.W. Lam, "Seven Common Myths About the Zachman Architecture Framework," Business Rules Journal, Vol. 18, No. 1 (Jan. 2017), URL:  http://www.BRCommunity.com/a2017/b888.html  

January 2017
Seven Common Myths About the Zachman Architecture Framework
By Ronald G. Ross with Gladys S.W. Lam


December 2016
Being Business-Friendly About the Life of Business Things
By Ronald G. Ross with Gladys S.W. Lam


November 2016
The Architectural 'Why' of a Business Capability: Concept Models
By Ronald G. Ross with Gladys S.W. Lam


October 2016
The Architectural 'Why' of a Business Capability: Business Mission and Business Goals
By Ronald G. Ross with Gladys S.W. Lam


September 2016
Architectural Scope vs. Project Definition
By Ronald G. Ross with Gladys S.W. Lam


August 2016
Pattern Questions for Harvesting Business Rules About Geography
By Ronald G. Ross with Gladys S.W. Lam


July 2016
Pattern Questions for Harvesting Business Rules About Organizations
By Ronald G. Ross with Gladys S.W. Lam


June 2016
Pattern Questions for Harvesting Business Rules from Business Models of Milestones or States
By Ronald G. Ross with Gladys S.W. Lam


May 2016
Pattern Questions for Harvesting Business Rules from Concept Models
By Ronald G. Ross with Gladys S.W. Lam


April 2016
Pattern Questions for Harvesting Business Rules from Business Process Models
By Ronald G. Ross with Gladys S.W. Lam


March 2014
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Steps 5 – 7: The Technical Steps

February 2014
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Step 4: Develop Scenarios

December 2013
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Step 3: Analyze and Refine

November 2013
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Part 3: Structure Business Logic

October 2013
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Part 2: Interpret from Sources

September 2013
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Part 1: Introduction

February 2013
Estimating the Time Required for Business Rules Harvesting — Part 2: Provide the Estimate

January 2013
Estimating the Time Required for Business Rules Harvesting — Part 1: Ask These 13 Questions

March 2012
Top 10 Mistakes Business Analysts Make When Capturing Rules — Mistake #10: Not Communicating

January 2012
Top 10 Mistakes Business Analysts Make When Capturing Rules — Mistake #9: Not Having a Business Rule Methodology

October 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules — Mistake #8: Not Having the Right Skill Set

August 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules — Mistake #7: Not Having a Well-Defined Scope

June 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules — Mistake #6: Not Having Strong Sponsorship

April 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules — Mistake #5: Not Having the Right Business Infrastructure

February 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules — Mistake #4: Not Managing Business Rules from the Start

January 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules — Mistake #3: Assume Everyone Knows What a Business Rule Is

December 2010
Top 10 Mistakes Business Analysts Make When Capturing Rules Mistake #2: Not Focusing on Terminology

November 2010
Top 10 Mistakes Business Analysts Make When Capturing Rules Mistake #1: Treating Business Rules Initiatives Simply As IT Projects

May 2006
Business Rules vs. Business Requirements

October 2004

Organizing A Pile of Rules

 

June 2004

Family Reunion... Facilitated Session… Having the Right People Doing the Right Things

 

November 2003

Family Reunion ... Facilitated Session -- Same Difference

 

September 2003

A Relationship between Process and Business Rules

 

July 2003

The Hidden Secrets about a Business Rule

 

May 2003

Plainly Speaking: What Is A Rule?

 

May 1998

Business Knowledge ~ Packaged in a Policy Charter Policy Charter as a Deliverable

 

 

 about . . .

 RONALD G. ROSS

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the IPSpeak methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:

Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997., now part of the Building Business Capability (BBC) conference. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. For more information about Mr. Ross, visit www.RonRoss.info, which hosts his blog. Tweets: @Ronald_G_Ross

 

 

 

[ Home ] [ Staff ] [ About BRC Publications ] [ Editorial Feedback ] [ About BRCommunity ]
[ Contributor's Guidelines ] [ Privacy Policy ]