Although Enterprise Architecture is only a part of the
entire Transformation domain, we mention Zachman here because whilst the
Zachman Ontology is known as an Enterprise Architecture Ontology, and whilst
John A. Zachman is deemed to be “The Father of Enterprise Architecture”, it
does in fact cover the whole Transformation domain (from Strategy to
It is, in fact, an Enterprise Transformation Ontology where
the top half covers Enterprise Architecture and the bottom half covers
Enterprise Engineering (although the engineering part is IT focussed).
John A. Zachman is therefore “The Father of Enterprise
Architecture” and “The Father of Enterprise Engineering”
The basic message contained in Zachman is that “You cannot
change what you cannot see” and therefore is one of modelling and models -
Architectural Models and Engineering Models.
POET and PEAF are built on the following conceptual ideas
from the Zachman 6x6 grid:
Vertically - There are phases of Transformation that we need to consider
- from the highest view of Enterprise Strategy to the physical deployment of
change - and these phases must cover ALL the
transformations we need to do to bridge that gap.
Horizontally - There are data used by each phase of transformation -
that should be categorised - and these categorisations must cover ALL of the data we need for that phase.
Zachman teaches (quite correctly) that “If you want to
transform a complex Enterprise in a volatile environment, you have to a) Model
(not draw) the Enterprise, b) Persist Models as Primitives.”
Modelling (not drawing) the enterprise means you need to
make a distinction between drawings (which cannot be analysed or used in
anyway) and models (which can be analysed and used in a multitude of ways) and
therefore visual representations of things need a structured base.
Persisting models as primitives means that each element in a
model should be stored as separate elements, which are then brought together to
create one or more models.
If you are an IT person, you can think of the primitives as
tables in a database and the models as SQL statements (or views) into those
The other statements on this graphic relate to additional
fundamental things that Zachman should explain but actually incorrectly explains
the exact opposite.
Firstly, Pragmatic teaches us to “Use Ontologies
appropriately”. This means that an ontology should be used to create metamodels,
which should be used to create models. Zachman incorrectly teaches people to
create models based on the Zachman ontology (since he doesn’t have a metamodel),
instead of teaching people to create (and validate) metamodels on that
ontology. This is because people want to create models and so since he only has
an ontology, that is what is used.
Secondly, Pragmatic teaches us to “Use Architecture and
Engineering appropriately”. This means that Architecture and Engineering are closely
related but totally different things. Confusing architecture and engineering
and architects with engineers probably creates more problems in Enterprises
than everything else put together. Can you imagine what would happen if you
asked an Engineer to Architect a building or an Architect to Engineer it? When
Zachman was asked in a classroom (not by me) to clarify what he meant by architecture
and engineering (because he had been using those words a lot and it wasn’t
clear what he meant by them) Zachman replied “Oh well, some people say
architecture, some people say engineering. They are the same thing really and I
use the words interchangeably.”