How was Training?

more

“I am full of theory.” - Senior consultant, AutoCont, Czech Republic, Mar 2011

Recommend PEAF?

more

“Yes - Enterprise architecture has to be a practical and tangible road map. It moves us beyond theory and provides a framework to define both skill and implementation strategy.” - Enterprise Architect, Next Generation, Inc., A Deloitte Technology Partner, USA, Jan 2015



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 Deployment).

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:

1)    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.

2)    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 thing of the primitives as tables in a database and the models as SQL statements (or views) into those tables.

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 mean 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.”

 

 

◄◄◄ Previous Page          

          Next Page ►►►







 

© 2008-2016 Pragmatic EA Ltd