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