Stepping back from the current concerns with enterprise architectures, it is only fair to say that the IT people really began what has evolved into the current interest in architectures of all kinds. The earliest systematic use of the term “architecture” that is known of was in an article written by John Zachman, an IBM researcher, that appeared in the IBM Journal in 1987. The article was entitled, “A Framework for Information Systems Architecture,” and described how one could apply the concepts that building architects used to arrive at a number of perspectives that would help software engineers understand their own constructs.
A key idea was that an overall architecture was made up of a number of other architectures (LOBs) that were focused on different, specific areas of concern. Thus, the building architect created one diagram that he or she showed to the prospective buyers to give them an overview of what the finished product would look like.
Another blueprint was more detailed and described the rooms (using the analogy of building a house) within the structure, showing where the doors and windows would be, and so forth. Still more detailed views were created for the people who would actually build the infrastructure, while others were created for electricians, plumbers, and those who would finish the interior.
Zachman created a matrix that has six rows and three columns.
- The top row describes the Scope or overall context and is concerned with things a planner might consider.
- The second row describes a Business Model and is focused on things that might concern a business manager.
- The third row is focused on the System Model and is concerned with the logical elements that might interest a software designer.
The original Zachman framework was focused on Data, Functions, and Networks, and was properly identified as an “Information Systems Architecture.” In the past decade, Zachman has continued to expand his matrix. He has added three columns, People, Time, and Motivation, and has started calling it an Enterprise Architecture.
IT folks have a long tradition of using the term enterprise to refer to company-wide systems. Thus, Enterprise Applications originally referred to systems like accounting, payroll, and bookkeeping that were run on mainframes, maintained in central locations, and used to maintain a company’s accounts and generate all the paychecks.
Similarly, large companies have used layered diagrams to represent how their products can be arranged into a comprehensive IT solution, and, in the past few years, they have frequently referred to these comprehensive collections of products as an architecture.
If you view the Zachman framework, you’ll see that some of the cells within the matrix are described as architectures.
There are Application Architectures, Data Architectures, Human Interface Architectures and Network Architectures, among others. By the time Zachman completed the first version of this framework, he was convinced that he had identified all of the kinds of data that a company needed to keep track of, and, thus, the framework describes a kind of architecture of architectures. At the same time, the term “enterprise architecture” had become popular as a way of talking about all of architectures a company might need, and thus, the latest version of Zachman’s Framework has been termed an Enterprise Architecture.
Some would argue that Zachman’s Framework provides a comprehensive description equivalent to our use of the term Process-Centric Enterprise Architecture. A quick examination of the Zachman Framework, however, will suggest that business processes are not central to Zachman’s conception.
There is a lot of interest currently in the Zachman Framework. Some companies claim to use the Framework to organize their corporate data, and it is often cited as an example of an enterprise architecture.