Data Thinking

Understand the data before you automate the process around it.

Data thinking is not about putting data at the centre of every slide deck. It is about understanding what the business facts actually mean, where they came from, how they change and what happens to them as they move. Get that right and technology becomes useful. Get it wrong and you simply automate the confusion.

Data thinking without the theatre

I have never found much value in fantasy-land architectures that only live in slide decks.

Real organisations have inherited systems, duplicated records, awkward integrations, historical decisions, spreadsheets somebody still depends upon and business rules that occasionally exist only in somebody's head.

Data thinking starts there.

Understand the facts first. Understand their context. Understand how they move. Then decide what process, platform or technology is required.

Follow the data and you usually find the business

Processes change. Organisation charts change. Applications certainly change. The underlying business facts tend to be more persistent.

An order may pass through CRM, billing, fulfilment, finance and reporting. Each platform sees part of the journey, but the data relationships reveal how those parts fit together.

That is why I tend to start with the data rather than the process diagram. The process tells me what people expect to happen. The data often tells me what actually happened.

Neither replaces the other. The useful bit is understanding the relationship between them.

Define. Move. Prove.

Structure before cleverness

I am fond of dimensional thinking because it forces an apparently simple question:

What happened, and what context do I need to understand it?

In dimensional terms, the thing that happened becomes the fact and the surrounding perspectives become dimensions: who, what, when, where, organisation, product, customer and so on.

That does not mean every problem requires a star schema. It means the discipline behind dimensional modelling is useful well before anyone creates a database table.

It provides a common language for requirements, migration, reconciliation, analytics and discussion with the people who actually understand the business.

Data has a life outside the database

Managing information means understanding it wherever it happens to be: stored, being used or moving between places.

Lineage is not decoration

When somebody asks, “Where did this number come from?”, the answer should not depend on finding the person who built the spreadsheet three years ago.

Useful lineage tells us where data originated, what happened to it, where it travelled and which rules were applied along the way.

That matters for migration, analytics, security, governance and AI for exactly the same reason: a result is considerably more useful when we can explain how we arrived at it.

Evidence by example: data divestment

Divestments are a good example of why data problems become interesting once the tidy diagrams meet time.

Imagine an employee starts a transaction while working for Company A and moves to Company B before that transaction completes.

Who owns the historic record? Who is entitled to see it? Which company should receive it during separation?

Those are not simply extraction questions. They depend on effective dates, provenance, legal ownership, entitlement and the business event being represented.

This is where a good data model earns its crust. Instead of hiding every exception inside procedural code, make the relationships and their history visible enough to question, test and defend.

Platforms matter. Their heritage matters too.

ERP, CRM, BSS, OSS and cloud platforms are not interchangeable boxes. Each has architectural history, assumptions and seams.

Understanding where a platform came from can tell you almost as much as its current architecture diagram: what grew organically, what was bought, what was bolted on and where integration is likely to become interesting.

I keep the deeper platform material separately so this page can stay focused on the thinking rather than becoming an encyclopaedia.

And then somebody asks about AI

AI does not make poor data magically acquire meaning.

Models still depend upon context, quality, provenance and appropriate structure. If the underlying business concepts are muddled, the ability to process them faster merely produces muddle at impressive speed.

The groundwork therefore remains rather traditional: understand the information, structure it appropriately, retain its provenance and know what transformations have been applied.

The clever technology comes afterwards.

Practitioner note

Data thinking is not data worship.

Processes matter. Technology matters. People certainly matter.

The point is simply that when things become complicated, following the data gives you a remarkably effective way of finding out what the organisation is really doing.

The short version

Understand what the data represents.
Preserve its meaning as it moves.
Prove what happened to it.

Everything else is implementation detail.