Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Confusion reigns – Characteristics and Classifications

Some years back I was asked, What is the difference between a Data Modeller and a Terrorist?  The answer of course is that you can negotiate with a terrorist.  But while this view is still held by many today there are signs of a new breed of data modeller emerging that do whatever they are asked to do – the Customer is always right.

Of course that simple expression is often said through clenched teeth – many customers are not right (please forgive me) but the intention is to instil in people’s minds that good customer service requires a different approach to “the customer is always wrong and should be denied any opportunity to criticise us”.

So, how do you strike the balance between doing what is right, and doing what the Customer wants when the two aren’t always aligned?

Data modelling is something of an art form.  There is seldom an objective “correct” answer and even in the most clear cut situation data modellers will advocate different things based on their experience and prejudices.   The title refers to confusion that is a consequence of characteristics and classifications becoming mixed up by data modellers and their clients and this short article is intended to help people recognise this in the hope that some of the confusion will be dissipated.

At its simplest a characteristic is something that is perceived to be descriptive of something or someone at a point in time.  Ideally it is reasonably enduring or at least captured and connected to the time of observation.  For example, I have a First Given Name of Stephen.  As far as I am aware this has always been my First Given Name and since I have no intention of applying to change it it is reasonable to assume it is going to be an ongoing characteristic.  My Blood Group is B positive and this (assuming I have been told the correct value) is likely to endure as my Blood Group. 

On the other hand a classification is something that is based on connected, and to some extent transitory, information that depends to some extent on a policy, or a rule and often involves some level of assessment or decision.   If you classify a house according to its number of bathrooms, while the number of bathrooms is clearly a characteristic, the classification “small” might mean it has 1 bathroom, but in an estate agents that only sells mansions small might mean <5 bathrooms.  While the number of bathrooms is a characteristic the classification depends on other criteria and can easily change.  I can derive the classification from the combination of the characteristic and the rule.

A Person may be defined as being a living human being.  The characteristics of a human being are well defined and there are legal definitions of what “living” means.  If a thing has those charateristics it is a Person.   There are few possible alternatives to this.

However, a Customer may be defined in many different ways.  For example,

A Person or organisation that has at some point in time purchased an item from our company. 


A Person or organisation that has purchased an item from our company, paid for it, and not returned it for a refund.


A legal entity that has interacted with our company, whether as a buyer or a seller, potential or actual.

These variations are a consequence of policy, the intended use of the data collected and stored and the presence or absence of data that allows the classification.

There is every reason to have a Person table.  There is no problem connecting that table to a classification table showing them to be a prospect, customer, ex customer, employee, etc.  Ideally the classification should be based on (and linked to) some criteria that may be charateristics of a relationship or separate table (e.g. transaction) and better still I should be able to change the rules easily if the needs of the business change.

When a data modeller comes to deal with the simple requirements of his/her client an understanding of what the client has asked for must be related to the flexibility that the client might need.  Databases are notoriously difficult to redesign later so a good data modeller should be allowed to get it as close to “right” as is practical from the start.  This requires some challenging questions.

You have every right to tell me you want a Customer table.  I reserve the right to try to persuade you that you don’t and then we can start negotiating…….

About the author

Stephen Timbers
Stephen Timbers
I've been modelling data in various forms for over 20 years and I'm just starting to get my head around information! Towards the end of a career in the British Army I started working on data models for the exchange of battlefield data across NATO. After leaving I worked at Sainsbury's and Accenture looking after data and application architecture and after a short spell at EDS joined Capgemini as an Enterprise Architect. I am working in the Information Strategy team. a part of Business Information Management. I like to write about how difficult it is to use a language that isn't defined, changes its meaning continuously and yet is vital to our day to day lives - data

Leave a comment

Your email address will not be published. Required fields are marked *.