Enterprise Data Modeling for AI: 5 Lessons from 30 Years of Data Architecture

5 lessons from 30 years of enterprise data modeling with John Giles

We’ve all heard that “your AI is only as good as your data”. But what does it actually mean? What all those screaming titles mean is the following: to get accurate answers from an AI agent, the data it reads must be structured, documented, and semantically meaningful. Most enterprise data is not. It is a maze of undocumented tables, conflicting definitions, and models built by teams who never talked to one another.

John Giles has spent three decades fixing exactly that. A data modeling veteran and author of The Nimble Elephant and The Data Elephant in the Boardroom, Giles recently joined Serge Gershkovich from SqlDBM to share what he has learned about building data architecture that actually holds together – and why those lessons matter more than ever now that AI agents depend on your data to do their jobs.

Here are five of the most important insights from that conversation.

INSIGHT 1

The most common data architecture failure is tunnel vision

When Giles is asked what causes data initiatives to fail, he points to something that surprises people: the problem is usually not bad technology or a lack of talent. It is teams of talented people who are only focused on solving their own piece of the puzzle, with no visibility into how their work connects to the rest of the organization.

Each team builds its own tables, defines its own terms, and ships its own solution. The code works. The project delivers. But six months later, the finance team and the product team are reporting two different customer counts, and no one can explain why.

“If you basically look at a car’s carburettor, you won’t understand what a car is. You have to look at the whole to see how the parts fit together.”

Giles describes this as the absence of systems thinking: the failure to see how individual deliverables provide and receive value across the enterprise. Without it, organizations end up with duplicated efforts, conflicting metrics, and communication breakdowns that slow every subsequent project.

He illustrates the stakes with a story from the Australian Black Saturday wildfires. Incident controllers urgently asked volunteer organizations how many fire trucks they had. One agency called them appliances. Another called them tankers and slip-ons. The terminology was different enough to create dangerous confusion during a crisis. In enterprise data, the same thing happens every day, just with slower-moving consequences.

The fix is a shared information model: an agreed-upon vocabulary for the business’s core concepts that every team and every system can reference. That alignment is the foundation that makes everything else work — including, eventually, your AI agents.

INSIGHT 2

Your data needs a city plan, not a kitchen renovation

Most enterprise data modeling initiatives fail for one of two reasons: they start too late, after the technical debt is already crippling sprint velocity, or they try to do too much, spending years documenting every attribute in the company while delivering no value to anyone.

Giles proposes a different approach, which he calls a Data Town Plan. The name comes from the idea of urban planning: before you build individual structures, you establish a high-level map of the city: where the roads go, how zones connect, what the landmarks are. You do not, at this stage, pick the color of the tiles in the town hall kitchen. That is too much detail too early.

In data terms, a town plan is a lightweight conceptual model of your organization’s core entities — customers, products, assets, events, suppliers, employees — and how they relate to one another. It is not a physical schema. It does not prescribe data types or enforce referential integrity. It is a shared map of the business in just enough detail to keep every team pointing in the same direction.

“The data town plan is not going to pick the colour of the tiles in the town hall kitchen. That’s too detailed.”

The business case for spending time on this upfront is dramatic. Giles cites an agile team whose sprint velocity was slowing to a crawl: by sprint four, they were spending most of their time recoding and retesting work from sprints one, two, and three. An Agile coach convinced them to invest one sprint in sketching a conceptual model. The result was a 13-fold increase in delivery speed.

A town plan does not need to be perfect. It needs to be good enough for teams to stop making architectural decisions that contradict each other.

INSIGHT 3

Fifty percent of your data model already exists. Use it.

One of the most expensive habits in enterprise data is starting from scratch. Every organization deals with people, products, orders, events, and locations. The fundamental patterns for modeling these concepts have been documented, tested, and refined by data practitioners for decades. Yet most teams still open a blank canvas and reinvent them.

Giles points to the work of authors like Len Silverstone and David Hay, who have published reusable data model patterns covering the most universal business domains. His position is direct: use them.

His estimate: roughly 50 percent of a mature enterprise data model can be pulled directly from established generic patterns. Another 25 percent comes from patterns specific to your industry (eg. telecommunications, healthcare, financial services, and so on). Only the remaining 25 percent requires original thinking, the part that makes your organization genuinely distinct from every other.

Giles demonstrated this in practice when a telecommunications company hired him to deliver an enterprise model that a full team had been working on for years. With two weeks and a copy of Len Silverstone’s book as his baseline, he delivered a working enterprise model for an entire telco.

The point is not to copy blindly. It is to stop paying for the solved problems. Established patterns give teams a tested foundation. Customization happens on top of that foundation, not instead of it. Tools like SqlDBM now include these patterns natively, so teams can start with a battle-tested baseline rather than an empty canvas.

INSIGHT 4

Your business will never agree on one definition. Build for that.

Even with the best intentions, getting an organization to agree on definitions for core concepts is genuinely hard. And sometimes, the ambiguity is not a problem to eliminate — it reflects something real about the business.

Giles illustrates this with a health insurance provider that also operated dental clinics. A grandfather pays the insurance premium. He brings his frightened grandchild to a dental appointment. In that context, who is the customer?

“This poor little frightened kid sitting in the dentist’s chair — who is the customer? Granddad… or the frightened child?”

Both answers are correct, depending on what question you are asking. In the context of billing, granddad is the customer. In the context of the dental visit, the child is.

A well-designed data architecture handles this gracefully. The conceptual town plan captures a gold standard definition. The physical and logical layers are built flexibly enough to present different interpretations depending on context. By recording base transactions accurately, you can apply semantic logic on top: if you include dental visitations, here is one customer count; if you exclude them, here is another.

The lesson is not to pick one definition and enforce it everywhere. It is to capture the raw truth accurately and apply meaning deliberately, so that different teams can answer different questions from the same underlying data without conflicting with one another.

INSIGHT 5

AI agents need a semantic data model. Without one, they are guessing.

This is where the previous four insights converge, and why enterprise data modeling is seeing significant renewed interest from organizations that may not have prioritized it before.

An AI agent pointed at an undocumented, poorly structured database is not going to generate reliable insights. It will try — but without context, without semantic meaning, without a shared vocabulary that connects table names to business concepts, it is operating on pattern matching rather than understanding. The answers it produces will be confidently wrong.

“To get value from artificial intelligence, the AI engines need context, they need definitions. LLMs need a semantic model and a data town plan to consume, interpret, and generate accurate insights.”

Giles draws a direct line from the work of data modelers (like the conceptual blueprints, the shared vocabularies, the documented relationships) to the capability of AI systems. If a person cannot find the information they need in your data environment, an AI agent cannot find it either.

This changes the role of the data modeler. It is no longer a back-office technical function. It is the work that determines whether your organization’s AI investment returns value or returns hallucinations.

What to do starting next Monday

The principles Giles describes are not abstract. Here is how to begin applying them immediately.

1. Run a two-day alignment workshop before your next major project
   Stop gathering requirements in isolated one-on-one interviews, where inconsistencies hide. Get frontline workers and management in the same room. Use the session to map your organization’s core concepts ( customers, products, events, locations), and surface the places where different teams use the same word to mean different things. One workshop, done well, can prevent months of rework.
2. Start with patterns, not a blank canvas
   Before modeling anything from scratch, search for an established pattern that covers it. Universal business domains, like party management, product catalogs, order lifecycles, geospatial locations –  all have documented patterns. Use them as your starting point. Adapt them to your specifics. Do not pay to rediscover what has already been solved.
3. Pair technical and business bridge-builders
   If your strongest engineers are uncomfortable engaging with executives, that is fine. Find a business analyst or product owner who is comfortable in both worlds and partner them deliberately with your technical team. The goal is to have someone who can translate between business requirements and data design without information being lost in either direction.
4. Document your semantic model before connecting AI
   Before pointing an LLM or an AI agent at your data environment, invest in making that environment legible. Document your tables, define your key entities, map your relationships. A well-documented semantic data model is the prerequisite for getting value from AI. SqlDBM is designed to make this documentation accessible and shareable, so that once definitions are agreed upon, they are visible to both the human teams and the AI systems that depend on them.

The discipline of enterprise data modeling has existed for decades. What has changed is the cost of skipping it. When the primary consumers of your data were dashboards and reports, poor documentation created inconvenience. When the consumers are AI agents making decisions, poor documentation creates unreliable systems.

John Giles has seen data architectures succeed and fail across industries and technology generations. His conclusion is consistent: the teams that invest in shared blueprints, agreed vocabulary, and a conceptual model that maps business meaning to data structure are the ones that move fast, stay coherent, and build systems that age well.

The work has always mattered. Now the whole organization can see why.