The Zachman Framework™

What is The Zachman Framework™? Click for the Official Concise Definition and new graphic:

Follow us on Twitter

Follow Zachman International on Twitter and get the latest news and specials.

Print The Framework

Log in and PRINT your personal, licensed, high-resolution copy of The Zachman Framework™.
No Cost!!!

Thursday, 18 September 2014

Enterprise Architecture FAQs

Zachman Certified™ FAQs

Technical FAQs

Enterprise Architecture FAQs

What is Enterprise Architecture and why do we do it?

"Architecture is a set of descriptive representations that are relevant for describing something you intend to create and that constitute the baseline for changing an instance of that thing once you have created it. Therefore, Enterprise Architecture is the set of descriptive representations relevant for describing an Enterprise and that constitutes the baseline for changing the Enterprise once it is created." - John Zachman, taken from interview with Roger Sessions, Editor-in-Chief: Perspectives of the International Association of Software Architects

"If you get really honest and search all of history, seven thousand years of known history of humankind, to find how humanity has learned to cope with two things, complexity and change ... there is one game in town, ARCHITECTURE.

If it (whatever it is) gets so complex you can't remember everything all at one time, you have to write it down... ARCHITECTURE. Then, if you want to change it (whatever it is), you go to what you wrote down... ARCHITECTURE.

How do you think they build hundred story buildings, or Boeing 747's, or IBM supercomputers... or even simple things like a one-bedroom house or a Piper Cub or the PC on your desk? Somebody had to write it down... at excruciating levels of detail... ARCHITECTURE. Now, if you want to change any of those things (with minimum time, disruption and cost), how do you change them? You go to what you wrote down... ARCHITECTURE.

The key to complexity and change is ARCHITECTURE.

In the Industrial Age, we had to learn what architecture was relative to physical objects (products) in order to deal with product complexity and product change.

In the Information Age, it is the Enterprise that is complex and changing and therefore, now we are having to learn what architecture is relative to the Enterprise ... Enterprise Architecture.

This is what is making the Framework for Enterprise Architecture so significant in the Enterprise community as we move into the Information Age. The Framework is putting some definition around Enterprise Architecture."

-John Zachman
"The Zachman Framework for Enterprise Architecture™: A Primer on Enterprise Engineering and Manufacturing"



How can I learn more about Enterprise Architecture?

  1. Watch these video clips on Enterprise Architecture.
  2. Learn about the industry-standard Zachman Framework™.
  3. Read John Zachman's eBook, “The Zachman Framework for Enterprise Architecture™: A Primer on Enterprise Engineering and Manufacturing.”
  4. Take one of the Zachman International courses.
  5. Read John Zachman's interview with Roger Sessions.



How can I learn more about The Zachman Framework™?

Part of the Zachman International's mission is to further understanding and to educate professionals concerning The Zachman Framework™. John Zachman has developed many resources to this end. We recommend you start with the following:

  1. Download John Zachman's original 1987 article on the Framework. (The high quality 1999 reprint is easier to read but the download is 15Mb.)
  2. Read some of the 21 the articles John Zachman has written on the Enterprise Architecture that can be found in Appendix A of the Zachman eBook™.
  3. Register for the Standards and for access to the new Framework Graphic.
  4. Take one of the Zachman International courses.



Do I have to build models in order to do Enterprise Architecture?

Enterprise Architecture is all about PHYSICS. Nothing magic is going to happen and you can’t create something out of nothing… no matter whether you want to hear this truth or not.

Here are some of observations:
1. If you are not building models, you are not doing any design, you are only manufacturing.
2. If you are not building PRIMITIVE Models, you are not doing Architecture, you are implementing.
3. If you are not building the higher Row models, there is NO WAY you are going to produce anything that will be aligned with what management has in mind. (You can build a prototype, but remember that is not "design" and if the prototype becomes operational, you are DIS-integrating the Enterprise at a VERY granular level.)
4. If you are not building Enterprise-wide models, you are implementing "stovepipes," "islands of automation."
5. If you are not building excruciating level of detail models, you are making assumptions about the details and then you will have potential defects… which, will have to be removed at some point and the closer you get to implementation before you find the defect, the more it is going to cost you to get the defect out. (Look at your "Maintenance budget.")
6. if you are not retaining the models you build, your underlying assumption is that nothing is ever going to change… because if something changes, you are going to have to reverse-engineer the models from the running code… IF there is enough information left in the running code to reverse-engineer them.



Why is Rapid Application Development really Implementation and NOT Architecture?

Usually, by its very name, a "rapid application development"- style methodology’s Enterprise engineering design objective is "IMPLEMENT" as soon as possible. The engineering design objective for rapid application development-style methodologies is NOT Alignment, NOT Integration, NOT Flexibility, NOT Interoperability, NOT Reduced Time-to-Market, NOT Quality, NOT Security, etc. Those Enterprise engineering design objectives actually require ENGINEERING. Engineering requires PRIMITIVE MODELS, the "raw material" for engineering. Primitive Models are "analysis/paralysis" relative to rapid implementations… UNLESS, you already have the Primitive Models in inventory, in which case, implementations are virtually instantaneous, a click of a mouse, ASSEMBLE TO ORDER… BUT, the investment has to be made in the Primitive Models BEFORE you get the order for the implementation.

So, if you want the short-term approach, that is, to get to implementation as soon as possible, forget about models, write the code. Build more legacy.

On the other hand, if you want the long term approach, that is, if you want Flexibility, Integration, Reusability, Alignment, Security, Interoperability, etc. forget about the code, start building (Primitive) models. In fact, if you want to reduce the time it takes to produce an implementation to just the time it takes to click a mouse, then start building up an inventory of reusable, Primitive Models.



Sometimes, isn't redundancy and complexity necessary or even desirable? For instance, isn't a large retailer more successful with thousands of redundant stores and massive complexity?

You can have as many instances (redundant retail stores) as you want in Row 6:Operations Classes, but you only want a single abstraction in Row 1:Scope Context, Row 2:Business Concepts and Row 3:System Logic. It is conceivable to have more than one abstraction in Row 4:Technology Physics and Row 5:Component Assemblies, but if you do, you have to keep track of them as they relate to Row 3:System Logic or else you will go out of control- potentially have an entropy problem. They will get out of sync.

That is, you don't want any discontinuity in the Concepts (Row 2) or the Logic (Row 3). It is conceivable that you might want to implement in more than one Technology (Row 4), but now you have a synchronization problem that you will have to manage.

In terms of Row 6:Operations Classes instances, there can by "n" of those, but you want each instance to trace back to the Assemblies Transformation (Row 5), the Physics Transformation (Row 4), the Logic Transformation (Row 3), and the Concept Transformation (Row 2), and probably the Scope Transformation (Row 1) as well. That is how you insure that the reality of the Enterprise is consistent with the Enterprise Architecture. And when the "Systems" say there are 423 Employees in stock, there are actually 423 Employees in stock, etc., etc... and when we say the Concept "Employee" (Row 2:Business Concepts), it means the same across the entire Enterprise and that all the Employee instances (Row 6:Operations Classes) obey that authorized Enterprise Concept (Row 2:Business Concepts) definition.

If you did this, you could actually manage the Enterprise.



How do you "cost-justify" Enterprise Architecture?

Technically, you can't cost-justify Enterprise Architecture because Enterprise Architecture is NOT an expense... it is an asset. Cost-justification is an expense-based concept that has to do with saving money in the current accounting period. In contrast, return on investment (ROI) is an asset-based concept that has to do with deriving value in multiple, future accounting periods through reusing an asset in which an investment was made. Enterprise Architecture does not save money in the current accounting period. Enterprise Architecture requires an investment which can be reused to derive value (potentially, a LOT of value – assuming it is engineered effectively) in multiple future accounting periods.



Zachman Certified™ FAQs

How much does the Zachman Certified™ program cost and what exactly do I have to do?

In comparison to other certification programs out there, the Zachman Certified™ program is very affordable.

To become a Level 1 Zachman Certified - Enterprise Architect, you need to complete three components: 1) you must complete our Z101 and Z102 Masterclass. Both courses are run in succession as The Complete MasterClass and depending on the country, it is generally priced right under $3000 US. 2) You must complete our Z103 Pragmatics: Enterprise Modeling Workshop. Depending on the country, it is generally priced right under $2500 US. 3) You must complete and pass the ICCP Zachman Certified™ examination. It's cost is built into the price of the modeling workshop. So essentially, to become a Zachman Certified - Enterprise Architect, it will take you 7 days of training for just under $5500. Complete details...

To become a Level 2 Zachman Certified - Enterprise Architect Professional, you must have completed Level 1 and additionally do ONE of the following three components: 1) acquire one of the various methodology capabilities available in the industry (i.e.: Enterprise Engineering, TOGAF, FEAC, etc.) and do an EA methodology project mapping the methodology against The Zachman Framework™. 2) Demonstrate knowledge of The Zachman Framework™ through three evaluated conference presentations. 3) Demonstrate knowledge of The Zachman Framework™ through a minimum of five approved, implemented elaborations. Complete details... There is a nominal charge based on evaluation hours to have us evaluate your project. So the total cost of Level 2 Zachman Certified - Enterprise Architect Professional is the $5500 approx. you spent on Level 1 Zachman Certified™, plus whatever costs you incur by doing some other methodology certification, and the nominal fee associated with us evaluating your project.



How can I verify is someone is Zachman Certified?

Anyone can verify Zachman Certified™ status by clicking here: Status Verification. While there has been much claim recently about Zachman knowledge, our site now offers employers, colleagues or anyone looking to verify Zachman Certified™ status the ability to search the Zachman database by a person's full name or Architect ID.

Once a name has been queried, the resultant information will show which Zachman Certified™ Level the individual has attained and if their status is current, in addition to showing their unique Zachman Certified™ seal with embedded Architect ID.



What happened to ZIFA?

ZIFA (The Zachman Institute for Framework Advancement) was an informal collaboration between John Zachman of Zachman International, and Sam Holcman of Pinnacle Business Group. It was initially intended to be a vehicle for research on The Zachman Framework™, however no Framework research was ever conducted under ZIFA.

An annual conference, the ZIFA Forum, was held from 1996 thru 2004 and Enterprise Architecture Seminars have been conducted under the ZIFA name until the present with one and a half days of Framework Concepts by John Zachman and one and a half days of Sam Holcman’s Enterprise Architecture Planning Methodology.

All Framework research has been conducted under the auspices of Zachman International and Sam Holcman has created a new venture, the EA Center of Excellence (EACOE) which presumably is intended to market and train in the Holcman planning methodology. John A. Zachman was neither consulted about nor invited to participate in the EACOE and therefore, that new venture is completely independent of and disassociated with John A. Zachman and The Zachman Framework™. There is no continuing purpose for the Zachman Institute for Framework Advancement (ZIFA). Mr. Holcman has recommended and Mr. Zachman has agreed to dissolve ZIFA, year end 2008.



What is the real scoop with consulting companies who claim to "implement The Zachman Framework™?"

"There are NO consulting companies, ZERO, that I know of that actually 'implement The Zachman Framework™'. In fact, The Zachman Framework™ is not implementable… it is not an implementation. It is an ontology. Someone could build, store and reuse components of the Framework primitive models to create engineered, Enterprise implementations, and several organizations have now petitioned Zachman International to confirm that their methodological use of The Zachman Framework™ is certified as compliant or that their architecture work products are certified as conforming to the metamodel of one or more cells of The Zachman Framework™. They will be listed under Status Verification upon completion of the Certification process.

If any person or company claims to do something with, or know something about The Zachman Framework™, or they claim to be Certified in The Zachman Framework™ and their name does not appear when searched on the Zachman International site here: Status Verification, then I would have to question the veracity of their claim and whether or not they actually know anything about the fundamental concepts embodied in The Zachman Framework™." - John A. Zachman



Why does The Enterprise Modeling Workshop start before the MasterClass in the same week?

This is done for two reasons. The first reason, is that in our experience, the sheer amount of information in both of those courses is dramatically too much to process in one week's time. We have found that people assimilate the new concepts we are introducing much better if they have time to let the contents of the MasterClass "sink in" before they attempt to build models.

The second reason is travel cost. We can start the MaasterClass on a Tuesday while the Modeling Workshop is concluding on a Tuesday and Wednesday thus achieving seven days of training into five.



What is your education cancellation policy?

If you have signed up for one of our courses and can not make the trip for some reason, you have three options:

  1. You can transfer your course fee to a future course. For instance, if you were signed up for The Complete MasterClass in February and could not make it, but could make it in March, then you could come to The Complete MasterClass in March even if it is at a different location.
  2. You can substitute your seat for someone else in your organization.
  3. You can cancel for a refund which is subject to a $100 cancellation fee, as long as you do it within three weeks of the course. Unfortunately, we can not accept cancellations within three weeks of any course running.



Can I pay for courses using a corporate check?

Yes. We will accept corporate or company checks to pay for any of the Zachman courses. If you need to pay by check, please send an email to: This e-mail address is being protected from spambots. You need JavaScript enabled to view it for details and mailing address.



Technical FAQs

Why does your web site have the black "Home Page" and "Contact Buttons" right on top of the world graphic?

Not all browsers (i.e.: Internet Explorer 6) render our graphics correctly. We are aware of the issues and are working on it.



Why does your web site wrap all the text below the menus?

Are you viewing the site in Internet Explorer 6? That's why. We are aware of the Internet Explorer 6 problem and are working on it.



Why won't John's eBook run on my mac?

The eBook is designed to run on a Windows system only, because we write into various parts of the Windows OS. Emulating Windows on a mac through Parallels or Bootcamp is not exactly like running the Windows OS, so therefore the eBook can't register the way it was designed.