Reification and Ratificationveryard projects > information management > reification & ratification
|consultancy||Reification means viewing something (such as a
process or relationship) as an object.
Reification is an important technique of Software Engineering.
|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 Engineeringveryard 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.
Identity and Difference
Reification and Ratification in Customer Relationship Managementveryard 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
|Customer Relationship Management
Customer Identity - Business View versus Data View
Reification as a form of Materialismveryard 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
The relevance of Arab and Christian philosophy to object thinking
|veryard projects > information management > reification & ratification||
Copyright © 2003 Veryard Projects Ltd