Data-fit concepts of record - information, application-interface, record, data - in that order.

One of the things that I've talked about quite a bit over the last few years, is how I'm seeing the records and data management parts of the organisation come together in every program that is sufficiently advanced.

The missing piece in most of them, is a unified concept of records as data, and data as records.

People are going wrong in fairly consistent ways.

Many data people are going wrong because they think that "record" is an irrelevent concept.

I think they feel this way because they haven't been sufficiently exposed to ideas about what records are, and how important the concept is, to have appreciated it. I think that there's also a certain blindness to the problem that the recording of the data solved for the people recording it - a certain tendency to deal with data as the thing, not data as the representation of a business activity and the things about that business activity that were important enough to record, and need to be known with high fidelity later on.

At the same time, there's a certain lack of desire in records people to spend time sufficiently understanding how the data came to be, to understand the concept of record as it applies to the data.

Partly, I think this is because there's also a tendency in records to want to distance ourselves from the thing that our records represent - the same problem where we deal with the record as the thing, and only want to manage it - rather than seeing it as the representation of something that happened in the real world - the things about it that were important enough to record because they would need to be known with high fidelity later on (that sentence duplicated on purpose, it is what unifies us, if we can bring ourselves to see that).

We are also (in general, as a group) woefully inadequate in our understanding of how data comes to be in a database and the structure of it once it's there. While we might occasionally laugh at the fact that rows in a database are called records, if we laughed less and went and looked and understood more, we'd be in a much better position to realise that it's no more worthy of laughter than our idea that many documents constitute a record - databases just aggregate differently.

The mistake everyone seems to be making, is thinking that they can understand data as a record without understanding how the information is recorded as data.

The answer (to me at least) is relatively simple, it's in the interface - generally the business application that people use to record the data (as a note, it's worth considering it an interface because then we can get to a useful concept of record when it's an API being written to by a machine).

What people see in the interface, and what they record there, gives us the best chance of understanding the business activity that's at play, and once we understand the business activity, we understand what is being represented by the record - the context.

The data fit concept of record has to acknowledge that the record is what gets created using the creation nterface (generally the business application) - which is most likely being entered by a person.

Trying to deal with the data-as-records problem any other way leaves us without the context that allows us to link them to real world things.

And so far, customers don't care about things not linked to the real world, you can't build businesses on them, they're no good for analytics, regulators don't care about them - they're basically useless and it's hard to work out why anyone would waste any time on them - data or records people.

Thoughts?