Do you trust your doctor ?

We all unfortunately need to visit a doctor from time to time when we do not feel well. He examines us, he makes a diagnosis and prescribes medications. It rarely comes to our mind to ask him what is the active ingredient of the medication he prescribed to us or if he did well at school […]

Why new technology requires non technical orientated architects, but not Business Architects.

For a long time we have seen that a new set of technology is announced and when we are lucky we may actually see it in action decade later. Usually there are a lot of people talking of the potential and some that focus on prototyping it, but what is really always missing is not … Continue reading Why new technology requires non technical orientated architects, but not Business Architects.

Architecture for fun

Many architect miss the fact that architecture is not only done as source of income, but also as voluntary unpaid work. There are various architects in areas such as open source developments that often are superior in their core skills to the paid ones. Some of them are also architects that do architecture as a … Continue reading Architecture for fun

What is the Enterprise Lifecycle?

TOGAF doesn’t always provide a good explanation of important terms or phrases. One example is the Enterprise Life Cycle, which is referred to throughout TOGAF. This article – from Good e-Learning – explains why the phrase is useful, and what it means in the TOGAF context.

Related posts:

  1. What’s the Difference Between Scope and Partition? There are some things in TOGAF that confuse practitioners over…
  2. How well do you know TOGAF definitions? Here is a quick interactive quiz from Good e-Learning on…
  3. Building Blocks in Enterprise Architecture This article by Selvyn Wright provides a good explanation about…

Zachman Enterprise Engineering – Primitive vs. Composite Review

Primitives and Composites – What’s the Difference?

It is useful to discuss the differences between Primitives and Composites because this is the paradigmatic problem of the Information community of the day.

It is useful to discuss the differences between Primitives and Composites because this is the paradigmatic problem of the Information community of the day.

Primitives are single-variable, ontologically-defined categories of the essential components upon which the Enterprise is dependent for existence. Only one type of Enterprise component can be classified in any one cell of the Zachman Framework. They are the domain of Engineering, that is, Architecture. They don’t “do” anything. In contrast, Composites are multi-variable, holistic constructs of parts or pieces of the Enterprise with components from multiple categories of the essential components. Representation of different categories of components (different Framework Cells) are prerequisite for implementation. They are the domain of Manufacturing. They implement (“run”).

There is a strong metaphorical correlation between the Elements and Compounds of the Chemistry discipline and the Primitives and Composites of the Enterprise Architecture domain. Elements (Primitives) are timeless. Compounds (Composites) are temporal. Elements (Primitives) have single types of components. Compounds (Composites) have multiple types of components. Elements (Primitives) are isolated theoretically for engineering work. Compounds (Composites) are integrated practically for manufacturing work. Elements (Primitives) are Architecture. Compounds (Composites) are implementations. Elements (Primitives) are needed for Engineering. Compounds (Composites) are used by and the result of Manufacturing. Compounds (Composites) can be manufactured without knowing anything about or reusing the Elements (Primitives), but for Compounds to be engineered to produce predictable and/or modifiable behavior, they must be created from “reusable” Elements (Primitives).

This brings up a very important point. If you had inventories of all of the Chemical Elements in their primitive states, you could manufacture ANY Chemical Compound you wanted. However, as soon as you create the compound, it is fixed … it is hard to change. By the same token, if you had all of the Enterprise Primitives in inventory in their pure Primitive state, you could create any Enterprise Composite implementation required. Once you create the Composite, it is fixed, a snapshot, a point in time instantiation… an implementation.

There is a metaphorical departure in Enterprise Architecture from Chemistry in the fact that the media of the Enterprise implementation is the same as the media of its descriptive representations, namely digital depictions. We do not have to go through a media transformation from our engineering descriptions to become our implemented reality. They can both be digital. We simply “compile” the implementation. However, we learned long ago that the moment you “bind” together the components of the Composite implementation, it is fixed … you can’t change it. Therefore, the optimum implementation strategy would be to “bind at execute time” … that is, don’t “compile” the implementation until you “click your mouse” … “late binding.”

Unfortunately, “bind at execute time” is not presently perceived to be technically feasible. I think most people would argue that it is because the current technology does not support the concept. I would suggest that this is not a technical issue at all. The fundamental problem is, we do not have an inventory of our Primitive (elemental) components in their pure Primitive state from which we could bind Composites together at the click of the mouse. The key to this capability is Enterprise Architecture, the inventory of Primitive components, “loosely coupled,” related only by “foreign keys” in a database (Repository). If we had the inventory of Primitive Models in a Repository, the current technology would, in fact, support the concept. This capability in Manufacturing, Industrial Age products, is called “Mass-Customization:” “Custom Products, Mass-Produced, in Quantities of One, for Immediate Delivery.” This is REALLY important for Enterprises in the Information Age … because of the dramatic escalation of complexity and of the rate of change, the ENTERPRISE needs to be mass- produced from reusable components already “in inventory” in quantities of one for immediate instantiation … dynamically creating (late-binding) a new Enterprise implementation. This is the urgent motivation for ENTERPRISE ARCHITECTURE!!!

RBPEA: Constraints and corollaries

Enterprise-architectures should, in principle, apply to any enterprise, at any scale. But what happens when we scale our enterprise-architectures up to the ‘really-big-picture’ (RBPEA) level, with a literally global scope? What non-negotiable constraints would we hit up against? What corollaries would

The Strategic Staircase – Case Study

TOGAF doesn’t explain in much detail how you actually go about producing an Architecture Vision or Roadmap, and this can be particularly difficult if the future is uncertain or turbulent. This case study shows how one European telecoms company used the idea of a strategic staircase to supplement TOGAF. Read the full case study: https://www.goodelearning.com/downloads/enterprise-architecture/the-strategic-staircase-case-study?

Related posts:

  1. TOGAF Poster #43 – The Sandwich Diagram Knowing the seven parts of the TOGAF documentation is very…
  2. How well do you know TOGAF definitions? Here is a quick interactive quiz from Good e-Learning on…
  3. TOGAF 9 Poster #44 – TOGAF and ArchiMate TOGAF and ArchiMate are two standards managed by The Open…