We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Enterprise Architecture Matters

Adrian Grigoriu

Zachman's is a process rather than a framework or an ontology

Vote 0 Votes
I would like to launch a challenge  with regard to Zachman's table by saying that it is neither an ontology nor a framework, as it was often said, but a good old system development process.

Whatis.com states that "an ontology is the working model of entities and interactions in some particular domain of knowledge or practices."
In which case, an ontology sounds more like a metamodel, which Zachman is not.

 In Zachman's table the interactions between the elements/cells that would define an ontology are missing.
Furthermore, the cells are not entities in the EA domain of practice since the matrix is neither enterprise nor architecture specific. It can apply to any system. And solely one row is in fact, about architecture. The cells are artifacts themselves, composites of such entities.

As such, Zachman's is not an ontology because it describes neither the entities of the knowledge domain nor their relationships.

Zachman' s is not a framework either.

Here is what Whatis.com writes about frameworks:

"A framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful"

Hence, Zachman's is not a framework because it does not represent the structure of the enterprise or its architecture. Putting the artifacts in cells, back in the "framework", does not constitute an integrated EA but still a table of disjoint set of enterprise representations.

Zachman's is a simple veiled process though. The vertical dimension describes the system development process beginning with objectives establishment and concept design and ending with Implementation.

The process is described by either deliverables (the business model, the logical, physical...) and/or by phase owners (planner, business owner, architect, designer...) rather than by process phases.

Were we to describe the process the following phases would be evidenced: objectives specification (row 1), concept definition (row 2), logical design (row 3), technology design (row 4), implementation (row 5) (and eventually utilisation (row 6) or I would say deployment).

It is uncommon too that each phase is executed by a different participant or firm. The process would be often executed end-to-end by the same entity. In this case repeating questions like why, who... etc for each phase of the development makes little sense. Why should one ask the why question again and again, once the business case for the development has been already established in a previous phase? 

To sum up, Zachman's looks to me like a straightforward system development process specified on the vertical dimension of the matrix by its deliverables and/or owners of the phase. 

The "w" questions that help justify and qualify the activities in each phase, make  sense once only for the whole development process, rather than repeated for each phase, at least because the owner of the phase does not change.

In any case, the EA architect is not responsible or accountable for all the activities in phases. Take for instance the planer's, the contractors' rows... But the architect should be clearly in charge of the architecture, logical/system phase (=row).

You cannot track an end-to-end process in Zachman's table. You cannot navigate to the resources that implement it.

I solely use Zachman's to market EA to top management who needs to ask questions like why, who...  at each phase of a major development. That is because they have responsibility for the whole outcome to ensure that it is fit for purpose, delivered in time by participants and resourced accordingly. 


| Leave a comment

I find your reasoning a bit opaque. It sounds as if you attempt to apply the definitions from Whatis on the similarities between enterprises and the Zachman model. However what Zachman is trying to help with, with what I would call a framework, is not modelling enterprises, but enterprise *architecture*. As such it seems to me it complies with the definition perfectly.
The same reasoning leads me to conclude that the model is also an ontology.
What are your thoughts?

I take it you disagree with Whatis.com. If you would bother to define framework and ontology or at least search the web for other definitions you would still come with similar.

The result of modeling an Enterprise is an EA.
True Zachman's does not help at modeling the enterprise. For that try GODS-FFLV. It is just a common system development process (on the vertical dimension) specifying phase deliverables that answer questions like what, how...
Only the architecture phase (row) is owned by an EA architect. Zachman does not tell you how to produce the deliverables or how do they integrate in a navigable architecture whole.
You cannot track an end-to-end process in Zachman's table. You cannot navigate to the resources that implement it.

Zachman's cannot be a framework and ontology at the same time. It could be either one or the other. It is none, it is a process as I said.

Leave a comment

Adrian Grigoriu blogs about everything relating to enterprise and business architecture, SOA, frameworks, design, planning, execution, organization and related issues.

Adrian Grigoriu

Adrian is an executive consultant in enterprise architecture, former head of enterprise architecture at Ofcom, the spectrum and broadcasting U.K. regulatory agency and chief architect at TM Forum, an organization providing a reference integrated business architecture framework, best practices and standards for the telecommunications and digital media industries. He also was a high technology, enterprise architecture and strategy senior manager at Accenture and Vodafone, and a principal consultant and lead architect at Qantas, Logica, Lucent Bell Labs and Nokia. He is the author of two books on enterprise architecture development available on Kindle and published articles with BPTrends, the Microsoft Architecture Journal and the EI magazine. Shortlisted by Computer Weekly for the IT Industry blogger of the year 2011.

Recently Commented On

Monthly Archives