John A. Zachman is the originator of the “Framework for Enterprise Architecture” (The Zachman Framework™)
Mr. Zachman serves on the Executive Council for Information Management and Technology (ECIMT) of the United States Government Accountability Office (GAO). He has been a Fellow for the College of Business Administration of the University of North Texas and is currently listed in Cambridge Who’s Who.
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.
What attracted you to data management or IT, and why did you choose to pursue this career?
In 1969, Atlantic Refining out of Philadelphia acquired Richfield Oil Company out of Long Beach to form Atlantic Richfield, and Atlantic Richfield acquired Sinclair Oil out of New York, the biggest corporate merger in history. I was the IBM Account Manager for Sinclair and became the IBM Account Executive for the newly formed Atlantic Richfield Company, ARCO. The CEO, R.O. Anderson, wanted to create a single, “integrated” (key word) oil company from the three independent companies. Jack Murray, Vice President of Administration said, “Zachman, how do you think we ought to do this?” I said, “Jeeeeeeze Jack. I have no idea. I’ll try to find someone who has some ideas about it.”
I stumbled across Dewey Walker, who came out of one of the IBM Manufacturing Divisions and at that time was in Large Account Marketing documenting his methodology. Dewey had a planning methodology that he knew was NOT information systems planning so he named it BUSINESS Systems Planning as opposed to Information Systems Planning. As Director of Architecture, one of five Directors on the Information Systems Control and Planning Staff, Dewey had built the Enterprise PROCESS Model. The other four Directors included Directors of Plans, Controls, Data, and Communications. Therefore, the staff was comprised of 1) Plans and Controls and 2) Process, Data, and Communications (the infrastructure) … pretty innovative for 1965.
In 1972, I arranged for Dewey to come to Los Angeles to speak with ARCO General Management. When I was taking Dewey back out to the airport, he said, “the key to this whole Enterprise ‘integration’ issue lies in the coding and classification of the DATA.” My response was, “The DATA!!! What does the tape library have to do with anything?!” (To me, data was just the hundreds of reels of tape hanging in the tape library that were required in order to get the code to run!) Remember, Chen didn’t publish until 1977 so Dewey had no words to use like “enterprise-wide,” “fully-attributed,” “normalized,” “logical data model,” etc. to describe what he was talking about. Ironically, IBM didn’t care about data or enterprises either one … they cared about process, specifically, the Industrial Age Paradigm, getting the code to run, consistent with the rest of the known world. Dewey got frustrated and resigned and became the Vice President of Management Systems for Humana, and I, because I was the only one who had any idea about what Dewey was trying to do, became the de facto owner of Dewey’s methodology, Business Systems Planning (BSP). And … that’s how I got interested in DATA, but more specifically, ENTERPRISE ARCHITECTURE, the set of descriptive representations that constitute the design of the enterprise … all of which are DATA.
What has been your greatest career accomplishment so far, and why has it been important to your career?
As the de facto owner of Dewey’s methodology, Business Systems Planning, now I had to actually figure out what Dewey was doing or at least trying to do. Assigned to IBM’s Western Region, I was doing a lot of strategy work in the airframe manufacturing industry and the biggest challenge was figuring out how to transform the business strategy into implementation. We didn’t know how to transform the strategy into the reality of the enterprise, such that it was “aligned” with management’s intent. The Enterprise strategy boils down into something like “make money” (in the private sector) or “spend money” (in the public sector) but the enterprise implementations in a digital economy were a series of bits and bytes. So, the question was, “how do you get from “make (or spend) money” to 1001 0100 0101 1110, etc., etc.” We thought that maybe, “architecture” had something to do with this, but we had no idea what “architecture” was for enterprises.
I reached out to an architect friend of mine and with his architecture and construction knowledge coupled with my experience in engineering and manufacturing strategy enabled me to see the pattern for descriptive representations that constitute the design of Industrial Age, tangible objects (buildings, airplanes, ships, computers, coffee pots, etc., etc.). By examining various examples including enterprises, it was easy to verify that this pattern is the pattern for design descriptions of anything. I simply took the pattern for Industrial Age, tangible products, and substituted the names for Information Age, conceptual products, like enterprises, to become the “Zachman Framework for Enterprise Architecture.” It was only years later that I discovered ontologies and it dawned on me that my framework actually was an ontology, i.e., a classification structure for all the facts that are relevant to the existence of an object (enterprise) upon which the existence of the object (enterprise) is dependent.
In 1980, I was on a Task Force where I was simply trying to prove to IBM that BSP was only one methodology, a Row 1 methodology, not the comprehensive “end-all to be all” methodology. Unbeknownst to me, the task force intent was to establish “my” methodology (BSP) as the official, IBM methodology. I was using my framework to prove that there were many other methodologies relevant to the enterprise, not simply BSP. It turned out that the task force was not convened to discover facts but only to provide confirmation and BSP became the official IBM Methodology despite my objections. The task force conclusions later proved to be incorrect but also proved my objections correct. However, unbeknownst to me, I had stumbled across a kind-of Law of Nature that had universal, persistent, implications much like the Periodic Table in the chemistry domain. Chemically, from a finite set of single-variable “elements” one can produce an infinite set of multi-variables “compounds.” Similarly, in the enterprise domain, from a finite set of ontologically defined, single-variable, “primitive” components (“elements”), one could produce an infinite set of multi-variable “composite” (“compound”) implementations … dynamically.
The Zachman Framework is simply a two-dimensional classification structure of unique, independently varying, “primitive” categories for all the facts that are relevant to the existence of an enterprise. Those facts, in totality, constitute the knowledgebase of the design of the enterprise, the formal expression of how the enterprise works.
This has significant implications for humanity as we transition to the new, Information Age, “digital” paradigm! An enterprise can be explicitly designed and dynamically assembled from standard, unique, reusable, “primitive” components and changed on demand (i.e., “mass-customization”) to accommodate the extremely high rates of change of the new, “digital” paradigm.
This was my greatest career accomplishment although, I must admit, it was never my conscious intent to create a great career accomplishment. It was simply accidental in the process of working day by day as the de facto “owner” of BSP. My 1987 IBM Systems Journal article, “The Framework for Information Systems Architecture”[1] was the most reproduced article in the IBM Systems Journal history and is a heavily referenced article, particularly by academia to this day, 35 years later.
[1] It was a grave mistake to name my Framework a “Framework for Information Systems Architecture” but when I would say “A Framework for Enterprise Architecture,” people would say, “a Framework for WHAT??” So I would say, “it’s kind-of like a Framework for Information Systems Architecture.” They would say, “oh yeah .. I kind-of get what you mean.” But I inadvertently contributed to the misunderstanding of Enterprise Architecture being conceived as an IT technology issue rather than an ENTRPRISE business issue.
What are the two or three biggest challenges you face as a data management professional / CDO and how can we address them?
Clearly, the paradigm problem is the biggest problem … The Industrial Age World View (“paradigm”) was that machines (technology) extends humanity’s ability to do work far beyond the employment of manual labor, whether that technology is airplanes, coffee pots, calculators, buildings, ships, or telephones. It is “better, faster, and cheaper” to use machines (automation) to replace the people doing the work manually. The end result of this worldview is a motivation to get the technology implemented as soon as possible because every minute the technology is not implemented, it is costing quality (better), time (faster), and money (cheaper). This motivation optimizes the implementation, the short-term proposition at the expense of the long-term proposition, preservation of asset valuation. This results in entropy, consumption of resources compensating for the disintegration, discontinuity, sacrifice of “integration,” ignoring the use of “standards,” reusability, separation of independent variables, design for change, etc., etc. This compensation for the lack of employing rigorous design principles is a classic case of entropy, the Second Law of Thermodynamics, consuming enterprise energy/resources contributing no value short of keeping the enterprise working. Over time, the entropy increases until, in the extreme, all the energy of the system is absorbed keeping the system working. No energy is left over to produce value into the external environment. By contributing no value, the reason for the system’s existence no longer exists.
I had a friend who said, “Tomorrow I’m going out to visit a company that is dead … they just don’t know it yet.” The Industrial Age World View must be replaced by the Information Age (Digital) World View just like the Industrial Age World View had to replace the Agricultural Age World View. The Information (Digital) Age Worldview is no longer employing technology to extend the work ability of humanity, but the technology is used to enhance humanity’s ability to THINK. The behavior of groups of people (enterprises) can be designed to be “integrated” for collaboration yet retain and enhance the facility for innovation … designing the ENTERPRISE to accommodate extreme complexity and escalating rates of change and be aligned with management’s intent to respond to the vagaries and uncertainties of the market.
It was the craftsmen of the Agricultural Age that resisted the Industrial Age and did not want to produce standard interchangeable parts! They wanted to produce custom products, characteristic of the previous, Agricultural Age Worldview. Similarly, the information technology folks don’t want to produce standard interchangeable components (data or code or other components), but want to produce custom implementations, characteristic of the previous, Industrial Age Worldview. The required compensation (entropy) for these custom implementations includes interfaces (API’s), data warehouses, “work-arounds,” MBAs with Excel spreadsheets, etc., etc. Furthermore, ignoring the cost-effectiveness of standard interchangeable data and reusability of its code in the name of getting the code to run is rapidly increasing the entropy, the compensation for the disorder and disintegration required to keep the implemented systems running.
The absence of Enterprise design requires create, read, update, and delete (CRUD) code for every custom, unique data element in the enterprise … potentially a massive amount of code to create and maintain. This raises the question, “How long can the enterprise continue to fund the custom replication of both data elements and their code with its creation of unintended consequences of change in an extremely dynamic marketplace?” How long can an Enterprise continue to support the escalation of entropy simply keeping the Enterprise in operation and still maintain its competitive and economic viability? Clearly, there is something wrong with an Application Development Methodology that perpetuates this expensive, implementation environment that is fraught with unintended consequences of change because of the indiscriminate replication of both data and code. So, what is data management to do? My suggestion is to continue to advocate optimization of the resources of the enterprise and elimination of entropy, the compensation for the adverse effects of optimizing implementations at the expense of resources.
I would also advocate fixing the Application Development Methodology … this is so simple! Build the data model FIRST, ensuring no replication of the attributes, and force the programmers to REUSE the standard, authorized, consistently named, formatted, and defined attributes (data elements), and also REUSE the data’s pre-built create, read, update and delete code written one single time. Populate every input/output (user view) with reusable data and reusable CRUD code. The “integration” problem is solved: indiscriminate replication of data and code eliminated, entropy eliminated, unintended consequences of change avoided, value of resources preserved, and Enterprise future costs controlled. These benefits far outweigh getting the code to run as soon as possible, the Worldview of the previous, Industrial Age, the World View for the LAST several hundred years. The Industrial Age World View (paradigm) of using technology to extend humanity’s ability to work, and from the IT perspective, to get the code running as soon as possible, has enormous inertia and is very difficult to change. This clearly is the biggest challenge to transitioning to the Information (digital) Age World View (paradigm) to extend Humanity’s ability to THINK and innovate, not simply to work.
How do you see data management / the role of the CDO / IT changing in the next 2 – 3 years?
Enterprise management actually does not manage the resources of the Enterprise directly … they manage the DATA about the resources, the surrogates for the actual resources. Therefore, I would see the evolution of an Executive Vice President of Enterprise Design and Implementation that would support general management in enterprise operations by creating and managing the descriptive representations (the data) that constitutes the design, the knowledge of the Enterprise. The enterprise design must accommodate the extreme complexity and extreme rate of change of the Information (digital) Age, while ensuring the Enterprise implementation is aligned with enterprise strategy. Because the enterprise design includes descriptive representations of the data surrogates for all enterprise resources, the Executive Vice President of Enterprise Design and Implementation would necessarily encompass, if not supplant all of the general managers of enterprise resources including Human Resources, Material, Money, Facilities, etc. The Executive Vice President of Enterprise Design and Implementation may alternatively be called the Executive Vice President of Enterprise Architecture … “architecture” being the set of descriptive representations that constitute enterprise design and implementation, the knowledgebase of the enterprise. The rhetorical question, “Who knows how the enterprise works … at the level of definition required to create it or change it?” Even for small enterprises, the answer is: NOBODY! As the sole proprietor of the enterprise “Zachman International,” I had no idea how it worked because I never expended the effort to formalize it and retain it in memory. However, if the Executive Vice President of Enterprise Engineering and Manufacturing (or the EVP of Enterprise Architecture) retained the descriptive representations of the enterprise design in a knowledgebase, he or she could have instantaneous access to the knowledge of how the enterprise works at the level of definition required to avoid the unintended consequences of change and to reconstruct the enterprise dynamically, that is, if the knowledgebase was composed of single-variable, ontologically-defined components for realizing “mass-customization.”
Who knows? … Whoever creates and manages the descriptive representations that constitute the design of the enterprise. He or she knows! I must insert a caveat: The Executive Vice President is not going to create all the models or manage the repository of models. Many engineering design specialists (modeling experts) will do the design work (similar to designing a Boeing 747 or a hundred story building or any complex engineering product). The EVP makes sure that the purity of the ontology (classification of the single-variable descriptive representations, i.e., models) is preserved and the implementations actually use (or, REuse) the contents of the knowledgebase of the enterprise design.
Do you have any planned next steps for your career?
Although at age 88, I still continue to do research-type work (somewhat less productively!), I am somewhat constrained from directly making contributions. My focus now is packaging and articulating an understanding of enterprise architecture from my 50 years of study for the next generation of advocates. Humanity is dependent on wisdom of probably a few vocal advocates and many skilled Enterprise Engineers. It will take knowledgeable leadership for making the transition into the future Information (digital) Age. The future is a worldview of enterprise design, design for complexity and change for collaboration and innovation. It is NOT “more of the same” implementing the technology as soon as possible! Enterprise design supplants getting the code to run as soon as possible as the motivation for employment of technology.
What is the single best piece of advice you have received in your data management / IT career so far? Why has it been so important to you?
Do not give up! We have a LOT to learn about designing and implementing (engineering and manufacturing) enterprises. We sorely need people who are competent and experienced in this essential discipline to lead us into the new paradigm worldview, the Information (digital) Age of enterprise design, employing technology to extend humanity’s ability to THINK, not simply to extend the capability to do work.
