Data Contracts Are Promises, Written Down
A data contract is a promise between the team that produces data and the teams that depend on it. Most data breaks because that promise was never written down.
Type above to search across every perspective.
A data contract is a promise between the team that produces data and the teams that depend on it. Most data breaks because that promise was never written down.
If you cannot explain where a number came from, should an executive make a decision with it? Lineage is the quiet precondition for trusting data at all.
Enterprise AI does not fail because the models are weak. It fails because organisations deploy them faster than they can govern them. Governance is the enabler, not the brake.
The label ‘data product’ has become fashionable. The idea underneath it is sound — and demanding. It asks teams to treat data with the same rigour they would any product people depend on.
An organisation can be rich in data and poor in trust — and it is trust, not data, that is spent when a real decision is made.
The question every board eventually asks about AI is the hardest one to answer well: what did it change? Measuring AI honestly is less about dashboards and more about deciding what counts.
Data mesh is not decentralisation for its own sake. It is giving ownership to the people closest to the data — and holding them to one shared standard.
Trust in data is not established by a platform or a policy. It is earned slowly, through consistency, and lost quickly, through a single number that turns out to be wrong.
Delivering programmes is the price of entry for a technology leader, not the job itself. The harder, less visible work is judgement: knowing what to build, what to stop, and what to defend.
Organisations are drawn as boxes, but the hardest work lives on the lines between them — where ownership is unclear and no one is quite responsible.
Cloud in financial services is rarely a technology problem and almost always an organisational one. The institutions that succeed treat it as a change in how they operate, not just where they run.
Transformation programmes are described in terms of systems and timelines, but they succeed or fail on something harder to plan: whether people can and will work differently.
Every organisation wants AI. Far fewer want to do the unglamorous work it depends on. AI does not fix poor data — it industrialises it, at speed and scale.
AI does not make enterprise architecture obsolete. It raises the cost of not having one — because AI is only as good as the data, systems and boundaries it inherits.
Strategy documents describe intent. Operating models decide what actually happens. When the two disagree, the operating model wins — every time.
Capital markets organisations build sophisticated data platforms and then wonder why adoption lags. The gap is usually not capability. It is a platform built for engineers rather than the business it serves.
Uncertainty is used to excuse a lot of loose delivery. In reality, the less certain the outcome, the more disciplined the delivery has to be — just disciplined about different things.
Lift-and-shift gets an organisation to the cloud. It rarely gets it any benefit. The value is in modernisation — and modernisation is a decision, not an inevitability.
The fear that governance will smother AI is understandable and, handled badly, justified. But the choice between speed and control is a false one. The right governance is what lets teams move quickly and safely.
Choosing proven, unremarkable technology is often the most sophisticated decision a leader can make. Novelty has a cost that is easy to underestimate and hard to unwind.
Transformation programmes are rich in metrics and poor in meaning. Measuring what matters begins with an uncomfortable question: if this succeeds, what will be different — and for whom?