Most data architectures weren't designed — they accumulated. A warehouse added here, a pipeline bolted on there, a reporting layer that nobody quite owns. The result is a system that works just well enough to avoid being replaced, but poorly enough to cause daily frustration.

The good news: the tooling landscape has matured to the point where a genuine rethink is now within reach for almost any organisation. The bad news: most data reboots fail not because of technology choices, but because of the assumptions that precede them.

Start with the questions, not the tools

The first mistake teams make when redesigning their data architecture is reaching for a solution before they've fully articulated the problem. What decisions does this architecture need to support? Who makes them, and on what cadence? What does "fresh enough" mean for each use case?

These aren't technical questions — they're business questions. And they determine everything downstream: whether you need real-time or batch, centralised or federated, a lakehouse or a warehouse, a catalogue or a tight schema.

Design for the team, not the ideal state

A technically superior architecture that your team can't maintain is worse than a simpler one they can. Skill availability, team size, and existing habits should be first-class inputs to architectural decisions — not afterthoughts.

This doesn't mean settling for mediocrity. It means sequencing the ambition. Build what your team can own today, with clear onramps to what you'll need in two years.

Interoperability over integration

The most resilient architectures are the ones that don't assume permanence. Vendor lock-in is less of a risk when you've built with open formats, standard interfaces, and clear separation between compute and storage. The goal is a system that can evolve — not one that needs to be replaced every three years.

A data reboot isn't just a technical project. Done well, it's a forcing function for the organisation to get clearer about how it makes decisions, who owns what, and what "good data" actually means in practice.