Subscribe to the FREE Business Rules Journal Newletter


 

 

 

     ZACHMAN ARCHIVES ...
untitled

A Historical Look at Enterprise Architecture with John Zachman

an interview with John A. Zachman

John Zachman's Zachman Framework is widely recognized as the foundation and historical basis for Enterprise Architecture.  On Tuesday, Feb. 3, during The Open Group's San Diego 2015 event,[1] Zachman gave the morning's keynote address entitled "Zachman on the Zachman Framework and How it Complements TOGAF® and Other Frameworks."  The Open Group spoke to Zachman in advance of the event about the origins of his framework, the state of Enterprise Architecture, and the skills he believes EAs need today.

~ The Open Group

As a discipline, Enterprise Architecture is still fairly young.  It began getting traction in the mid to late 1980s after John Zachman published an article describing a framework for information systems architectures in the IBM Systems Journal.  Zachman said he lived to regret initially calling his framework "A Framework for Information Systems Architecture," instead of "Enterprise Architecture" because the framework actually has nothing to do with information systems.

Rather, he said, it was "A Framework for Enterprise Architecture."  But at the time of publication, the idea of Enterprise Architecture was such a foreign concept, Zachman said, that people didn't understand what it was.  Even so, the origins of his ontological framework were already almost 20 years old by the time he first published them.

In the late 1960s, Zachman was working as an account executive in the Marketing Division of IBM.  His account responsibility was working with the Atlantic Richfield Company (better known as ARCO).  In 1969, ARCO had just been newly formed out of the merger of three separate companies, Atlantic Refining out of Philadelphia and Richfield in California, which merged and then bought Sinclair Oil in New York in 1969.

"It was the biggest corporate merger in history at the time where they tried to integrate three separate companies into one company.  They were trying to deal with an enterprise integration issue, although they wouldn't have called it that at the time," Zachman said.

With three large companies to merge, ARCO needed help in figuring out how to do the integration.  When the client asked Zachman how they should handle such a daunting task, he said he'd try to get some help.  So he turned to a group within IBM called the Information Systems Control and Planning Group and the group's Director of Architecture, Dewey Walker, for guidance.

Historically, when computers were first used in commercial applications, there already were significant "Methods and Procedures" systems communities in most large organizations whose job was to formalize many manual systems in order to manage the organization, Zachman said.  When computers came on the scene, they were used to improve organizational productivity by replacing the people performing the organizations' processes.  However, because manual systems defined and codified organizational responsibilities, when management made changes within an organization, as they often did, it would render the computer systems obsolete, which required major redevelopment.

Zachman recalled Walker's observation that "organizational responsibilities" and "processes" were two different things.  As such, he believed systems should be designed to automate the process, not to encode the organizational responsibilities, because the process and the organization changed independently from one another.  By separating these two independent variables, management could change organizational responsibilities without affecting or changing existing systems or the organization.  Many years later, Jim Champy and Mike Hammer popularized this notion in their widely-read 1991 book, Reengineering the Corporation, Zachman said.

According to Zachman, Walker created a methodology for defining processes as entities separate from the organizational structure.  Walker came out to Los Angeles, where Zachman and ARCO were based, to help provide guidance on the merger.  Zachman recalls Walker telling him that the key to defining the systems for Enterprise purposes was in the data, not necessarily the process itself.  In other words, the data across the company needed to be normalized so that they could maintain visibility into the assets and structure of the enterprise.

"The secret to this whole thing lies in the coding and the classification of the data," Zachman recalled Walker saying.  Walker's methodology, he said, began by classifying data by its existence, not by its use.

Since all of this was happening well before anyone came up with the concept of data modeling, there were no data models from which to design their system.  "Data-oriented words were not yet in anyone's vocabulary," Zachman said.  Walker had difficulty articulating his concepts because the words he had at his disposal were inadequate, Zachman said.

Walker understood that to have structural control over the enterprise, they needed to look at both processes and data as independent variables, Zachman said.  That would provide the flexibility and knowledge base to accommodate escalating change.  This was critical, he said, because the system is the enterprise.  Therefore, creating an integrated structure of independent variables and maintaining visibility into that structure are crucial if you want to be able to manage and change it.  Otherwise, he says, the enterprise "disintegrates."

Although Zachman says Walker was "onto this stuff early on," Walker eventually left IBM, leaving Zachman with the methodology Walker had named "Business Systems Planning."  (Zachman said Walker knew that it wasn't just about the information systems, but about the business systems.)  According to Zachman, he inherited Walker's methodology because he'd been working closely with Walker.  "I was the only person that had any idea what Dewey was doing," he said.

What he was left with, Zachman says, was what today he would call a "Row 1 methodology" — or the "Executive Perspective" and the "Scope Contexts" in what would eventually become his ontology.

According to Zachman, Walker had figured out how to transcribe enterprise strategy in such a fashion that engineering work could be derived from it.  "What we didn't know how to do," Zachman said, "was to transform the strategy (Zachman Framework Row 1), which tends to be described at a somewhat abstract level of definition into the operating Enterprise (Row 6), which was comprised of very precise instructions (explicit or implicit) for behavior of people and/or machines."

Zachman said that they knew that "Architecture" had something to do with the Strategy-to-Instantiation transformation logic, but they didn't know what architecture for enterprises was in those days.  His radical idea was to ask someone who did architecture for things like buildings, airplanes, locomotives, computers, or battleships what the architecture was for those Industrial Age products.  Zachman believed if he could find out what they thought architecture was for those products, he might be able to figure out what architecture was for enterprises and thereby figure out how to transform the strategy into the operating enterprise to align the enterprise implementation with the strategy.

With this in mind, Zachman began reaching out to people in other disciplines to see how they put together things like buildings or airplanes.  He spoke to an architect friend and also to some of the aircraft manufacturers that were based in Southern California at the time.  He began gathering different engineering specs and studying them.

One day while he was sitting at his desk, Zachman said, he began sorting the design artifacts he'd collected for buildings and airplanes into piles.  Suddenly he noticed there was something similar in how the design patterns were described.

"Guess what?" he said.  "The way you describe buildings is identical to the way you describe airplanes, which turns out to be identical to the way you describe locomotives, which is identical to the way you describe computers.  Which is identical to the way you describe anything else that humanity has ever described."

Zachman says he really just "stumbled across" the way to describe the enterprise and attributes his discovery to providence, a miracle! Despite having kick-started the discipline of Enterprise Architecture with this recognition, Zachman claims he's "actually not very innovative," he said.

"I just saw the pattern and put enterprise names on it," he said.

Once he understood that Architectural design descriptions all used the same categories and patterns, he knew that he could also define Architecture for Enterprises.  All it would take would be to apply the enterprise vocabulary to the same pattern and structure of the descriptive representations of everything else.

"All I did was, I saw the pattern of the structure of the descriptive representations for airplanes, buildings, locomotives, and computers, and I put enterprise names on the same patterns," he says.  "Now you have the Zachman Framework, which basically is Architecture for Enterprises.  It is Architecture for every other object known to human kind."

Thus the Zachman Framework was born.

Ontology vs. Methodology

According to Zachman, what his Framework is ultimately intended for is describing a complex object, an Enterprise.  In that sense, the Zachman Framework is the ontology for Enterprise Architecture, he says.  What it doesn't do is tell you how to do Enterprise Architecture.

"Architecture is architecture is architecture.  My framework is just the definition and structure of the descriptive representation for enterprises," he said.

That's where methodologies, such as TOGAF®[2] (an Open Group standard), DoDAF, or other methodological frameworks come in.  To create and execute an Architecture, practitioners need both the ontology — to help them define, translate, and place structure around the enterprise descriptive representations — and they need a methodology to populate and implement it.  Both are needed — it's an AND situation, not an OR, he said.  The methodology simply needs to use (or reuse) the ontological constructs in creating the implementation instantiations in order for the enterprise to be "architected."

The Need for Architecture

Unfortunately, Zachman says, there are still a lot of companies today that don't understand the need to architect their enterprise.  Enterprise Architecture is simply not on the radar of general management in most places.

"It's not readily acknowledged on the general management agenda," Zachman said.

Instead, he says, most companies focus their efforts on building and running systems, not engineering the enterprise as a holistic unit.

"We haven't awakened to the concept of Enterprise Architecture," he says.  "The fundamental reason why is people think it takes too long and it costs too much.  That is a shibboleth — it doesn't take too long or cost too much if you know what you're doing and have an ontological construct."

Zachman believes many companies are particularly guilty of this type of thinking, which he attributes to a tendency to think that there isn't any work being done unless the code is up and running.  Never mind all the work it took to get that code up and running in the first place.

"Getting the code to run, I'm not arguing against that, but it ought to be in the context of the enterprise design.  If you're just providing code, you're going to get exactly what you have right now — code.  What does that have to do with management's intentions or the Enterprise in its entirety?"

As such, Zachman compares today's enterprises to log cabins rather than skyscrapers. Many organizations have not gotten beyond that "primitive" stage, he says, because they haven't been engineered to be integrated or changed.

According to Zachman, the perception that Enterprise Architecture[3] is too costly and time consuming must change.  And, people also need to stop thinking that Enterprise Architecture belongs solely under the domain of IT.

"Enterprise Architecture is not about building IT models.  It's about solving general management problems," he said.  "If we change that perception, and we start with the problem and we figure out how to solve that problem, and then, oh by the way we're doing Architecture, then we're going to get a lot of Architecture work done."

Zachman believes one way to do this is to build out the Enterprise Architecture iteratively and incrementally.  By tackling one problem at a time, he says, general management may not even need to know whether you're doing Enterprise Architecture or not, as long as their problem is being solved.  The governance system controls the architectural coherence and integration of the increments.  He expects that EA will trend in that direction over the next few years.

"We're learning much better how to derive immediate value without having the whole enterprise engineered.  If we can derive immediate value, that dispels the shibboleth — the misperception that architecture takes too long and costs too much.  That's the way to eliminate the obstacles for Enterprise Architecture."

As far as the skills needed to do EA into the future, Zachman believes that enterprises will eventually need to have multiple types of architects with different skill sets to make sure everything is aligned.  He speculates that, someday, there may need to be specialists for every cell in the framework, saying that there is potentially room for a lot of specialization and people with different skill sets and a lot of creativity, just as aircraft manufacturers need a variety of engineers — from aeronautic to hydraulic and everywhere in between — to get a plane built.  One engineer does not engineer the entire airplane or a hundred-story building or an ocean liner, or, for that matter, a personal computer.  Similarly, increasingly-complex enterprises will likely need multiple types of engineering specialties.  No one person knows everything.

"Enterprises are far more complex than 747s.  In fact, an enterprise doesn't have to be very big before it gets really complex," he said.  "As enterprise systems increase in size, there is increased potential for failure if they aren't architected to respond to that growth.  And if they fail, the lives and livelihoods of hundreds of thousands of people can be affected, particularly if it's a public-sector Enterprise."

Zachman believes it may ultimately take a generation or two for companies to understand the need to better architect the way they run.  As things are today, he says, the paradigm of the "system process first" Industrial Age is still too ingrained in how systems are created.  He believes it will be awhile before that paradigm shifts to a more Information-Age-centric way of thinking where the enterprise is the object rather than the system.

"Although this afternoon is not too early to start working on it, it is likely that it will be the next generation that will make Enterprise Architecture an essential way of life like it is for buildings and airplanes and automobiles and every other complex object," he said.

This article can also be viewed on John's website — presented here, with permission.

References

[1]  The Open Group, "Enabling Boundaryless Information Flow — Empowering Your Business."  Visit http://opengroup.org/sandiego2015  return to article

[2]  TOGAF®, at http://www.opengroup.org/subjectareas/enterprise/togaf  return to article

[3]  The Open Group, "Enterprise Architecture," at http://www.opengroup.org/subjectareas/enterprise  return to article



standard citation for this article:
John A. Zachman Interview, "A Historical Look at Enterprise Architecture with John Zachman," Business Rules Journal, Vol. 16, No. 9 (Sep. 2015), URL:  http://www.BRCommunity.com/a2015/b828.html  

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 ]