Subscribe to the FREE Business Rules Journal Newletter


 

 

 

     ZACHMAN ARCHIVES ...
untitled

Fatal Distractions (part 1)

by John A. Zachman

July 2001

I am discovering four corruptions of architectural principles that are being inadvertently executed by well-meaning folks who are think they are doing "Enterprise Architecture" using the "Zachman Framework," but that inevitably will lead them unsuspectingly into a cataclysmic disaster.

  • First, they are renaming the Rows or Columns of the Framework in an effort to accommodate the current inventory of artifacts created during the Industrial Age.
  • Second, they are taking model-based approaches to implementations and presuming that the models constitute the Enterprise Architecture.
  • Third, they are "integrating" Frameworks by a process of aggregation.
  • Fourth, they are separating the services of the Enterprise from the Enterprise on the basis that the Service is the equivalent of a Product.

Each of the above is a kind-of Architectural malapropism.[1]  They all sound like Architecture, but they actually are not Architecture and invariably will result in the classic "Silver Bullet" syndrome: "The Zachman Framework? Well, we tried that and that didn't work!!"  Or, even worse, "Enterprise Architecture?  Well, we tried that and that didn't work!!"  Then it will be a decade or more before that Enterprise will be able to re-address this incredibly critical issue so vital to its survival in the Information Age.

These are the "Fatal Distractions"!

Denormalizing the Framework

First: Changing the names of the Rows and/or Columns and/or Cells of the Framework.

Although this does not appear to be a very significant issue, it has a profound impact on the integrity of the logic of the Framework.  In fact, it denormalizes the Framework.  It creates redundancies and discontinuities and leads to drawing erroneous conclusions.

For example, I have seen where some folks have renamed the Process Column of the Framework to "Services."  Here is the problem:  Services do not equal Processes.  It is NOT "Input -- Service -- Output."  It is Input -- PROCESS -- Output.  Process is a "transformation."  You take something in, do something to it (transform it), and send something different out.  "Service" is not a transformation and therefore is not answering the primitive question "How" does the Enterprise work. 

The "How" question is the basis for all of the Column 2 "Process" models.  Service is a "view" -- a collection of some components of the Enterprise that are intended to provide value to a Customer.  Clearly, "Service" does not equal "Process."  It is NOT a "transformation."  It is NOT the answer to the question "How?"

Also, I have seen folks who rename Column 1 to "Information."  This is a throwback to the old Industrial Age days when the end object of I/S was to build and run (computer) systems.  The idea was to replace people with machines because machines (computers) were "better, faster, and cheaper" than people.  The objective was to automate the process and get to implementation as soon as possible and therefore improve the per unit productivity of the Enterprise.  Therefore, data was always defined in the context of a process.  We SUB-optimized the Enterprise data by optimizing the implementation.

Data in the context of its use (a process) is "Information."  Information is a "view" of data.  This is the fundamental problem with the "legacy" today.  The "data" that served as input or output to processes were collections of data elements defined relative to the process, that is "information" or a "view" of the total set of Enterprise data.  Since the total set of Enterprise data was never defined, the implemented "views" were overlapping, redundant, inconsistently defined, named, and formatted.  That is, in the current inventory of systems, the same data is in there "n" different times with "x" different names, "y" different formats and worst of all, "z" different meanings.  This is not only costing an arm and a leg to maintain but it is causing a major amount of confusion and frustration for Management because they keep getting different answers to the same question and don't have a warm feeling that they know what is going on!

Clearly, you don't want to try to classify data by its usage (Information).  From a finite set of data, you can create an INFINITE amount of information.  Information is a "beauty in the eye of the beholder" problem.  Everyone has their own peculiar variation.  There is no standard.  Therefore, you have to classify data by its intrinsic meaning, independently of its usage, if you ever hope to achieve "reusability" and semantic continuity, that is, if you ever want to get rid of the "Tower of Babel" problem and "interfacing" ("spaghetti") in the Enterprise.

The data has to be "normalized."  In fact, anything you want to actually "manage" has to be "normalized," that is, defined in its non-redundant, coherent, integrated, reusable, Enterprise-wide, natural, "primitive" state BEFORE you create composite views of it (think of money, think of people, think of parts, think of chemicals, think of anything you want to manage ... think of data!).

This is the factor that led to the demise of IBM's BSP (Business Systems Planning) methodology.  Literally thousands of BSP Studies were conducted throughout the world, most of which were never successful.  In the '70's, people simply did not understand the difference between data and information and therefore attempted to classify the data based on its usage, not on its intrinsic semantic structure.  The "data vs. process" matrix was actually an "information vs. process" matrix which was meaningless because the same data was showing up in bunches of "informations."  Therefore, BSP was simply more of the same.  The data was classified by usage -- redundant, inconsistent, incoherent, "information," "views" ... related to processes and implemented.

Nothing had changed!

And, as you might expect, BSP fell prey to the Silver Bullet problem.  "Well, we tried that and that didn't work!"  So, 10 years later BSP was renamed ISP (Information Strategy Plan), which fell prey to the same Silver Bullet problem again.  So now 10 years later we are calling it EAP (Enterprise Architecture Planning), which will also fall prey to the Silver Bullet problem unless we can see the data as representative of the Things of the Enterprise, classified by their intrinsic, "primitive," semantic structure.

In any case, "Information" does not equal "Things."  "Things" constitutes the basis for the Column 1 models as "Things" answers the primitive question "What Things does the Enterprise care about enough to manage?"  The structure of the Enterprise "Things" is the "semantic structure" of the Enterprise -- the basis for "classifying" the data by its intrinsic meaning, quite independent from its usage (processes).  "Information" is infinite, defined in the context of its use and therefore not standard, not integrated, not reusable, not normalized, and not "architected."

Now you can see the effect of renaming Column 1 to "Information" and Column 2 to "Service:"

  Column 1 Column 2 Column 3 Column 4 Column 5 Column 6
  NOT What NOT How Where Who When Why





This is NOT the "Zachman Framework."

Even if you diligently populate all of the resultant cells with models, you will not answer the 6 primitive questions about the Enterprise from which you will be able to derive answers to any question anyone asks about the Enterprise.  You will not have the total "knowledge base" for the Enterprise.

You will have a mixture of redundant, inconsistent, disintegrated stuff ... not a repository of unique, coherent, non-redundant, normalized, primitive components.  All you would have is a matrix, not a logical, normalized structure.  In fact, in the first two columns you would likely have "composite" models, which leads me to the next point.

But before I address that, let me observe:  you may THINK you would be doing Architecture by populating the cells of the altered Zachman Framework, but actually it is not the Zachman Framework at all.  It is just a denormalized matrix and actually, you would only be doing more of the same -- the same we have been doing for the last fifty years that resulted in the legacy.

You would simply end up with more legacy!

It is inevitable, at some point the Enterprise is going to wake up and say ... "Well, the Zachman Framework.  We tried that and that didn't work!!"  Or worse, "Enterprise Architecture. We tried that and that didn't work."  Then you will have to wait for 10 more years to have another crack at solving the problem.[2], [3]

Composites Versus Primitives

This is an insidious problem because composite models are the work products of "application development."[4]  We know how to do these.  These are the kinds of models that we have been building for the last 50 years (that is, if we have built any models, they have tended to be composite models.)  Anyone who's intent is to build and run systems KNOWS that Enterprise-wide, primitive models (especially Enterprise-wide ones) take too long, cost too much, and are difficult to produce.

They are absolutely right.

Composite models are all you need to get to implementation as soon as possible.  You don't need primitive, normalized models.

Primitive models take longer and cost more and are harder to produce because you are trying to "engineer" them such that they are "normalized" -- you only have one primitive concept in there one time, so that the primitive concepts can be shared or "reused," so that you have Enterprise-wide integrity, so that every time you need some concept you reuse the same concept, so that you can reduce the time for ensuing implementations to virtually zero, that is, so you can "ASSEMBLE the Enterprise TO ORDER," so you can change the Enterprise with minimum time, disruption and cost, so you have a knowledgebase for the Enterprise from which you can answer any question that anyone needs to ask, etc., etc., etc.

The word "primitive" comes from the idea of the 6 "primitive" interrogatives:  What, How, Where, Who, When, and Why.  Each of these interrogatives is an independent variable, and the total of the 6 constitutes a complete, "normalized," primitive set.  For an Enterprise, this translates into Things, Processes, Locations, People, Time, and Motivation -- the Columns of the "Zachman Framework."  For the complete Enterprise description, you would have to build each of these models Conceptually (from the perspective of the business, "Owners"), Logically (from the perspective of the systems, "Designers"), and Physically (from the perspective of the technology "Builders".)  You would have to add the Scope and Out-of-Context perspectives to complete the Framework, but this article does not intend to be a tutorial on the Framework.  You can find that in other references.[5]

The point is, each cell of the Framework constitutes a "Primitive Model" -- a single variable from a single perspective.  A "Primitive Model" is composed of "Primitive Components."  For example, the Enterprise's Semantic ("Primitive") Model is composed of "Things" ("Primitive Components") and Relationships between the "Things."  If you are not describing "Primitive Components" that constitute "Primitive Models," you are not doing "Architecture."

Furthermore, if you are not defining the Primitive Model across the scope of the entire Enterprise, that is, 'Enterprise-wide," then you are only going to realize the reuse of the Primitive Components" WITHIN the scope that you have defined the Primitive Model.  If you want reuse ("normalization," integration, etc.) across the scope of the ENTIRE Enterprise, then the Primitive Model must be defined Enterprise-wide.  Reuse ("Integration, "Normalization, "Standard Interchangeable Parts," etc.) does NOT happen by accident. It has to be ENGINEERED.[6]   (Please read the footnote!!!)

Primitives are ARCHITECTURE, which are engineered to be used in more than one implementation.  Composites are simply application development artifacts (comprised of components from more than one Primitive Cell Model), which are necessary for a single implementation.

Architects produce primitives.  Systems designers produce composites.

There is nothing the matter with composites.  You need composites for implementation.  All you need for implementation are composites.  Composites are good.  But, if you create the composite ad hoc, that is, for the purpose of one implementation, then the composite is only good for that implementation, that is, it is good as long as nothing changes.  You have created (and "locked in concrete") a "point-in-time" solution -- a "view."

This is the problem with the legacy today.  It is a conglomeration of composite, point-in-time solution "stovepipes" that are costing an arm and a leg to maintain and ultimately will have to be replaced, if (when) anything in the Enterprise changes.  We optimized the implementation and sub-optimized the Enterprise.  (Remember however, there were substantial SHORT-TERM benefits to this!  We got to implementation, system by system, as soon as possible ... but we DIS-integrated, SUB-optimized, DE-normalized the Enterprise in the process.)

On the other hand, if you have engineered primitives and assemble the composites from the primitives, then you can assemble virtually any composite you need dynamically, reduce time-to-market for implementation immeasurably, and you can change the Enterprise at will with minimum time, disruption, and cost.  (These are even greater LONG-TERM benefits.)

You can see the problem.  If you are building models and you think you are doing Architecture and you are not building Primitive Models, you are just building systems ... implementing, NOT architecting.

Worse, if you have renamed the first two Columns of the Framework to "Information" and "Services," you are justifying the use of the composites and convincing yourself that you are doing Architecture.  You THINK you are okay, but in reality, you are right back where we have been for the last 50 years.

You are just building more legacy.

It is only a matter of time before the Enterprise wakes up as says, "Well, Enterprise Architecture and the Zachman Framework! We tried that and that didn't work!! All we got is more of what we already have, legacy!!"

Accidental Integration by Magic

This is another insidious problem.

Some Enterprises are so big and so complex that it is intimidating to try to think about applying the concept of Architecture to the entire Enterprise, that is, one Framework for the whole Enterprise.  In fact, many times the organization of a large Enterprise that produces many diverse products or services will evolve such that stand-alone business units are created for decentralized management of the product or service (which tends to be unique) and centralized organizations are created to manage those aspects of the Enterprise that tend to be "common" or "shared," like "infrastructure."

In fact, in really big Enterprises they may group the business units into "Groups" or "Clusters" where there is at least some "sharing" potential around the products or services.  So, you could have "Business Units" (or "Divisions" or "Departments") grouped into "Groups" or "Clusters" (where there was potential leverage for sharing, typically around the products or services or customers ... wherever there was "sameness") and then some central "Enterprise" group for managing what is common to all the "Groups."  Some things are common to all ("Enterprise"), some things are shared by some ("Group/Cluster"), and some things are unique ("Strategic Business Units," or "Divisions," or "Profit Centers," or "Departments," etc.).[7]

If you are going to use the Framework to help you think about this kind of a complex Enterprise, you could apply the Framework logic to every single business unit on a stand-alone basis.  "Enterprise-wide" would mean Business Unit-wide and the analysis would be containable.  The General Manager of that Business Unit would have jurisdictional control over the models within one Business Unit and could unilaterally declare their structure and description.

However, in this case, you would not be able to realize any benefits of sharing, commonalities, reuse, etc.  To compensate, you could group Business Units into Clusters where there is likely some potential sharing and deliberately search for it and then engineer for it.  The whole Enterprise would be comprised of the set of Clusters, which, in turn, could be examined and engineered for commonality.

The Business Unit Frameworks are "Peer" Frameworks because they are all Frameworks for Enterprises.  Wherever you have "Peer" Frameworks all in the same Enterprise, they all could potentially be "integrated" into one Enterprise Framework.  It is convenient to consider the Business Units separately for analytical purposes (above), but where you want sharing to take place, or where you want to leverage commonality, those slivers of those cells of the Business Unit Frameworks that are to be shared or common have to be made THE SAME.  Otherwise, they are not going to be "shared" or "common" or "INTEGRATED."

You don't get "integration" by accident.

If you WANT integration, then you have to ENGINEER integration.  That means that you will have to DICTATE to the Business Units that you want such and such slivers of such and such Cells of their Frameworks to all be THE SAME.  Alternatively, you could require that the Business Units all get together and NEGOTIATE the common slivers of cells where there is leverage for sharing or commonality.  The former approach (dictate) is faster.  The latter approach (negotiate) produces more commitment.

If you don't either dictate or negotiate (one or the other), you are not going to get integration, that is, you are not going to get sharing or commonality or reuse.  And ... if you are trying to address sharing or commonality with composites ... GOOD LUCK!!  There are an infinite variety of composites!  The only way you are ever going to get there is with PRIMITIVES.  (There is an infinite number of composites and everybody has their own peculiar twist on how to compose them, whereas there is a finite number of primitives and at the primitive component level you can see, or agree to, their sameness.)

Furthermore, you have to define what is shared or common BEFORE you get to implementation, that is, before you get any systems built.  After you get the systems built, there is NO WAY to post integrate them.  You are into "throw those things away and start over again" ('scrap and re-work').[8]

This is precisely where we are with the legacy today!!  It is not integrated, and it is frustrating and costing a lot of money to keep running, and no amount of more technology is going to fix it, and nobody wants to hear that it has to be scrapped and re-worked, and the stress levels are out-of-sight!!  (Note: if it was easy to post-integrate systems after they are built, you could just post-integrate the legacy and you wouldn't have a legacy!)

Could you use the Framework to help you think about sharing at the Cluster level?  Sure!

This is what I have always referred to as "Sameness Templates."  You could define a Framework "template" either through declaration (dictation) or negotiation that would specify which slivers (or slices) of which Cells you want to make the same across a set of Business Unit Frameworks.  You could actually define a Cluster Framework in its own right and then you would have to figure out a way to ensure that the Business units actually used (or reused) the primitive components that were defined by the Cluster Framework in their own (Business Unit) implementations.  It would actually be to the Business Unit's advantage to reuse components that were already defined and that were in fact THE SAME as they needed.  It would be a LOT cheaper and faster than building them all themselves!!

Likewise, you could define a "Sameness Template" at the Enterprise level for defining what you want to be the same across all Clusters.  The same logic holds.  The Enterprise Framework (Sameness Template) is likely related to "infrastructure management" -- what some people are calling "internal services."

Here is the insidious problem.   If you think you can collapse (or merge) several peer Frameworks into a single Framework and then by some magic, they are automatically integrated, you are in for a rude awakening.   Worse ... if you think you can define composite models, map them against the Business Unit Framework, and then collapse several Business Unit Frameworks into a single Cluster Framework, and by some magic the models will be factored into primitive models and mystically integrated with all the other Business Unit models without doing any "engineering" (that is, Architecture), you are in for an even bigger surprise!!

This was at the heart of the tragic demise of the IBM Repository a decade or more ago!!  They thought they could take the Bachman metamodel, the KnowledgeWare metamodel, and the Eccelerator metamodel (which were all different metamodels), merge them (collapse them) into a single metamodel, and by some magic and mystical process they became automatically "integrated."  If that wasn't bad enough, then they thought they could dump CASE tool COMPOSITE models from any CASE tool known to mankind (each with its own proprietary metamodel) into the data base derived from the merged (not architected) IBM Repository metamodel and the CASE tool COMPOSITE models would somehow be magically and mystically factored into primitive components and integrated (shared, reused, normalized, common, etc.)!!

Please be careful on this one!!  Before we criticize the spec in IBM's eye, we had better take careful look at the BOARD in our own eye!!  Are we making an assumption that integration (sharing, reusability, commonality, etc., etc.) can be achieved with no engineering (Architecture) work -- simply by collapsing (or merging) Frameworks together?

Integration (reuse, sharing, etc.) does not happen by accident and it is not magic.  It has to be ENGINEERED ... or maybe I should say, ARCHITECTED!

Need I point out once again where this collapsing or merging peer Frameworks with no primitive engineering and no edicted or negotiated standards will lead?  It is only a matter of time before it will be, "Well, all we have is more legacy! Enterprise Architecture, the Zachman Framework, we tried that.  That didn't work!!"

(To be continued.)

References

[1] A "malapropism" is the misuse of a word, especially by confusion with one of similar sound.return to article

[2] Note:  There are similar problems with renaming either the Rows or the Cells but this article is becoming too long to elaborate those issues.  Let it be sufficient to say, if you get Conceptual, Logical, and Physical things in the same model (a vertical composite), now you have confusion!  Also, if you rename a cell to accommodate a "composite" (like rename Column 4, Row 2 from "Work Flow" to "Swim Lane") now you have real confusion ... see the next section, "Composites Versus Primitives."return to article

[3] Note on renaming Rows:  There are people who want to rename Row 3 to "Architect's Perspective" and Row 4 to "Designer's Perspective."  I know this is more consistent with common usage in the Information Technology community today, but the Architecture problem is an ENTERPRISE problem, and we have to communicate it to Enterprise people, and "Owner, Designer, and Builder" sings to the Enterprise.  Furthermore, you would have a very hard time convincing an Architect (who builds buildings - doing Row 3 work) that he was NOT "Designing" ... or an Engineer that was designing airplanes that he was not "Designing."  Likewise, you would have an equally difficult time convincing a General Contractor who was building buildings that he was NOT a "Builder" and a Manufacturing Engineer that was figuring out how to build the airplane that he was not a "Builder."  I would not change the names to conform to the information community's current usage.  It will just add confusion!return to article

[4] I wrote a whole article about this, "Architecture Artifacts versus Application Development Artifacts" that can be found at www.brcommunity.com.return to article

[5] See my bibliography which can be found at www.zifa.com.return to article

[6] Notice!!!  I am not saying you have to build out all 30 cells Enterprise-wide before you can implement anything.  You can compromise the overall Enterprise integrity, but you should clearly understand it is a COMPROMISE and understand the implications of the compromise.  Some cells of the Framework you can compromise with impunity (e.g. Columns 2 and 4).  Other cells you should hold the line determinedly (e.g. Columns 1, 3, and 6).  Sometimes you can mitigate the downstream impacts of a compromise (e.g. "promote slivers to Enterprise-wide Quality").  Sometimes there are ways to segment the cell (break it up into parts) without causing disintegration (sub-optimization) (e.g. determine build sequence based on entity-dependency).  These are decisions and choices that balance the long term and the short term and should be made as a part of your Enterprise Architecture Strategy.return to article

[7] This is typical in a large Public Sector organization. return to article

[8] See my article "Architecture Artifacts versus Application Development Artifacts." Ibid.return to article

Copyright, 2001. Zachman International.

January 2017
The Issue Is THE ENTERPRISE
By John A. Zachman


October 2016
Strategy Spectrum for Enterprise Engineering and Manufacturing
By John A. Zachman


July 2016
The New EA Paradigm
(4) The Assemble-to-Order Pattern

By John A. Zachman


June 2016
The New EA Paradigm
(3) The Provide-from-Stock Pattern

By John A. Zachman


May 2016
The New EA Paradigm
(2) The Make-to-Order Pattern

By John A. Zachman


April 2016
The New EA Paradigm
(1) Expenses and Assets

By John A. Zachman


March 2016
The Information Age: (3) Powershift
By John A. Zachman


February 2016
The Information Age: (2) The Third Wave
By John A. Zachman


January 2016
The Information Age: (1) Future Shock
By John A. Zachman


December 2015
Defining Enterprise Architecture: Economics and the Role of I.T.
By John A. Zachman


November 2015
Enterprise Physics 101
By John A. Zachman


September 2015
A Historical Look at Enterprise Architecture with John Zachman
By John A. Zachman


August 2015
Cloud Computing and Enterprise Architecture
By John A. Zachman


June 2015
The Zachman Framework Evolution (Part 2)
Special Guest: John P. Zachman


May 2015
The Zachman Framework Evolution (Part 1)
Special Guest: John P. Zachman


April 2015
Architecture is Architecture is Architecture
By John A. Zachman


April 2013
John Zachman's Concise Definition of The Zachman Framework
By John A. Zachman


November 2004
The Zachman Framework and Observations on Methodologies

 

November 2003

Framework Fundamentals: Frameworks, Reference Models, and Matrices

 

August 2003

Framework Fundamentals:  A Dialog With John Zachman

 

June 2003

Framework Fundamentals:  Miscellaneous Enterprise Engineering Concepts

 

April 2003

Framework Fundamentals:  Framework Fundamentals:  Level of Detail is a Function of a CELL

 

February 2003

Framework Fundamentals:  Responding to Questions from the OMG

 

May 2002

Enterprise Quantum Mechanics (Part 2)

 

March 2002

Enterprise Quantum Mechanics (Part 1)

 

January 2002

"What" Versus "What"

 

November 2001

Security And The "Zachman Framework"

 

September 2001

Fatal Distractions (Part 2)

 

July 2001

Fatal Distractions (Part 1)

 

May 2001

You Can't "Cost-Justify" Architecture

 

March 2001

Conceptual, Logical, Physical:  It Is Simple  (Part 2 of 2)

 

January 2001

Conceptual, Logical, Physical:  It Is Simple  (Part 1 of 2)

 

September 2000

Building The Enterprise - An Infusion Of Honesty

 

July 2000

All the Reasons Why You Can't Do Architecture or ("We Has Met the Enemy and He Is Us")

 

May 2000

Enterprise Architecture Artifacts vs Application Development Artifacts (Part 2)

 

March 2000

Enterprise Architecture Artifacts vs Application Development Artifacts (Part 1)

 

November/December 1999 & January/February 2000

Enterprise Architecture: Issues, Ingibitors, and Incentives


July/August & September/October 1999

Packages Don't Let You Off The Hook

By John A. Zachman


January/February & March/April 1999

Life Is a Series of Trade-Offs and Change Is Accelerating!


November/December 1998

"Yes Virginia, There IS an Enterprise Architecture"


July/August 1998

Enterprise Architecture:  Looking Back and Looking Ahead


January/February 1998

The Framework for Enterprise Architecture (The 'Zachman Framework') and the Search for the Owner's View of Business Rules

 

 

 about . . .

 JOHN A. ZACHMAN

 

John A. Zachman is the originator of the “Framework for Enterprise Architecture” (The Zachman Framework™) which has received broad acceptance around the world as an integrative framework, an ontology for descriptive representations for Enterprises. Mr. Zachman is not only known for this work on Enterprise Architecture, but is also known for his early contributions to IBM’s Information Strategy methodology (Business Systems Planning) as well as to their Executive team planning techniques (Intensive Planning).

Mr. Zachman retired from IBM in 1990, having served them for 26 years. He is Chief Executive Officer of his own education and consulting business, Zachman International®.

Mr. Zachman serves on the Executive Council for Information Management and Technology (ECIMT) of the United States Government Accountability Office (GAO) and on the Advisory Board of the Data Administration Management Association International (DAMA-I) from whom he was awarded the 2002 Lifetime Achievement Award. He was awarded the 2009 Enterprise Architecture Professional Lifetime Achievement Award from the Center for Advancement of the Enterprise Architecture Profession as well as the 2004 Oakland University, Applied Technology in Business (ATIB), Award for IS Excellence and Innovation.  In August 2011,  he was awarded the Gen. Colin Powell Public Sector Image Award by the Armed Services Alliance Program.

Mr. Zachman has been focusing on Enterprise Architecture since 1970 and has written extensively on the subject. He has facilitated innumerable executive team planning sessions. He travels nationally and internationally, teaching and consulting, and is a popular conference speaker, known for his motivating messages on Enterprise Architecture issues. He has spoken to many thousands of enterprise managers and information professionals on every continent.

In addition to his professional activities, Mr. Zachman serves on the Elder Council of the Church on the Way (First Foursquare Church of Van Nuys, California), the Board of Directors of Living Way Ministries, a radio and television ministry of the Church on the Way, the President’s Cabinet of the King’s College University, the Board of Directors of the Los Angeles Citywide Children’s Christian Choir, the Board of Directors of Heavenworks, an international ministry to the French-speaking world and on the Board of Directors of Native Hope International, a Los Angeles-based ministry to the Native American people.

Prior to joining IBM, Mr. Zachman served as a line officer in the United States Navy and is a retired Commander in the U. S. Naval Reserve. He chaired a panel on "Planning, Development and Maintenance Tools and Methods Integration"  for the U. S. National Institute of Standards and Technology. He holds a degree in Chemistry from Northwestern University, has taught at Tufts University, has served on the Board of Councilors for the School of Library and Information Management at the University of Southern California, as a Special Advisor to the School of Library and Information Managementat Emporia State University, on the Advisory Council to the School of Library and Information Managementat Dominican University and on the Advisory Board for the Data Resource Management Programat the University of Washington. He has been a Fellow for the College of Business Administration of the University of North Texas and currently is listed in Cambridge Who’s Who.

 

 

 

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