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.

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

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

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

# # #