identity and difference


on this page

> concepts
> business strategy
> customers
> information
> mechanisms
> modelling ideas
home page contact us

> information mgt page
> who owns your mother's maiden name?
> Heraclitus
> more on modelling

In order to understand change and difference, we need to understand not-change and not-difference - in other words, identity.

Continuity and discontinuity, order and chaos, quantity and quality - all these depend on an underlying notion of identity. As a consultant, I aspire to intervene usefully in large complex systems - so it's rather important to me (and my clients) to have some way of assessing whether my intervention has made any difference - or whether things are really just the same.
Business strategy The identity of a modern (or post-modern) company is increasingly complicated.  Strategic advantage comes from being just a little different.
Customers New ways of identifying customers - individuals instead of large corporations, individuals as members of friendship circles, and so on.  Implications for IT, especially data management.
Information Most information must refer to something. This means we need to identify the thing to which the information refers. Therefore the analysis and design of information systems demands the ability to think clearly about questions of identity.


basic concepts


There is a close linkage between the concepts of information, identity and difference.

Identity means - how do we recognize or refer to something as the same again. The ancients knew two stars, the morning star and the evening star - but these turned out to be different manifestations of the same planet (Venus). The customer who has just bought a sack of potatoes happens to be the same person who bought a chip pan from the hardware store next door (which we might discover if we had access to his credit card information).

For many purposes, two things are the same if we cannot tell them apart. Identity amounts to a lack of difference. And we can define information as "a difference that makes a difference" (Bateson).


Hold your hand perfectly still, palm upwards and resting comfortably on a table. With your other hand, drop a small coin into the palm. You will feel the impact, and if the coin is cold, you will feel the coldness of the metal. Soon however, you will feel nothing. The nerve cells don't bother repeating themselves. They will only report to the brain when something changes. Information is difference.

A lizard hunting insects operates on the same principle. The lizard's eye only reports movement to the lizard's brain. If the hunted insect settles on a leaf, the lizard literally cannot see it. But the moment the insect starts to move, whop, the lizard can see it again, and the tongue flickers out and catches it.

But there are differences and differences. Information is difference that makes a difference. You were probably aware, as you dropped the coin into your palm, your eyes told you automatically, without your brain even asking, what the value of the coin was; but you were probably not aware what date it was minted. This is because (unless you are a numismatist) the value of the coin makes a difference to you whereas its date doesn't.

What is it that makes a difference to a lizard, to a numismatist, to you? Surely not the same things. What is information for the lizard is not information for you, and what is information for you is not information for the lizard.

This is why the perspective of an information model is so important. Perspective defines what counts as information at all, perspective defines to whom the information makes a difference.

This is not the same as the purpose of the information model, as a model. The perspective may imply the purpose of the information modelled therein. But significance is more than just purpose; purpose is just one of several ways in which information may make a difference.


Identity crisis

"The Ulysses who arrives in Ithaca as a poor beggar unrecognized by everyone is no longer the same person as the Ulysses who departed for Troy. It is no coincidence that he had once saved his life by pretending his name was Nobody. The only immediate and spontaneous recognition comes from his dog, Argos, as if the continuity of the individual could make itself manifest through signs perceptible only to an animal. For the nurse, the proof of his identity was the scar left him by a boar's tusk, for his wife the secret of the manufacture of their marriage bed out of the roots of an olive tree, and for his father a list of fruit trees. These signs have nothing regal about them; they put the hero on the level of a poacher, a carpenter, a gardener." 

[Italo Calvino, The Literature Machine (trans Patrick Creagh, Pan Books, London, 1989) pp 140-1]

This notion of identity is based on knowledge - how do people recognize an old beggar as Ulysses?

veryard projects - innovation for demanding change

Business Identity

veryard projects > modelling > identity > business identity

Rethink the identity of your organization

The identity of a modern (or post-modern) company is increasingly complicated.  A number of organizations have identified me as a "loyal" customer of theirs, including several airlines and retail chains.  I have several plastic cards as tokens of my loyalty, what could be more authentic than that?  By accepting the card and its benefits, I have given them the right to identify me in this way.  But how do I identify them?

An excellent example of this is ambiguity of identity is Tesco.  As a Tesco Clubcard holder, I could reasonably ask: who exactly is the Tesco that I am supposedly being loyal to?  Is it a grocer, an ISP, a bank, a travel agent?  Is it a network of alliances and supply chains, under a common brand name? Part of the dynamism of an entity like Tesco is that it is constantly redefining its identity.

Performance measures

Questions of identity are also critical for business performance measurement.  For example, if we want to measure the proportion of sales enquiries that are converted into sales, we have know whether the phone call from Mrs Smith counts as a follow-up to the phone call from Mr Smith, or whether it is an entirely separate enquiry.  In other words, what is the business identifier for the entity type SALES ENQUIRY.

Identity is therefore a very important business issue, and a key element of the requirements for a business information system.

veryard projects - innovation for demanding change

Customer Identity - Business View versus Data View

veryard projects > modelling > identity > customer identity

In a large organization, different departments may have different notions as to the identity of the customer. (For example, does a grocer sell a breakfast cereal to children or to their parents? Does an oil company sell petrol to motorists, or to petrol stations? Among other things, how you answer such questions affects the number of customers you think you have - and this in turn affects performance measurement.

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

But from a business perspective, this is the wrong question. Instead, we need to model the (collaborative) process of relating to the customer. This allows a much more flexible, fluid, complex notion of customer. Here are some examples where the data-oriented view doesn't quite work.
data-oriented view business-oriented view
married couple either two separate customers (Mr and Mrs) with a link between them 

or a single customer (Mr-and-Mrs)

or three customers (Mr, Mrs and Mr-and-Mrs) with some complicated link between them

in business terms, a married couple probably represents more than a single customer, but less than two single customers 
    thus we want to send them one catalog, probably not two, certainly not three

    thus if both husband and wife ask for a quote, this probably only represents one business opportunity

parent and child probably one customer, possibly two when the parent is buying a product, this may be the result of a complex negotation between mother and child 

some advertising may be directed at the parent, some at the child, and some at both - so it may be difficult to calculate the success of a given advertising campaign

obviously a parent may have more than one child, and a child may have more than two parents - if you count step-parents and grandparents and child-minders playing the parental role

same name, same postcode some computer systems are unable to detect or remove duplicate entries 

some computer systems are unable to accept duplicate entries

in many computer systems, it is very difficult to merge two customer histories into one, or to split one customer history into two

suppose we have two separate transactions involving a Mr Fred Smith, at a given address - should we assume they are the same person? 
    assume they are the same, unless we have evidence that they are not - for example, father and son with the same name

    assume they are not the same, unless we have evidence that they are

in practical business terms, you have to be able to start doing business with Fred Smith before you know whether he is the same Fred Smith as the one already on your database
sole-trader with both business and private accounts either two customers (Fred Smith, Fred Smith &co Limited) 

or one customer

but when Fred Smith rings up, he doesn't always tell you whether he's calling for personal or business - in fact, he may well want to deal with both in one call
more Customer Relationship Management


In conceptual data modelling, each entity type has a requirement for identity.  This entails the ability to recognize an entity as the same again.


Imagine that you have just stolen some honey from a beehive. You are fiercely pursued. Are you pursued by many bees, or by one swarm of bee? If you are stung, are you stung by one bee or by the swarm?

Where a group of people is defined solely as the collection of its members, there will be problems with stability. Each time somebody leaves, or somebody else joins, we have a new group. How do we account for the actions of a group ? We may be interested in acts carried by the group as a whole, or in acts carried out by one or more individuals on behalf of a group, or in independent acts carried out by individuals who happen to belong to the group.

ORGANIZATION or ORGANIZATION UNIT can be regarded as a simple object, provided that it is defined by name, and not by the collection of PERSONs that happen to belong to it. But teams can often change their identity if their membership changes significantly. (Pop groups cause particular problems, particularly if they register collective ownership of copyright on songs.)



Component-Based Development

For me, one of the key insights of component-based development is that it provides me with clean mechanisms for dealing with apparently inconsistent notions.

This means I don't have to worry that different people define a notion in many different ways, as long as I am aware of this, and can bridge between the multiple notions.

In a commercial organization, for example, different departments may have different notions as to the identity of the customer. (For example, does a grocer sell a breakfast cereal to children or to their parents? Does an oil company sell petrol to motorists, or to petrol stations? Among other things, how you answer this question affects the number of customers you think you have.)

In the old days of central data modelling, we needed to agree a single corporate definition of CUSTOMER. These definitions often got quite complicated, because they needed to cover a range of different overlapping notions.

With component-based systems, there are more elegant ways of dealing with this complexity.

Turning to the definition of COMPONENT itself, it is an observable fact that there are different notions of component in popular circulation.

Some people have an inside-out definition - a component is essentially a lump of software with such-and-such properties. And some people have an outside-in definition - a component is essentially a set of services accessed through a specified interface whose implementation satisfies such-and-such properties.

Obviously if you show the same configuration to these people and ask how many components can you see, how much reuse has been achieved, you will get quite different answers.

Instead of saying that half of them are wrong, I have developed an ecological model of the component world, showing how each definition made sense in a particular context, and how these contexts (which I call ecosystems) could be connected to each other.


Database keys

In a traditional computer system, records are identified by an identifier or key. There is a crucial dilemma in designing such identifying mechanisms.


The act of identification is itself a process. Naive reification results in fixed and unchangeable identities - 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 process, although sometimes harder to code in software, can result in a much better alignment with business requirements.
more Reification and Ratification


modelling ideas

principles and patterns
Understand what you're counting

When people disagree about number this often reveals a disagrement about concept


fallacies and obsolete principles
Counting something before you've defined what you're counting

Forcing a standard definition

Treating CUSTOMER (or other business entity) as a thing with a fixed identity

Assuming you know enough to detect identity and difference


I found the following argument posted on an internet discussion (hosted by the New England Complex Systems Institute

The very very important point, one that is also very controversal when intellectually addressed, but which is the guiding basis for (my interpretation of) pragmatics; is that that ARE NOT an infinite number of possible way in which a specific situation can evolve. There are only a few events paths leading from any natural event in real time space.

This statement may not be provable, but neither can the statement be proved that there are actually an infinite number of ways that an specific event can evolve.

My argument is this: Events are rooted in a pragmatic axis that will not allow other than a few event paths from that space time point (soft determinism).

There is a third statement, which is that there is only one event path from each event point (i reject this statement).

Paul Prueitt
June 3rd, 1999
How many paths are there? I don't even know how many paths there are in my garden - because I don't know what counts as a different path. If my younger son crawls to the bottom of the garden, is that the same path as when my older son drives his tractor?

Such questions as these cannot be resolved until you know what you're counting.


As a practical rule of thumb, when two people differ hugely in their estimate of the number of occurrences of some class, this is often a conceptual difference rather than a factual difference. In other words, they're not talking about the same thing.

In his essay on Keats's 'Ode to a nightingale', Jorge Luis Borges points out that an individual nightingale is unidentifiable. Keats regards the bird he heard as immortal; this is because the same bird was heard (and extolled) by Chaucer, Milton and Swinburne. Borges goes on to quote Schopenhauer, who wrote:

There's more in my book on Information Modelling, but it's currently out of print.
Richard Veryard

Information Modelling, Practical Guidance

Prentice-Hall, 1992.



I have spent over twenty-five years covertly trying to inject basic philosophical notions like identity into the working practices of engineers, with the tolerant or sceptical amusement of those university chums who (despite Wittgenstein's advice) decided to become professional philosophers. Thanks in particular to Timothy Williamson.

veryard projects - innovation for demanding change veryard projects > modelling > identity
This page last updated on July 26th, 2003
Copyright © 1999-2003 Veryard Projects Ltd