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)
No comments:
Post a Comment