When Andre de la Harpe asked me if I would be interested in having dinner with John Zachman, it wasn't a question. Even if I had the option of having a discussion with a) Nelson Mandela b) Barak Obama or c) the Dalai Lama, I would still have opted to have dinner with John Zachman. And I may sound like a giddy teenager at a concert but please bear with me as I provide some context.

Roderick Lim Banda, John Zachman, Prof Johannes Cronje, Andre de la Harpe, Rheta de la Harpe

Knowledge connects us to other people, especially if we acknowledge that much of what we know is acquired from others and to whom we are indebted. We all have some fundamental questions about life and wonder what shapes our thinking. When we connect the things we learn from others and are able to process this in such a way that it helps us to understand who we are, shapes our beliefs and our personal decisions in life, then our indebtedness is beyond measure. While there are many books that I have read and many authors and individuals from whom I have learnt, if there were two people on this planet that I would most like to have a conversation with, and to whom I feel most indebted to (other than my parents), it would be John Zachman and Christopher Alexander.

Every enterprise has an architecture. John Zachman decomposed the modern enterprise into its primary elements and structure using a matrix and technique that is centuries old and has helped us to deal with complexity by breaking things down. The Zachman Frameworks provided the model, ontology and information classification from which the discipline of Enterprise Architecture was founded. As a follower of modernist thinking and in particular, Walter Gropius and the Bauhaus Movement of the early 1900s, the Zachman Frameworks was something I could relate to, along with the discipline of enterprise architecture. And like many Enterprise Architects today who owe their profession to John Zachman, I continue to regard Enterprise Architecture as a non-IT discipline rooted in a body of work that at the time had nothing to do with IT but with enabling the implementation of strategy in an enterprise.

Christopher Alexander on the other hand was a building architect who studied patterns in cultural societies, building design and nature to better understand what represents "good" architecture. His method of the "pattern form" was adopted by software development methodologists in the establishment of a set of object orientated software patterns. The discipline of Software Architecture emerged from the work on software patterns, object orientated analysis and design methodologies and their visual modelling techniques. I was in awe of Christopher Alexander's work including "The Nature of Order" and began taking an interest in books such as David Pearson's "Earth and Spirit: In pursuit of Natural Architecture". Having previously dismissed eXtreme Programming, I began to re-discover the Agile movement and more human-centric approaches.

John Zachman's fathering of Enterprise Architecture and Christopher Alexander's contribution towards the establishment of Software Architecture, could in themselves be sufficient reason for any practicing Enterprise and Software Architect such as myself to be humbled by their work. But in my study and comparison of their techniques, I transitioned from a modernist architect to a postmodernist systems thinker seeking natural and organic patterns as references for architecture-intensive-disciplines. While both have relevance in our postmodern world, understanding their similarities and differences are key to seeing the evolving social pre-occupation and future not only of our emerging professions but also of a world driven by technological change.

First Impression

My first impression of Johan Zachman as he entered the restaurant with Professor Johannes Cronje, Dean of the School of Informatics and Design at the Cape Peninsula University of Technology (CPUT), was that he seemed like a very humble and an unassuming individual. He was relaxed and seemed perfectly at home in the company of intellectuals and academics. On his left was Prof Cronje who sat across from his wife Francine. Dr Andre and Rheta de la Harpe, also of CPUT, sat to his left. I across him. And Dr Alta van der Merwe from the Meraka Institute who had arranged the meeting was in Pretoria but was in touch through text messaging. It seemed from our seating arrangement that we had surrounded our revered guest. I was simply thankful that over the last few years I was invited to guest lecture on EA at CPUT and was given this opportunity.

Caring for Enterprise Assets

The first insight from John that evening for me was that we needed to care more about the so-called "intangible assets" in our enterprise, our intellectual capital, our people and our systems. This was in response to Andre's first question regarding Enterprise Architecture. He asked what were the 3 most difficult challenges in introducing enterprise architecture, to which John elaborated on the difficulties with executives, senior and middle management and then information technology professionals.

Chief Executive Officers (CEOs) and Chief Financial Officers (CFOs) firstly have to concern themselves with the financial health of the organization and hence it becomes an issue of survival. Executives need to understand and care for the intangibles and their assets and learn to see this as critical to the survival of the company. I could relate to this and personally respect and understand the importance of sound financial principles in the management of the enterprise. But it struck me that John used the word "care", that there must be a sense of emotion, investment, nurturing and true appreciation for the value of the human, organizational, intellectual and information capital. The singular profit driven dimension of many modern enterprises or the dominance of the financial perspective no longer adds up. This is not how we should measure and visualize a sustainable enterprise.

Enterprise Architecture was not about IT

As he spoke it was as if we were gathered around a camp fire and he related stories rather than answering questions. As he dealt with the challenges of establishing enterprise architecture in relation to management and information technology staff, it was clear that the conception of the Zachman Frameworks and EA in the early 1980s preceeded databases and IT terminology and concepts which we became familiar with in the late 1980s and 1990s. Clearly, EA was not about IT and this also became more apparent as he recounted how IBM was wanting to develop the Zachman Frameworks as methodology to which he was adamant that it was an ontology or way of classifying information much like the periodic table.

The Framework is proven, "centuries old" and is about description

John is passionate about the "Frameworks" and is not too bothered if people are critical of it. His view is that it exists and whether we like it or not an enterprise has an architecture and the framework describes it. He says it is based on tried and tested methods used to ensure the description of parts in engineering, including complex objects like the 747 "Jumbo" plane. The matrix structure as a model and technique is based on a practice that is centuries old. It reminded me of the renaissance painters who would use a wooden frame with strings running vertically and horizontally to break up a complex landscape into smaller rectangles or squares that the artist could decompose and detail.

Placing emphasis on description, he tells us the story of how he developed his EA Framework. The representation of the columns in particular is important and can provide examples of how each provides insight into the relevant and primary elements of an enterprise. The rows were initially based on roles as patterns emerged from the activities and interactions of owners, contractors and sub contractors in building architecture and engineering practices. But he gradually realized that the rows best represented layers of abstraction - contextual, conceptual, logical and physical - from the common set of artifacts in a building or engineering project. As he worked with architects and engineers, he noticed the pattern of bill of materials, schedules, etc. While initially the wording of the columns were strategy, process, people, etc. he recognized the need to re-define the columns into the now familiar - What, How, Where, Who, When and Why.

EA as a concern about strategy

What was John's pre-occupation that led him to be concerned about developing the framework? John's focus was on business strategy and he regarded himself not as an architect but as a strategist and planner. Enterprise Architects often have this debate about whether EA is and should be about Information Technology (IT). Many EA professionals do not regard themselves as IT professionals and John's own position supports this. John was quick to point out that this took place long before many of the things we deal with even existed. At the time, it was not even focusing on many of the technologies that were emerging and later emerged out of IT. The classification of elements that made up the enterprise was based on artefacts of business, their documents, goals and objectives, processes, organizational structures, people and roles, activities, equipment and infrastructure.

Why it is relevant for the African enterprise

When I asked whether he felt the frameworks could apply to an African enterprise or to our local context and whether the fact that it was descriptive of a western and modern enterprise made it less relevant, he told a story about his son's experience in his smaller business. John believes that the framework applies to all scales of an enterprise and to just about any form of business model or global environment and condition. The way business operates is to a large extent based on a generic system and that the structures of an enterprise and its primary elements are fundamentally the same. He took elements of the frameworks and illustrated how his son had applied this in the context of his smaller business enterprise and how much of the things that needed to be addressed did not differ much from a larger enterprise. Listing, describing and understanding the things that are important to a business such as its products and customers are relevant to any enterprise.

On Why Academics are failing

John was very keen on this opportunity to engage with academics and to openly converse on why he felt academics are failing. I truly sensed and related to his passion to make things work between academia and industry. He acknowledged the fact that there are different concerns and focus but was concerned about the inability of universities to adapt quickly enough and the challenge to remain relevant in the context of the rate of change in business and technology. I was particularly pleased that he saw the need for universities to incorporate EA in their program and the way he reasoned on its relevance. This was a genuine appeal to acknowledge and support the knowledge that is intrinsic in this discipline and the evolving body of knowledge of EA as a practice and discipline.

John Zachman has a great sense of humour and we were all laughing at how he related his surprise when it was pointed out to him that "the transformation of abstract ideas into models" was known as "reification". It is this humbleness about his own learning and his disposition to listen and engage in conversation that truly stands out for me. His intent was not to conceive of something that would be the next big thing. He is from an era before IT and the internet spawned billionaires. It brings the meaning of what we regard as the academic pursuit of knowledge and this discipline of Enterprise Architecture - back down to earth. That ultimately like all other things in life, it is about people and relationships. For that reminder, it was one of the most rewarding dinners of my life.