![]() |
identity and differencenotes |
> concepts
> information
mgt page
|
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.
|
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).
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.
This notion of identity is based on knowledge - how do people recognize
an
old beggar as Ulysses?
![]() |
Business Identityveryard projects > modelling > identity > business identity |
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.
Identity is therefore a very important business issue, and a key element of the requirements for a business information system.
![]() |
Customer Identity - Business View versus Data Viewveryard projects > modelling > identity > customer identity |
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 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 not the same, unless we have evidence that they are |
![]() |
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 |
![]() |
Customer Relationship Management |
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.)
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 specialists often advise the use of meaningless strings of numbers as a fixed and unique key - but this also brings problems. For one thing, most people find it difficult to learn, remember and use these strings. For another things, these strings are themselves invalidated by identity shifts in the "real world".
![]() |
Reification and Ratification
Signature |
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 |
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:
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 > modelling > identity |
Copyright © 1999-2003 Veryard Projects Ltd http://www.veryard.com/infomgt/identity.htm |