Discover the best Data Vault automation software for modern data platforms - Learn more
Ignition | 26 August 2026
The pilot worked. That is usually how it starts. Someone builds something over a few weeks, demonstrates it to the leadership team, and the response is enthusiastic enough that it gets a budget and a mandate to scale.
Then it stops. Not dramatically, and rarely with a formal decision to cancel. It just gets slower, acquires a longer list of caveats, and eventually stops being mentioned in the monthly report.
When that happens, the post-mortem tends to focus on technology. Wrong model, wrong vendor, wrong architecture. Occasionally, that is true. More often the technology was fine, and the organisation was not ready to operate the thing it had built.
Readiness is not primarily an architectural question. It is a question about who owns what, who decides what, and whether your organisation agrees with itself about what its own data means. Here are five questions that will tell you where you stand, and none of them require a technical answer.
The arguments get shorter. A shared vocabulary means the debate about the business key stops being a matter of opinion and starts being a matter of applying a standard. Teams that have been through certification together spend less time relitigating decisions that the methodology already has a position on, and more time on the genuinely ambiguous cases that deserve the discussion.
Standards outlive the people who set them. Most data platforms are built by a rotating cast: permanent staff, contractors, an implementation partner, then a different implementation partner. When conventions live in one architect’s head, they leave when that architect does. When they live in a methodology the whole team has been trained in, a new starter can read the existing model and understand why it looks the way it does without an archaeology exercise.
Rework at integration drops. The expensive failures are rarely visible in the sprint that causes them. They surface later, when two subject areas built by two different squads need to join and the entity resolution does not line up. Consistent modelling upfront is unglamorous work that mostly announces itself through the absence of a crisis six months later.
Onboarding gets faster. If your partners and contractors hold the same certification, you are not spending the first fortnight of every engagement negotiating conventions. As one of our clients at Central Queensland University put it, with Data Vault “teams spend less time writing code for repeatable processes.” The same logic applies to the time spent agreeing on how to do things.
Pick a figure from an executive dashboard and trace it back. How many people do you need to ask, and how long does it take?
This is the question that determines whether you can defend an automated decision to a regulator, a customer, or a board. If reconstructing the derivation of a single number takes a week and three conversations, you are not in a position to explain why an automated system declined an application.
The organisations that handle this well are not necessarily the ones with the best tooling. They are the ones where the lineage was captured as the platform was built rather than reconstructed afterwards.
Ask finance, sales, and operations for their definition of an active customer. Then compare them.
Almost every organisation finds three different answers, and almost every organisation has been operating perfectly well that way for years, because each function applies its own definition within its own domain, and nobody must reconcile them. Reporting tolerates this. A model trained across all three does not. It learns from the inconsistency and produces outputs that are subtly wrong in ways that are very hard to detect.
Resolving definitional conflict is slow, political work. It is also the single highest-value preparation most organisations can do, and it does not require any technology at all.
Source systems change constantly. Fields get added; a vendor is replaced; a merger introduces a second instance of something you already had.
The question is what costs you. If a schema change in an upstream system triggers weeks of re-engineering downstream, you have a platform that will absorb your capacity in maintenance and leave nothing for the work you want to do. Every hour spent reworking existing integrations is an hour not spent on the thing the AI investment was meant to enable.
This is the one question on the list where architecture genuinely is the answer. A structure that separates stable business entities from the systems that happen to hold them absorbs change rather than propagating it. That is the reasoning behind the Data Vault 2.1 methodology and the reason it underpins the platforms we build. But it is worth noticing that the previous three questions had nothing to do with architecture at all.
Somewhere in your organisation there is data that should not be used to train anything, and data that can be used internally but not exposed to a customer-facing system.
Who makes that call? Is there a process, or does it happen case by case when someone remembers to ask? Is the classification recorded anywhere a system can read, or does it live in someone’s judgement?
Most organisations discover they have no answer to this at the point where they need one urgently, which is the worst possible time to invent a governance operating model.
Research from Dremio last year found that 85% of organisations are using Lakehouse architectures for AI model development, while 36% report struggling with data governance. That gap is the story. The infrastructure question is largely settled. The organisational question mostly is not.
None of the five questions above require a platform decision, a vendor, or a budget approval. They require a couple of uncomfortable conversations, and the answers will tell you more about your readiness than any architecture review.
If you want a structured version of this exercise, our Data Maturity Self-Assessment takes about ten minutes and gives you a view of where your organisation sits across governance, architecture, quality, and capability. For organisations that want the full picture, our Data Maturity Assessment goes considerably deeper and produces a prioritised plan.
Either way, it is worth knowing the answers before the pilot rather than after it stalls.
.png?)
