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

Deconstructing The Grammar of Business

@JohnIMM (John Owens) trots out a familiar piece of advice about data modelling today.

"Want to know what data entities your business needs? Start with the nouns in the business function names."

Starting with the nouns is a very old procedure. I can remember sitting through courses where the first exercise was to underline the nouns in a textual description of some business process. So when I started teaching data modelling, I decided to make this procedure more interesting. I took an extract from George Orwell's essay on Hop-Picking, and got the students to underline the nouns. Then we worked out what these nouns actually signified. For example, some of them were numbers and units of measure, some of them were instances, and some of them were reifications. (I'll explain shortly what I mean by reification.) Only a minority of the nouns in this passage passed muster as data entities. Another feature of the extract was that it used a lot of relatively unfamiliar terms - few of us had experience measuring things in bushels, for example - and I was able to show how this analytical technique provided a way of getting into the unfamiliar terminology of a new business area. I included this example in my first book, Pragmatic Data Analysis, published in 1984 and long out of print.

One problem with using this procedure in a training class is that it gives a false impression of what modelling is all about. Modelling is not about translating a clear written description into a clear diagrammatic structure; in the real world you don't have George Orwell doing your observation and writing up your interview notes for you.

Now let me come on to the problem of reification. The Zachman camp has started to use this word (in my view incorrectly) as an synonym of realisation - in other words, the translation and transformation of Ideas into Reality. (They claim this notion can be traced back to the ancient Greeks, but they do not provide any references to support this claim. As far as I am aware, this is a mediaeval notion; it can for example be found in the work of the Arab philosopher ibn Arabi, who talks about entification in apparently this sense.) However, modern philosophers of language use the word "reification" to refer the elevation of abstract ideas (such as qualities) to Thingness. One of the earliest critics of reification was Ockham, who objected to the mediaeval habit of multiplying abstract ideas and reified universals; his principle of simplicity is now known as Ockham's Razor.

In our time, Quine showed how apparently innocent concepts often contained hidden reification, and my own approach to information modelling has been strongly influenced by Quine. For example, I am wary of taking "customer" as a simple concept, and prefer to deconstruct it into a bundle of bits of intentionality and behaviour and other stuff. (See my post on Customer Orientation.) As for business concepts like "competitor" or "prospect", I generally regard these these as reifications resulting from business intelligence.

Reification tends to obscure the construction processes - tempting us to fall into the fallacy of regarding the reifications as if they directly reflected some real world entities. (See my posts on Responding to Uncertainty 1 and 2.) So I like to talk about ratification as a counterbalance to reification - making the construction process explicit.

Of course, John Owens is right insofar as the grammar of the data model should match the grammar of the process model. And of course for service-oriented modelling, the grammar of the capabilities must match that of the core business services. But what is the grammar of the business itself? Merely going along with the existing nouns and verbs may leave us short of discovering the deep structural patterns. 

 

Update May 2024. The distinction I'm making here between reification and its opposite, which I've called ratification, can be compared to Simondon's distinction between ontology and ontogenesis, so I shall need to write more about that. Meanwhile, I now acknowledge the possibility that some notion of reification might be found among the Neoplatonists but that's several hundred years after Plato himself.

Related posts: Reification and Ratification November 2003), Business Concepts and Business Types (May 2009), Business Rule Concepts (December 2009), The Topography of Enterprise Architecture (September 2011), Conceptual Modelling - Why Theory (November 2011), From AS-IS to TO-BE (October 2012), BankSpeak (May 2015), Mapping out the entire world of objects (July 2020)

Reification and Ratification

Reification means viewing something (such as a process or relationship) as an object. Reification is an important technique of Software Engineering. 

• Database
• Object-Orientation

What is the opposite of reification? I call it Ratification. This means viewing an object as something else (such as a process or relationship). 

Many OOSE developers use reification techniques excessively and uncritically. We therefore make a point of practising and teaching the reverse techniques. An example of the importance of ratification can be found in Customer Relationship Management (CRM).

---

Software engineers with a database background are accustomed to treating customers, products and other business concepts as data objects. From a data-oriented perspective, a key task of business systems analysis is to divide up "customer-space" and "product-space" into fixed, predictable, discrete units of customer and product. Customer and product information can then be captured as a set of data records, each representing a fixed set of facts about a specific customer or product.

But from a business perspective, this can be a gross simplification. Customer relationship management is a (collaborative) process of relating to the customer; product management is a process of developing products. Business management often needs much more flexible, fluid, complex notions of customer and product.

The object-oriented way of describing the world is extremely useful, especially for designing and managing components. It is also useful for describing the behaviour of components, and their performance in complex environments. There are excellent techniques for creating objects out of processes, out of relationships, or perhaps even out of nothing. Philosophers and software engineers have a word for this; they call it reification.

When relationships are regarded as things, this usually focuses attention either on the bridging mechanism, or on a static snapshot of the relationship, as for example represented by a legal contract. When processes or services are regarded as things, this usually focuses attention on the deliverable or end-result.

But there are limitations to an object-oriented view of systems and components. Sometimes we need the reverse procedure - to understand things as dynamic clusters of activities and relationships. We call this ratification.

Database development requires data to be identified and classified. Naive reification results in fixed and unchangeable identities and classifications - and this suits the normal constraints of data management software - but often results in information systems that are inflexible and cause difficulties to business users. Ratification of the identification and classification processes, although sometimes harder to code in software, can result in a much better alignment with business requirements.

 

Many companies (especially financial service companies) have invested large amounts of information system effort on converting their information systems to being customer-centric. This has typically been motivated by significant levels of duplication in the databases, and an inability to identify when a customer has more than one relationship with the company - e.g. multiple accounts. A common reason for this is that legacy systems have been account-centric - with separate customer details for each account. Another common reason is that the customer base has grown through merger and acquisition.

In Customer Relationship Management systems, there is typically an object called CUSTOMER, which is the primary focus of the system and its data structure. A naive view of this object is that it represents a person or company - or any other PARTY playing a customer role. A consequence of this view is that if a customer is represented twice, and if the details don't match (e.g. different addresses), then one of the records is simply wrong.

But this naive view stems from an implicit act of reification, which can sometimes produce misleading results. In a customer relationship management system, CUSTOMER is actually a reification of the customer relationship. If there are multiple relationships, it may well be appropriate to have different information associated with each relationship.

Our approach to information modelling takes these implicit reifications and analyses them to expose the underlying relationships and processes. Of course, it may still be good to reduce or eliminate duplications and discrepancies in customer information - but we think it better to do this on the basis of explicit ratification rather than implicit reification.

 

Update May 2024. The distinction I'm making here between reification and its opposite, which I've called ratification, can be compared to Simondon's distinction between ontology and ontogenesis, so I shall need to write more about that.

---

Originally posted at http://www.veryard.com/infomgt/reification.htm

Related posts: Deconstructing the Grammar of Business (June 2009)