Enterprise Cheatsheet to Build Data Architecture
How to build enterprise data architecture
Northwind Logistics (a fake company) hired a sharp data science team, gave them a budget, and told them to “modernize decision-making.” Eight months later they had a beautiful model that predicted late shipments with 94% accuracy. It sat in a Jupyter notebook. Nobody outside the data team could run it, nobody downstream trusted its output enough to act on it, and the dispatchers kept making calls off a spreadsheet that hadn’t been touched since 2019.
This is the most common failure mode in enterprise AI, and it has nothing to do with model quality. The model was fine. What Northwind was missing was everything around the model: a way to get clean data into it, a way to turn its output into something a human could recognize as “this truck” or “that customer,” and a way to route a decision to the person who actually needed to make it.
That gap is what a proper AI platform architecture is supposed to close. And the answer to “do we need to buy into someone’s whole ecosystem to get this” is no. You can build it standalone, and you should understand what “standalone” actually requires before anyone sells you a shortcut.
The five things nobody puts on the roadmap
You are at an airport. Somewhere below the tarmac, baggage handlers move thousands of items from planes to belts to customs to the right owner, hour after hour, without most passengers ever thinking about it. That’s data integration. It’s unglamorous by design. Connectors that pull from a hundred different source systems, quality checks that catch a corrupted feed before it poisons everything downstream, versioning so you can tell what changed and when. Nobody praises the baggage system when it works. Everyone notices when it doesn’t.
Above that sits the fleet itself, different aircraft from different manufacturers, each with its own maintenance quirks, all needing to operate on the same runway. That’s model integration. A platform that forces every model into one proprietary format is an airport that only accepts one plane manufacturer. What you actually want is support for the runtimes people already use, PySpark and R showing up as first-class citizens instead of afterthoughts, standard package managers, model formats that don’t trap you.
Then there’s air traffic control, and this is the layer most teams skip entirely. ATC doesn’t see planes. It sees a radar blip and turns that blip into “Flight 448, a Boeing 737, currently at 12,000 feet, cleared to descend.” That translation from raw signal to meaningful object is the whole job. That’s the ontology layer: the thing that takes your tables and your model scores and turns them into “this customer,” “this shipment,” “this at-risk delivery,” with the relationships between them intact. Without it, every team downstream reinvents its own private interpretation of what a row in a database actually means, and those interpretations quietly drift apart.
Above ATC, gate agents and ops staff work the actual operation. Someone reviews a delayed connection and rebooks a passenger. Someone escalates a mechanical issue. That’s workflows, the layer where a person filters, reviews, and takes action on live data through an interface built for the job, not a spreadsheet somebody exports every Monday.
And at the very top, the control tower makes the calls that everything else has been feeding into: hold this flight, clear that runway, divert around weather. That’s decision orchestration, structured and auditable, so when someone asks “why did we do that” six months later, there’s an actual trail to point to.
Here’s the visual represention of stack, bottom to top, data flowing up into decisions:
