Most data strategies start by describing the data: how much there is, how fast it arrives, how many forms it takes, whether it can be trusted and what it is worth. Volume, velocity, variety, veracity and value. The five Vs of big data are a useful checklist, and they turn up in nearly every strategy paper for that reason.
The trouble is that they describe, they don't decide. They overlap too much to each earn a place, and they leave out the properties that actually move a decision. A data strategy is only as good as the questions it forces you to ask, and the Vs mostly ask "what do we have?" rather than "can we act on it?"
The properties that move a decision
Read each of these as an instrument reading on a given dataset: a property you can, in principle, measure regardless of who is looking.
- Quality, and representativeness. Quality is how right and how whole the data is: accuracy, completeness, consistency, validity. It is recoverable. You can clean data later, at a cost. Representativeness is different. Data can be immaculate and still be the wrong sample to reason from. Accurate is not the same as representative, and it is the first thing any review of an AI model's training data goes looking for.
- Tractability. How much work sits between "we have it" and "we can compute on it": structured, semi-structured or unstructured, and the cost of making it joinable. It is the decisive property wherever most of what you hold is unstructured or trapped in incompatible systems, and it is the one the Vs leave out.
- Defensibility. Can anyone else get this? In an open market, the value of raw data trends to zero. Behind a gate, the gate is the value.
Volume matters less on its own than it appears. It counts mostly through the cost it creates and the patterns it unlocks.
Velocity is a property of the world. Cadence is a property of your process. The gap between them is where you fly blind without knowing it.
Velocity is not one thing
The Vs treat velocity as the speed at which data is produced and processed. That merges three separate readings, and the gaps between them are where most of the risk sits.
Velocity proper is the rate at which the underlying truth changes. Cadence is how often you sample it. Timeliness is whether the data is still current enough to act on by the time it reaches the decision. When cadence is slower than velocity, the data looks current but is stale, and nobody knows it.
Take monthly cost returns on a cost-reimbursable contract. Cost is incurred continuously; it is returned once a month. Every reading is therefore up to a month old. For steering the programme, that is fine: a month-old position is still directional enough to act on. But any benchmark built from those returns reasons from a picture that is already out of date, and the weakness bites the moment the figures have to stand as evidence.
Veracity is three questions, not one
Veracity is usually treated as a yes or no: can we trust the source? It is better read as three questions you can interrogate.
How robust was the capture? Was it captured by a machine or a person? A machine is consistent, but can be systematically wrong if it is miscalibrated. A person is variable and subjective, but aware of context. And was it transformed, aggregated or re-keyed on the way? Every hand-off is a point where trust leaks. The further a figure sits from where it was created, the more it has to be trusted rather than verified. That is the difference between "we have it" and "we can rely on it".
The two decisions you cannot walk back
Most data problems can be fixed later, at a price. Two cannot.
The first is granularity. How fine is fine enough is set by the decision, not by a "finer is better" instinct: coarse data will tell you how a system is performing, but tuning an activity needs resolution an order of magnitude finer. The rule of thumb is to capture roughly one level below the level you intend to act at. You can never make coarse data fine after the fact.
The second is provenance. A broken chain of custody cannot be rebuilt afterwards either. For both, you have to commit at the point of capture, to the finest level and the fullest record you might later need. That is the one place where a data strategy should run ahead of its known purposes.
What the Vs never ask
Two more questions belong in any data strategy, and neither appears on the usual checklist.
Does using the data change it? When a measure becomes a target, it stops being a good measure. Any benchmark or governance metric invites gaming, and a forecast that helps set the baseline it is judged against is partly measuring itself. That is tolerable when you are steering, and corrosive when the figure has to stand as proof.
Can we reach what we already hold? Data that is carried but unreachable, often called dark data, is cost without value until the friction is removed. It is the mirror of defensibility: not "can others get it" but "can we act on what we already have".
Decide, don't describe
A descriptive framework catalogues data and stops. A useful one ends every pass in a verdict. There are four: act, because the data clears the bar the decision sets; wait, because letting the data mature costs less than being wrong; don't trust it, because the provenance is too weak, so use it as a signal to investigate and never as proof; or don't hold it, because the carrying cost and the liability of keeping it exceed its value.
None of this is new in isolation. Treating data as an asset valued against its use, and naming what makes it findable, accessible, interoperable and reusable, are both well established 1][2]. What matters is forcing each question to end in a decision. That is how Synaform's [Data service works in Playground: the record is connected and modelled, and the question in front of you decides which of these properties count.
Sources
- [1] Douglas B. Laney, Infonomics: How to Monetize, Manage, and Measure Information as an Asset for Competitive Advantage, Bibliomotion / Routledge, 2017.
- [2] Mark D. Wilkinson et al., "The FAIR Guiding Principles for scientific data management and stewardship", Scientific Data 3, 160018 (2016). https://doi.org/10.1038/sdata.2016.18