I recently commented on Philip Allega’s blog. Phil understands that enterprise architecture (EA) programs must be more than buzzwords, and his post made me revisit one of the EA-disciplines grand old men, John Zachman.
According to John Zachman, EA is a mechanism “for defining and controlling the interfaces and integration of all of the components of the system” (Zachman, 1989). There are different architecture disciplines like software architectures, hardware architectures, network architectures and system architectures that confuse the meaning of “architecture”. While, for example software architecture describes the layout of the software modules and the connections and relationships among them, hardware architecture can describe how the hardware components are organized.
Part of the buzz-problem that Phil also describes is that the term “architecture” can have a range of meanings, goals, and abstraction levels, depending on the discipline speaking about it. For Zachman EA reflected a fundamental need to impose better management structures on system development. He was inspired by the millennial disciplines of classical architecture and the more recent development of the disciplines and methods in IE successfully adopted for the creation, design, and production of complex machine systems such as airplanes. In his first article from 1987 he observed that a great deal can be learned by observing how the expert practitioners of large edifices or machines go about their work. The framework that Zachman developed explicitly recognized the stylized roles played by key actors (e.g., owners and users) in the creation of buildings and aircraft, how they are involved in the related processes, and their unique informational needs and contributions.
Keep It Simple!
With time it has become more and more evident that creating integration and interoperability in an enterprise has more facets than just technology (i.e. the large body of literature on implementation). Obviously, having an integrated telephone network is not a sufficient condition for intelligible communication between remote sources, while the introduction of technology for local employee decision making seems pointless in an organizational context where decision making is seen as a management prerogative. Making technology work thus requires a wider perspective than technology alone, whereby contextual aspects are included in the design perspective such that the organizational context and technology are optimally matched and integrated. Many failed introductions of technology and related systems prove the importance of this notion!
In my opinion, the Zachman framework is not an architecture and was never proposed as such. It can be thought of as a multidimensional visual checklist. There is no guidance on sequence, process, or implementation of the framework. The artifacts that instantiate the cells of the framework for a given architecture are indeed architectures or subsets of an architecture, depending on one’s point of view. The framework depicts the design artifacts that constitute the intersection between the roles in the design process and the product abstractions. The large number of cells can be an obstacle for the practical application of the framework and the relationship between the different cells is not well specified.
So, take what you need from the Zachman and forget about the buzz. As noted previously on this blog, I have championed the introduction of EA reference models in Denmark. And we are working on other tools for national IT-portfolio planning, e.g. via business cases. Adoption is difficult, but if we apply EA with a natural scepticism and keep it simple we might succeed…