I have spent a good part of my career around data-platform decisions — through architecture, engineering, analytics, cloud and governance.
One pattern keeps returning: the conversation often starts too late.
By the time someone asks, “Which platform should we choose?”, several more important decisions may already have been made — sometimes without anyone explicitly making them.
What business decisions are we trying to improve? Which workloads genuinely matter? Where does the data already live? How much engineering complexity can the organisation sustain? What needs to be governed centrally? Which capabilities do we actually have? What kind of cost variability are we prepared to manage?
If those questions remain implicit, a technically capable platform can still become a poor fit for the organisation around it.
Don’t begin by asking which data platform is best. Begin by defining what the platform must make easier, safer and economically sustainable.
Product capabilities matter. Ecosystem fit matters. Commercial terms, support and roadmaps matter.
But they are more useful when judged against an explicit operating need than when they are allowed to define that need in the first place.
Change: the categories are converging, but the decisions are not
The data-platform landscape used to be easier to describe.
Warehouses served structured analytics. Data lakes handled large and varied datasets. Separate tools covered engineering, machine learning, streaming and business intelligence.
Those boundaries have blurred.
Modern platforms increasingly span workloads that once required separate technologies. That is useful, but it creates a new challenge: feature lists can make competing platforms look more alike than they really are.
The important differences often sit below the feature name.
Where does control actually live? How is compute acquired and isolated? Which storage formats and interfaces are native? How does identity travel across environments? What remains the customer’s responsibility? How easy is it to understand the resulting cost?
A checklist can tell you that several platforms support data engineering.
It cannot tell you which one fits an organisation whose strongest capability is SQL, whose analytics estate revolves around a particular semantic layer, whose data is concentrated in one cloud, whose AI teams need different patterns, or whose workloads experience unpredictable concurrency.
Feature convergence makes context more important, not less.
Fit: start with the Platform Decision Stack
Before comparing products, I make six parts of the decision explicit.
I call this the Platform Decision Stack.
The point is simple: use one language to define the need, then use the same language later to evaluate credible platform choices.
1. Business decisions and outcomes
Start with the decisions the platform should improve.
What should become faster, better evidenced, more reliable or easier to automate?
A platform supporting statutory finance reporting is solving a different problem from one supporting real-time pricing, supply-chain optimisation, clinical research or customer-facing AI.
“Become data driven” and “create a single source of truth” are useful aspirations.
They are not yet architecture requirements.
Without a more specific outcome, selection can drift towards familiarity, existing vendor relationships or the most compelling demonstration.
2. Representative workload portfolio
There is rarely such a thing as the organisation’s “average workload”.
Write down the real portfolio: batch ingestion, streaming, warehouse queries, semantic models, notebook engineering, machine learning, data sharing, APIs, AI retrieval and reporting.
Then distinguish common workloads from differentiating workloads.
Most credible platforms handle many common scenarios well.
The useful question is what happens with the workloads that matter disproportionately to your organisation.
That is where architectural differences begin to matter.
At this stage, the goal is to define the workloads that matter, not to build every one of them on every possible platform.
3. Data gravity and interfaces
Where does the data originate today?
Which datasets are costly, risky or difficult to move? Which consumers need SQL, files, APIs, events or semantic models? Which applications, partners or regulators require data to cross a boundary?
Data gravity is not simply about volume.
It includes identity, networking, residency, egress, contracts, source-system ownership and the applications that already depend on the data.
Moving the data may be technically straightforward.
Moving everything that surrounds it is usually much harder.
4. Governance and decision rights
Governance is often discussed as a product capability.
That is only half the question.
The more useful design question is:
Who is allowed to decide what?
What must be controlled centrally? What should domains own? Who approves access? Who owns quality? Who resolves policy exceptions?
Those answers shape catalogue design, policy enforcement, lineage, data-product ownership and environment isolation.
A platform can provide sophisticated governance technology and the organisation can still struggle if ownership and decision rights remain unclear.
Technology can enforce policy; it cannot decide who should own the policy.
5. Operating capability and skills
Platform architecture is also organisation design.
Look beyond the skills listed in a survey to where the organisation has real depth.
Can teams operate Spark-centric engineering, SQL-based transformation, infrastructure automation, semantic modelling, capacity management, model operations and production support?
A managed platform does not eliminate operating responsibility.
It changes it.
So rather than asking “Is this platform managed?”, I prefer:
“What remains our responsibility, and are we organised to carry it?”
A strategy that requires a different talent model may still be right.
But that capability transition should sit in the investment case, not remain hidden inside the architecture.
6. Economics and reversibility
List price is not the economic model.
Consider ingestion, transformation, storage, compute, concurrency, networking, data movement, development environments, observability, governance, security, support and people.
Then ask what would make this platform expensive to leave.
Lock-in is not only proprietary code.
It can accumulate through skills, operating processes, security policies, semantic models, marketplace dependencies, integration patterns and commercial commitments.
Open formats can improve technical portability.
They do not automatically make an operating model portable.
The vendor is the final variable — not the starting assumption.
Where AI changes the conversation
AI belongs in the workload portfolio.
But where AI is strategically important, it also reshapes other parts of the stack.
It can change data gravity, because enterprise AI may need to bring together governed structured data, unstructured content, retrieval patterns and model access.
It changes economics, because inference, tokens, specialised compute and retrieval introduce different cost drivers.
And it raises additional control and provenance questions.
For important AI-generated outputs, organisations need to understand what data grounded an answer, what model or configuration was involved, what controls applied, and how an output can be investigated when something goes wrong.
So I would resist evaluating AI through the showcase demo.
If AI matters to the strategy, put representative AI workloads into the evaluation and subject them to the same deployment, security, governance, observability and economic discipline as everything else.
Reality: platform selection can fail in the evaluation design
Most enterprise platform selections contain plenty of activity — workshops, demonstrations, proofs of concept, architecture discussions, feature matrices, commercial negotiations and scorecards.
The question is whether that activity is producing the right evidence.
Demo bias. A polished demonstration proves that a prepared path can work. It does not prove that your teams can make the ordinary path repeatable with your data, identity model, deployment process and support model.
Feature-parity theatre. Hundreds of capability rows can create the appearance of precision while hiding the handful of differences that actually affect architecture, adoption and cost. The useful question is not “Does the platform support this?” but “How does this capability operate in the architecture we would actually deploy?”
Ignoring the path to production. A proof of concept often concentrates on whether something can be built. Production asks different questions. How is access approved? How does code move between environments? How are policies deployed? What happens when a job fails? How is lineage captured and recovery tested? How does the support team investigate a cost spike?
Treating skills purely as a training problem. Training can close a knowledge gap. It takes longer to build engineering judgement, architecture patterns, operating discipline and domain ownership. If the platform decision implies a significant capability transition, make it visible.
Forcing one platform to win every workload. Standardisation has genuine value. It can reduce duplication and operational fragmentation. But it does not have to mean that every workload follows exactly the same technical path.
A useful architecture may set a strategic default for common workloads while allowing governed exceptions where a specialist requirement justifies the added complexity.
When the platform names finally enter the conversation
This is usually the point at which specific products become useful.
In many enterprise conversations I have seen, the eventual shortlist includes platforms such as Microsoft Fabric, Databricks and Snowflake.
That is understandable. Their capabilities increasingly overlap, even though their architectural choices, workload patterns, governance models and economics are not identical.
The point is not to recommend one over another.
It is to treat each platform story as a hypothesis.
Consider a composite enterprise with a significant Microsoft estate, an established Power BI community, SaaS and operational source systems, an expanding data-science function, streaming requirements and partners operating across more than one cloud.
One hypothesis might be that Fabric reduces some seams in a Microsoft-oriented analytics estate.
Another might be that Databricks fits teams with strong engineering, streaming, ML and lakehouse requirements.
A third might be that Snowflake fits an operating model that values independent compute, SQL-oriented analytics patterns and a highly managed platform experience.
These are hypotheses to test, not conclusions.
But this does not mean building the full workload portfolio on every platform.
The representative workloads help shape the shortlist first.
Then validation should focus only on the areas where the shortlisted platforms differ materially, where a claim remains uncertain, or where the delivery risk is significant.
Define broadly. Shortlist intelligently. Validate selectively.
Outcome: turn selection into a staged architecture evaluation
A credible platform decision does not require every workload to be tested on every product.
The objective is to reduce uncertainty progressively.
1. Fix the non-negotiables
Document the boundaries that cannot be traded away: residency, regulatory obligations, recovery objectives, supported clouds, identity standards, critical interfaces and significant commercial constraints.
These become early filters.
2. Define the representative workloads
Identify the workload portfolio before choosing the technology.
Select scenarios that expose the architectural differences that matter — not because every scenario must immediately become a proof of concept, but because they give the evaluation a common basis.
Include both common workloads and the differentiating workloads that carry more business or architectural weight.
3. Build a credible shortlist
Use the Platform Decision Stack, current product capabilities, ecosystem fit, operating capability and commercial reality to narrow the field.
A practical evaluation should focus on a small number of credible options rather than trying to test the entire market.
At this point, published evidence, architecture analysis, existing experience, reference patterns and commercial feasibility should eliminate choices that do not deserve deeper validation.
4. Validate where uncertainty matters
Test the shortlisted platforms selectively against the workloads that genuinely differentiate them or carry material risk.
Use realistic identity boundaries, representative data volumes, deployment practices, security controls, observability, recovery and cost attribution.
Do not build a proof of concept simply to prove something already well established.
The objective is to test the uncertainty, not reproduce an entire production estate three times.
5. Compare the evidence and record the decision
Bring together architecture fit, operational experience, unit economics, capability implications and accepted trade-offs.
Record why the selected platform fits, which assumptions the decision depends on, where exceptions are permitted, what dependencies are being accepted and what evidence would cause the decision to be revisited.
Reversibility does not mean refusing proprietary capability.
It means adopting it deliberately, understanding both the advantage being purchased and the dependency being accepted.
Define the workloads before the shortlist. Test the uncertainties after the shortlist.
What the scorecard should reveal
Once the organisation has defined the Platform Decision Stack, the final evaluation should use the same language.
That gives traceability from the original business and operating problem through to the eventual platform decision.
Outcome fit — Does it materially improve the decisions and products that justified the investment?
Workload fit — Can it carry the representative portfolio without unnecessary duplication or awkward service boundaries?
Data-gravity fit — Does it fit where the data resides and the broader technology estate surrounding it?
Control fit — Can identity, policy, lineage, quality, access and audit be operated end to end?
Capability fit — Can the organisation build, govern and support it through a credible capability plan?
Economic fit — Are the important cost drivers visible, attributable and sustainable as usage grows?
Reversibility — Can the architecture evolve without making every future strategic change a major migration programme?
A weighted model can help structure the discussion.
But a platform scoring 4.2 instead of 4.0 means little if the assumptions behind those numbers cannot be explained.
The written evidence matters more than the precision of the score.
The Decode
The point of platform selection is not to identify a universal winner.
It is to identify the technology and operating model that fit the organisation you actually have — and the one you are deliberately trying to become.
Start with the outcome.
Understand the workload portfolio.
Make data gravity, governance, capability and economics visible.
Use that context to build a credible shortlist.
Then test only the uncertainties that matter.
Choose a strategic default without pretending every workload is identical.
Record both the advantage being acquired and the dependency being accepted.
Then choose the platform.
By that point the decision should feel much less like a product contest.
It should feel like architecture.