Data strategy consulting is the work of deciding which recurring decisions in a business are made badly for want of knowledge, what knowledge would improve each one, where it has to live to be retrievable at the moment the call is made, and who is allowed to see it under what authority. Vivaldi advises on that. We do not build warehouses, write pipelines, run migrations or operate a governance function, and that limit is why our answer on scope is usually much smaller than an implementation partner’s.
- Since 1999demand, commercial and customer strategy
- 200+published case studies
- 10 officeson four continents
- Advisory onlywe specify the work, your teams and build partners deliver it
- No vendor tiesour advice on tooling carries no commercial stake
When companies bring us in
- The investment is large and the answers are still generic. Years of platform spend, a capable data function, and an executive question that still gets answered from instinct.
- Before a multi-year data program is signed. A target state architecture is about to be funded and nobody has named the decisions it is meant to improve.
- When an AI pilot returns fluent nothing. The system answers from general training rather than from your organization’s knowledge, because that knowledge is not retrievable.
- When governance has become a committee. There is a policy, a steering group and a classification scheme, and people route around all three to get work done.
- When two functions hold the same question differently. Commercial and operations produce different numbers for the same thing and the argument is about the data rather than the decision.
Why a data maturity roadmap does not survive contact with a budget
The standard opening is an estate-wide assessment: current state, target state, a maturity score and a sequenced multi-year plan. It is thorough, it is defensible, and it defers value until everything is fixed. Everything is never fixed.
The score is the weakest part of it. Readiness varies enormously by domain, so an average across the estate describes nowhere in particular. A business can be genuinely ready to ground a pricing decision and nowhere near ready to ground a service one, and a single number hides exactly that difference.
The phrase data-driven decisions has been in general use for twenty years and has stopped carrying information. Three narrower questions do carry information, and each has a different owner:
- Readiness. Is the knowledge for this decision accessible, current and trustworthy enough to act on, asked one decision at a time
- Currency. Knowledge decays, and a system grounded in last year’s reality is confidently wrong in a way that fails quietly
- Precision. Retrieving ten relevant things beats retrieving a thousand adjacent ones, so volume is the wrong ambition
If a firm cannot answer those three for a named decision, a maturity score will not rescue the program.
What our data strategy consulting services include
Four bodies of work. Most engagements start with the first and stop where the value runs out, and each can be engaged on its own.
- AllThe data estateEvery system, document store and feed the organization holds, which is the scope an estate-wide assessment quietly commits you to fixing
- NamedRecurring decisions with an ownerThe calls made on a cycle by a person we can name, rather than the capabilities an architecture diagram implies
- RankedDecisions worth grounding betterRanked by what a better version of the decision is worth, not by how available the data happens to be
- SpecThe smallest architecture that serves themWritten as a specification your teams or a build partner can price, with the rest of the estate deliberately left alone
1. A decision inventory before a data inventory
We start with the people who make recurring decisions and work backwards to the knowledge each one needs. Starting from available data produces projects looking for a use.
- The decisions named individually, with the person who owns each and how it is made today
- What knowledge would improve each one, where it currently lives, and whether it is current enough to trust
- The decisions ranked by value at stake, and the ones we recommend leaving alone, named explicitly
2. Knowledge architecture
How organizational knowledge is structured so the right person or system can retrieve it at the moment of a decision. This is the part most often skipped, because it looks like librarianship rather than engineering.
- How knowledge is organized, named and related, so retrieval is precise rather than broad
- Ownership, review cycles and decay signals that flag stale content before it misleads someone
- What has to be written down deliberately, because knowledge that exists only in a conversation is a dependency rather than an asset
3. Grounding, lineage and permission by design
Governance belongs at the point of retrieval, which is the only place it reliably holds, because that is where the request and its context both exist.
- Who may see what, under what authority, with an audit trail, specified as a design requirement rather than as policy
- Provenance, so an answer can be checked, because nobody senior acts on an answer they cannot trace
- Classification proportionate to sensitivity, so controls built for the difficult tenth of the estate do not slow the ordinary rest of it
- A named owner per domain, because governance without an owner is a document
4. A specification someone else can build against
Our output is a decision, written so it can be priced and delivered by people who build for a living. We stay available while it is built and we do not bid for the build.
- The target capability described by what it has to answer, for whom, at what latency and with what provenance
- The evaluation that tells you retrieval quality has degraded, rather than discovering it through a bad decision
- Selection criteria you can run yourself, since we hold no partnership with any platform or model provider
Not sure which decision to start with?
Start with a working session with one of our partners. We will take a single recurring decision, establish what grounding it properly would be worth, and test whether what you already hold supports it.
How a data strategy engagement works
- Inventory. Interviews with the people who make the recurring decisions, a map of how each is made today, and a ranking by what a better version is worth.
- Diagnose by decision. For the top decisions only, what knowledge is missing, where it sits, how current it is and what stops it reaching the moment of the call.
- Design. Knowledge architecture, retrieval, lineage and permission for those decisions, plus the ownership and review cycles that keep them current.
- Specify and hand over. A build specification your teams or an implementation partner can price, with an evaluation method and a measurement line from the decision to the business result.
Why companies choose Vivaldi for data strategy work
- We start at the decision, not the estate. The value case comes before the architecture, which is the step that decides whether any of it gets used.
- We do not build it, and we say so first. No implementation revenue sits behind our recommendation, so the smallest honest scope is also the one that pays us.
- No platform or model partnerships. Our advice on tooling carries no commercial stake, which is not true of most firms offering this work.
- Commercial strategy is the frame. We have advised on demand, commercial and customer strategy since 1999, so the question we ask about a dataset is what decision it changes.
How to evaluate a data strategy consultant
Worth asking of any firm on your shortlist, including us.
- Ask them to scope by decision. A firm that opens with a maturity model and a target state architecture is quoting you the whole estate. Ask which ten decisions get better first.
- Ask what they will not fix. Every honest engagement leaves parts of the estate alone. A firm that finds everything critical has prioritized nothing.
- Ask where governance sits. If the answer is a policy document and a committee, governance is beside the workflow and will be routed around within two quarters.
- Ask how currency is maintained. Knowledge systems fail slowly and quietly. Named ownership, review cycles and decay signals are the answer, and nobody enjoys giving it.
- Ask who gets paid for the build. A recommendation from a firm that will also deliver the implementation is not the same artifact as one from a firm that will not.
Data strategy consultancy, implementation partner or in-house data team?
| Criterion | Data strategy consultancy | Data engineering or implementation partner | Your in-house data team |
|---|---|---|---|
| What it decides | Which decisions are worth grounding better, what knowledge each needs and how it is governed | How data is collected, stored, modeled, served and secured | What gets built next within an agreed architecture |
| Typical deliverables | Decision inventory, knowledge architecture, permission and lineage design, a build specification | Pipelines, storage, retrieval infrastructure, migrations, running governance tooling | Reporting, models, platform operation, day to day stewardship |
| Who signs it off | The decision owner and the CDO or CIO together | CDO, head of data engineering or IT | Head of data |
| Commercial stake in the answer | None in the tooling, and none in the size of the build | Direct, since the recommendation is usually the scope of work | Internal, and usually tied to the existing estate |
| Best when | The spend is already large and the answers are still generic | The decision and the architecture are settled and you need it built | The architecture holds and the backlog is the constraint |
Where our data strategy work stops
We are a strategy firm, so this page claims advice and not delivery. We do not build or operate data platforms, write integration code, run migrations, staff a governance office or resell tooling. We have no published data strategy case studies, which is why there are no results or client figures on this page: a firm with no proof to show should say so rather than borrow proof from adjacent work. What we bring is the decision frame and the specification, and we are candid that the build belongs to someone else.
Four neighboring services answer questions this page does not, each a single step away. If the knowledge exists and the problem is that two systems will not hand it to each other, the decision sits with API and systems integration. If the data is available and the open question is whether the design calls in front of you are being made on evidence rather than on taste, start with digital interaction design. If the knowledge that matters most is generated by participants outside your own boundary, that is AI-driven ecosystem strategy. If the constraint is how quickly anything can be shipped at all, the delivery and platform decisions above the build sit on technical and DevOps architecture.
Related work
- Digital product consulting for the group this capability sits in, if the real question is which products and platforms to build at all.
- Predictive and advanced analytics if the data is good enough and the gap is the commercial prediction that would act on it.
- Machine learning, predictive analytics and AI strategy for model development, evaluation and AI model choice.
- AI technology consulting if the prior question is where artificial intelligence changes your economics at all, and in what order.
Our view on why so much of this investment returns so little is set out in the AI paradox. This work sits inside our business technology strategy practice at Vivaldi, the strategy firm behind the Demand Landscape and the Interaction Field.
Data strategy consulting in the US and worldwide
Vivaldi is headquartered in New York and has a second US office in Los Angeles. Outside the US we work from London, Zürich, München, Hamburg, Düsseldorf, Singapore, Buenos Aires and Lima. Data residency, retention and permission rules differ by market, so a knowledge architecture that is compliant in one place is often not portable to another. We scope the design per market and reuse the decision inventory rather than the configuration. Read who Vivaldi Group is and how we work.
Start with one decision that keeps going badly
One working session on a recurring decision, what it is currently grounded in, and what it would take to ground it properly. You leave knowing whether the program is worth funding and how small the first phase can be.