One speaker at ITC 2012 in London spoke of
how the false economies of an earlier systems decision came to light during a
subsequent data migration exercise. It seems the performance of an underwriting
system had been speeded up by disabling its validation. This simple
intervention improved performance by 20%, at no cost. Even better, underwriters
using the system found they could put whatever they wanted in its fields.
Instead of asking the IT team for enhancements to cope with new data items,
they simply bent existing fields to new uses. This meant everyone was even
happier, not only was the system faster, but development costs went down.
Two or three years later and the need for
data migration after integration exposes the folly of this decision. The
systems' fields were filled with disparate data that was hard to interpret.
Dispensing with quality control brought apparent short-term benefits but
created massive problems further down the line.
The company concerned dealt with the
problem, bringing its systems discipline back in line and insisting on
validation – and thereby data quality. The speaker went on to say that
organizations across the industry must hold themselves responsible for the
quality of the data they send each other and not try to offload the
responsibility on to intermediate handlers of the data. Whatever you do inside
the organization may be okay, bit at the interfaces you must have the discipline of standards.
It's interesting that the time delay
between the poor decision to unhook validation and the integration blow-up was
short – only a couple of years. Since people don't often share war stories like
this, you might think data quality issues like this are only relevant to aged
systems. But it seems that, perhaps under the pressure to perform cost
miracles, and with a lack of direction about the value of data assets, IT folks
can use the kinds of strategies we associate with an era of less frequent
change and more expensive storage costs.
More important is the message that data
quality is today more likely to be a concern of the business than the IT
professional. After all, we migrate data because it's of interest to the
business, not for the sheer fun of it.
We capture data because it's fundamental to the business – at the end of the
day, it is the business.
We need to educate our IT colleagues on the value of
data. It's not just “content”. Or rather, “content” is more valuable than such
a generic term suggests. This data we generate, store, modify and share is the
stuff of business.