Architecture and Reality

There are various confusing notions of "real" and "reality" circulating in the enterprise architecture world.

1. The idea that business people are only interested in things that are real.

2. The idea that architectural models represent some form of reality.

3. The idea that data contained in a computer represents some form of reality.

4. The idea that the data contained in a computer is itself a higher form of reality.

5. The idea that one artefact can be a realization of another artefact.

6. The idea that artefacts can be arranged along a realization dimension - some artefacts are more or less real/realized than others. For example, a physical data model is supposedly more real/realized than the logical data model.

Now you could believe some of these, but I don't see how anyone could believe all of them at the same time, without fracturing the concept of reality.

Here are some posts that cover some aspects of this.

Faithful Representation, Faithful Representation 2 (Aug 2008) - on the fallacy of regarding a system as a faithful representation of the real world. Among other things, I argue that the problem of knowledge and uncertainty fundamentally disrupts our conventional assumptions about representation, in much the same way that quantum physics disrupts our assumptions about reality. This led to a further series of posts, offering several examples. Responding to Uncertainty, Responding to Uncertainty 2, Analyzing the Rusty Lawnmower (Aug-Sept 2008). 

Architecture and the Imagination (Oct 2012) - on how architects need to think about things that don't yet exist.

From AS-IS to TO-BE (Oct 2012) - three alternative ways of interpreting the notion of realization. See also Deconstructing the Grammar of Business (June 2009), on the correct meaning of "reification".

From AS-IS to TO-BE

Architects produce many types of models. One useful distinction is between AS-IS models (which describe the current situation) and TO-BE models (which describe some projected future situation). If we can compare an AS-IS model with a TO-BE model, we can identify and quantify the differences (known as Gap Analysis) and work out a route from AS-IS to TO-BE (known as Roadmap). See my post on Value of Models (Sept 2010).

If we wish to compare AS-IS with TO-BE, it is a good idea for them to be similar in as many ways as possible. For example, same viewpoint, same scope, same level of granularity, same terminology and notation.

But despite all that, they differ in meaning. We might be tempted to say that the AS-IS model describes something real, while the TO-BE model describes something imaginary. This would be why we have to apply different validation criteria: for the AS-IS model to be valid, it must correspond to our observations of the actual system (warts and all), whereas the TO-BE model is valid, it merely has to be consistent with other descriptions, such as descriptions of user goals and requirements

A model may start life as a TO-BE model - describing some desired future system. At some point in the history of this model, the system it describes becomes operational, and the model now becomes an AS-IS model. In which case, we might want to regard "TO-BE" and "AS-IS" as roles or phases in the life of a model, rather than permanent characteristics of a given model.

(If for some reason we wanted to create an exact replica of an existing system, then the AS-IS model might become a TO-BE model.)

The TO-BE model describes an imaginary system, and at some moment in time, the imaginary system turns into a real system: so we might call this the moment of realisation. It might make sense to regard "realisation" as an event in the life history of a model, when the model turns from a TO-BE model into an AS-IS model. It may also be an event in the life history of a system, as it goes from "imaginary" or "planned" to "real" and "operational".

Of course it's not always as simple as this. On many projects the first release of the system only implements part of the architecture. So we could have a model where half of it has been realised (now AS-IS) and half not (remaining TO-BE).

But there are two rival notions of realization to be found in the popular architecture frameworks, which seem to be mutually incompatible.

• Sometimes realization seems to be an association between two different artefacts - for example, the system being a realization of the model.

• And sometimes realization seems to be a quality that may be possessed by different artefacts to different degrees.- for example the physical data model might be "more realised" than the logical data model. The architecture frameworks are commonly presented using diagrams with a vertical arrow showing that realization increases progressively from top to bottom. (To make matters even more confusing, Zachman labels this arrow "reification".) The reverse arrow is called "idealization".

Each of these notions of realization seems to imply a different notion of reality. I am particularly sceptical of the notion of reality implied by the third notion of realization, apparently dividing some universe of discourse into "real" and "not-so-real" and "completely unreal".

Some people in software development worlds might regard what happens inside a computer as "real" and what happens outside the computer as "ideal". Meanwhile, business people are more likely to regard what happens in the business as "real" and what happens inside the computer as "abstract". If the job of EA is to bridge between these and other worlds, then EA needs to regard both of these notions of "reality" as equally legitimate, coming from equal and opposite viewpoints. For this reason, I regard any architecture framework with a one-sided (typically IT-centric) notion of reality as deeply suspect.

 

For more on reification, see my post Deconstructing the Grammar of Business (June 2009). See also The Topography of Enterprise Architecture (September 2011)

Note also Simondon's concept of concretization, which seems to involve a form of technical refinement akin to naturalization. "It can only be said that technical objects tend toward concretization, whereas natural objects such as living beings are concrete from the start." Gilbert Simondon, On the Mode of Existence of Technical Objects (1958). See also Bernard Stiegler, Technics and Time 1 (1994, English translation Stanford 1998).

The Topography of Enterprise Architecture

A lot of the terminology of enterprise architecture depends on some basic categories and distinctions, which help to define the dimensions for various schemas and frameworks.

• Top-down / Bottom-up
• Ideal / Real
• Abstract / Concrete
• Espoused / In-Use

But the meaning of these terms depends on your perspective. See for example my previous post What Does "Top-Down" Mean?

One popular categorical distinction is between “ideal” and “real”, with a progressive series of intermediate states. This category implies a process known as “realization” moving from the “ideal” towards the “real” (for which the Zachmanites prefer the mediaeval word “reification”), and a contrary process known as “idealization” moving from the “real” towards the “ideal”.

(The Zachmanites claim that this distinction derives from some unnamed ancient Greek philosophers, but I have not been able to verify this claim. The earliest sources I can find for this notion are mediaeval Christian and Arabic philosophers such as Ibn Arabi and Ockham, although there may be some hints in Plotinus. What Plato and Aristotle talked about was Form and Matter, and although Form is often translated as Idea, that's not exactly the same.)

But it is interesting to see exactly what people regard as more “real”. For example, many people seem to think that the technology model is more “real” than the business model. In other words, a pattern of magnetic dots on a physical data storage device counts as more “real” than the flesh-and-blood customer that this pattern of dots represents. Such a technologically based notion of “reality” may be useful for some purposes, but it is inescapably a technological perspective. And no EA framework that uncritically adopts a technologically based notion of “reality” can claim to be free of a technological bias.

 

 

Stanford Encyclopedia of Philosophy: Form vs Matter  

For more on reification, see my post Deconstructing the Grammar of Business (June 2009)

Updated May 2024 to insert reference to Plotinus