An enterprise data architecture strategy is what a business has to settle before it can evaluate a platform meaningfully: which decisions the data exists to support, which system owns each domain, how information should move, at what grain it should be stored, who answers for each figure, and what the operating constraints are. Settle those six, and the platform question narrows to something testable. Skip them and the selection process becomes a comparison of vendor differentiators against requirements nobody has written down.
Why Platform-First Selection Goes Wrong
The sequence that causes the trouble is familiar. Reporting is unreliable, leadership asks for a fix, someone is tasked with evaluating options, and an RFP goes out. Vendors respond with capability matrices. The evaluation compares features that all three finalists have, in slightly different arrangements, and the decision gets made on demonstration quality, commercial terms, or an existing relationship.
None of that is unreasonable behavior. It happens because the questions that would differentiate the options have not been asked yet, so the only available comparison is the one the vendors supplied.
The cost shows up during configuration. Every decision the strategy should have made gets made anyway, by an implementation team under delivery pressure, one ticket at a time. Those decisions then sit inside the platform, unlabeled, and become the de facto architecture. Two years later, nobody can say why the customer domain is modeled the way it is.
The Six Decisions That Have to Come First
- What the data is for. Start from the decisions leadership makes and works backward, rather than starting from the data that happens to exist. This narrows scope sharply. Most businesses discover that a large share of what they were planning to migrate supports no decision anyone makes.
- The system of record for each domain. Customer, product, transaction, employee, asset. One authoritative system each, and a written tie-break rule for the day a rival system reports a different figure. This is a business decision, not a technical one, and no platform can make it on your behalf.
- Integration patterns. Whether movement is batch or streaming, whether transformation happens before or after loading, and whether systems connect directly to each other or through a common layer. This single decision has more influence on long-term cost than the platform choice does, because it determines whether adding the next system is a small job or a large one.
- Modeling approach and grain. The level of detail at which information is retained. Grain is the decision most often made by accident and least often reversible without reprocessing history. If revenue is stored at entity level, no reporting tool will later produce it by product line.
- Accountability. A named owner per domain, and the approval path a definition change has to travel before it takes effect. Platforms provide mechanisms for enforcing this. None of them supplies the answer.
- Operating constraints. Latency expectations, retention obligations, data residency requirements, access and security rules, and the skills your team actually has. These are the criteria that genuinely separate platforms, and they are usually documented last.
Six decisions, then the shortlist. Stratiform Group helps leadership teams settle the structural questions before a platform commitment fixes them in place.
What Changes Once Those Are Settled
The evaluation becomes specific. Instead of asking whether a platform supports streaming, you ask whether it supports the three streaming cases you identified, at your volumes, with your latency requirement, using skills your team has or can hire for in your market.
Vendor demonstrations stop being persuasive in the abstract, because you now have your own test cases. The shortlist usually shortens on its own, and occasionally the honest conclusion is that the existing estate can meet the requirement with better structure and no new platform at all.
There is a second benefit that matters more over time. The decisions are now written down outside the platform. When the vendor is changed, or the implementation team rolls off, or a new CFO arrives, the reasoning survives. Architecture that exists only as platform configuration is architecture that leaves with the people who configured it.
Where Platform Choice Genuinely Matters
Platforms are not interchangeable, and nothing above claims they are. They differ, and the differences are real on specific axes: how they handle semi-structured data, how compute and storage are billed and scaled, how well they fit an existing Microsoft or cloud estate, the maturity of their governance tooling, and what skills the local hiring market can supply.
Microsoft Fabric, Databricks, and Snowflake each have situations they suit better than the others, and Azure services and Power BI sit around them in most mid-market environments. The point is that those differences only become decisive once you know your own volumes, latency requirements, workload mix, and constraints. Before that, every difference looks equally important, which is the same as none of them being important.
What This Does Not Mean
It does not mean a long strategy phase before anything happens. That is the failure mode on the other side, and it is real: a strategy exercise that runs for months, produces a comprehensive document, and ends with nothing built and the original problem unchanged.
The six decisions above are answerable inside a few weeks at mid-market scale, because the number of domains is finite and the constraints are usually already known by people inside the organization. The work is mostly getting the right people to agree and writing it down, not original research.
It also does not mean freezing procurement. Vendor conversations can run in parallel and are often useful for pressure-testing assumptions. What should not happen in parallel is signing.
A Test Before You Sign
Before committing to a platform, check whether you can answer these without opening a vendor document.
- Which three decisions will this platform improve, and how would we know?
- Which system is authoritative for our customer record, and what happens when another system disagrees?
- At what grain will transaction data be retained, and what reporting does that grain make impossible?
- When a new system is acquired, what is the standard pattern for connecting it?
- Who approves a change to the definition of a reported measure?
- What is our actual latency requirement, and which reports depend on it?
If several of these send someone off to find out, the strategy work has not been done yet, and the platform decision will make it anyway, less deliberately.
Where This Connects to the Rest of the Work
Strategy sets direction. Enterprise data architecture expresses it as a structure. Data infrastructure builds and operates it. Reporting delivers what it was designed to produce.
Work done out of that order still gets delivered. It just gets delivered against assumptions that were never examined, which is why implementations can be technically sound and still fail to change what leadership is able to decide.
Settle the Strategy Before the Shortlist
If you are weighing a platform decision now, the useful question is not which vendor is strongest. It is whether your organization has decided what the platform must do, at what grain, moving through which patterns, and under whose ownership.
Stratiform works with leadership teams on those decisions and on the sequencing that follows, so the platform choice becomes a consequence of the strategy rather than a replacement for it.
Make the platform decision the last decision, not the first. A structured review establishes requirements, target structure, and selection criteria you can actually test against.