Information Security: 7 communication tips to involve your business

Sharing knowledge and good practices is one of the core values of BiZZdesign. We regularly organize and contribute to online and offline seminars, conferences and round tables. Recently there was a very successful seminar on Enterprise Risk and Security Architecture for Dutch financial institutions. After presentations on “Security is not an IT problem” and the lacking relations between policies and measures in many organizations, we had a World Café on various topics. After reading this blog we would like you to your best and worst practices by reacting to this blog.  

Capitalizing on Complexity and Uncertainty

Darren Dalcher, one of my colleagues at Cutter Consortium, has written an Advisor about “The Third Knowledge Revolution: Learning to Live with Uncertainty” (Cutter login required) that has a lot of relevance to enterprise architects. My experience, research and client work shows that knowledge is one of eight fundamental factors that we need to include in EA…

Related posts:

  1. Crystal Ball Time Each year, Anne Mullaney, sets a challenge to the Cutter consultants:…
  2. Managing Complexity with Enterprise Architecture Mike Rosen has written an interesting article about complexity and…
  3. EA Myths Four myths that hide the true value from Enterprise Architecture!I…

The Inventory Model

This model is part of my toolbox for working with business architectures. The Inventory Model   The important thing to remember is to be agile minded in use of tools like this. So, when I say extendable I mean that this is definitely not all things that could or should be in the inventory. Reconfigure it in […]

The Inventory Model

This model is part of my toolbox for working with business architectures. The Inventory Model   The important thing to remember is to be agile minded in use of tools like this. So, when I say extendable I mean that this is definitely not all things that could or should be in the inventory. Reconfigure it in […]

EA Manufacturing versus Engineering

Manufacturing descriptive representations are holistic descriptions of individual parts such that the part (system) can be manufactured quite independently of the entirety of the Enterprise. The description of the part must be complete, “holistic,” because any characteristic that is requisite to the existence of the part, if not made explicit, is potentially defective. That is, any characteristic not made explicit is implicit and therefore, assumptions are being made which may be right … or may be wrong. Erroneous assumptions are the sources of defects.

Manufacturing descriptive representations can conveniently be classified in ONE dimension; a taxonomy, a hierarchy, a decomposition, which is, reductionism, (“analysis”). It is convenient for manufacturing to reduce the size of the parts through decomposition because the smaller the part, the less costly and more quickly each part can be manufactured. However, the smaller the implemented parts (systems) the more potential disintegration of the Enterprise as a whole.

Engineering descriptions are the converse of manufacturing descriptions. They are descriptive of the whole object, partitioned not by reduction but by intrinsic characteristic. The engineering descriptions are classified in a TWO dimensional structure, a schema, an ontology, such that the whole object is depicted in the context of each single, intrinsic characteristic. The descriptive classifications for engineering employment are “normalized” … “one fact in one place.” This is important for engineering so that redundancies, potential discontinuities, inconsistencies, incompatibilities, erroneous assumptions are identified and eliminated and therefore, every relevant characteristic is “integrated” in the context of the whole Enterprise (“synthesis”). In this fashion, if the implemented parts reuse components having characteristics that are integrated in the context of the whole Enterprise, the parts (systems), when implemented, will fit together, that is, the Enterprise will be “architected.”

See figure above for a comparison of Manufacturing Work and Engineering Work.

engineering v manufacturing

This engineering : manufacturing dichotomy can be seen the older disciplines. In Chemistry, the Chemical Engineering work is scientific, theoretical, focused on the single-variable theoretical elements as defined in the ontological structure of the Periodic Table. Chemical Manufacturing work is pragmatic, focused on assembling chemical products from multi-variable, holistic (in their own right) compounds (parts) that exist in nature or that can be created experientially. If no Chemical Engineering is done, alchemists can manufacture chemical products from compounds (parts) only if, by chance, the compounds (parts) “fit together,” that is, if they will “integrate.” Since the alchemists’ work is pragmatic, experiential, not theoretical, all progress is made by time-consuming, trial and error, (“best practices”) which severely limits the complexity and alacrity of the end results.

This can be seen in engineering and manufacturing of electrical and mechanical products as well. The engineering artifacts are descriptive of the whole object in the context of each single, intrinsic characteristic of the object. The manufacturing artifacts are descriptive of the total set of characteristics required for the implementation of a single “part” of the object.

I happened to discover the ontological classification of the Engineering Design Artifacts of an Enterprise, the “Zachman Framework,” by observing this pattern of descriptive representations in Architecture and Construction (buildings), and in Engineering and Manufacturing (airplanes, computers, ships, automobiles, etc.). I have written numerous articles and made a myriad of presentations about this experience and about the logic of the Framework for Enterprise Architecture, the Enterprise Ontology, the “Zachman Framework”.

Author

John A. Zachman

Who put the “Enterprise” in Architecture?

Enterprise Architecture is a commonly accepted label, used around the world by Enterprise Architects, and yet the meaning of the term continues to provoke debate. “Architecture” – on its own – is not confusing a term. Although some definitions narrow it to buildings, I prefer a more open definition which includes Enterprise Architecture, such as this: “[architecture…

Related posts:

  1. What’s wrong with IFW? I created Information FrameWork (IFW) as an architecture framework –…
  2. An Interview with John Zachman In January 2015, the Open Group published an interview giving…
  3. Zachman Version 3.0 John Zachman recently announced a new version of his framework….