Reification and Ratification veryard projects > information management > reification & ratification

we offer	reification	ratification	links
consultancy workshops	Reification means viewing something (such as a process or relationship) as an object. Reification is an important technique of Software Engineering.  Database Object-Orientation More generally, reification can be regarded as a form of materialism.  Excessive reification may be regarded as a mode of misplaced concreteness akin to fetishism.	Ratification 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).

The Role of Reification in Software Engineering veryard projects > information management > reification & ratification > software engineering

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.
 

Customer Identity - Business View versus Data View

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.
 

Classification Identity and Difference

Reification and Ratification in Customer Relationship Management veryard projects > information management > reification & ratification > CRM

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.
 

Customer Relationship Management Customer Identity - Business View versus Data View

Reification as a form of Materialism veryard projects > information management > reification & ratification > materialism

Materialism is not just a matter of wanting to possess things, although that’s certainly part of it.  It’s a matter of perceiving the world as if it were composed of things.  Children are taught this from an early age: most of the available books for toddlers have one word on each page, and the word is a noun: ball, bear, banana.

If you really make an effort, you can find books showing activities (bathing, building, blushing) or spatial relationships (inside, outside, upside down) or even feelings (happy, sad, tired).  But it’s still difficult for us adults to escape from the materialist mindset, or to avoid transmitting it to the next generation.  After all, materialism is embedded in the structure of the child’s book (one page, one picture, one word), together with the implicit notion that the child’s task is to accumulate vocabulary, one word at a time.

That’s why it’s so difficult to see the world other than as objects, and why the object-oriented paradigm is so attractive. However, technology may now be driving us beyond this paradigm, into a world where things are indexed purely by availability.
 

Software Objects and Mediaeval Thought The relevance of Arab and Christian philosophy to object thinking Availability

veryard projects > information management > reification & ratification

This page last updated on November 6th, 2003 Copyright © 2003 Veryard Projects Ltd  http://www.veryard.com/infomgt/reification.htm