"Why Data Modeling Success Hinges on Communication, Not Code"
Based on a conversation between data modeling experts Remco Broekmans (ELM), Marco Wobben (CaseTalk), and host Joe Reis
The Evolution from Techie to Communicator
A curious pattern emerges among seasoned data professionals: they all start deeply technical, then gradually shift their focus away from technology toward communication and business understanding. This isn't coincidence—it's recognition of a fundamental truth about data work.
As Remco Broekmans, author and BI specialist with over two decades of experience, puts it: "I realize it's not about the data, not about the tech part, it's more about communication. How to translate what business wants into a data model." Marco Wobben, who has spent 25 years in information modeling, echoes this sentiment: "The essence of what IT does is automate precisely the communication that happens on the business side."
This shift reveals something profound: technology can solve almost any problem, but only if we understand what problem we're actually trying to solve.
The "Involved Party" Problem: A Case Study in Failed Communication
Consider the common data modeling pattern of "involved party"—where IT professionals create abstract entities that can represent customers, employees, vendors, or any other business actor. While technically elegant and reusable, this abstraction creates a communication barrier.
When a business person hears "involved party," they're confused. When they need to query for customers, they must remember to filter for parties with type="customer" and role="buyer." What seems like smart design to IT becomes operational friction for everyone else.
This pattern repeats across organizations. As Broekmans notes: "We make a huge mistake because we think it's generic and abstract, but it's not because we need to do extra effort to get data into an abstracted level."
The lesson: abstractions that make sense to developers don't necessarily serve the business well.
Project vs. Program: Why American Data Initiatives Fail
One of the most striking insights from the conversation centers on the fundamental difference between how European and American organizations approach data work. In the United States, data initiatives are typically treated as projects—discrete efforts with defined start and end points, clear ROI requirements, and specific deliverables.
European organizations, particularly in the Netherlands, tend to treat data work as an ongoing program. Consider the Dutch railroad organization that has been continuously developing their information model for 18 years, mapping over 20,000 distinct business terms. The result? They reduced incident response times from four hours to two seconds through complete automation of their national rail infrastructure.
The key insight: data work is not a project you complete—it's a capability you build and maintain. As your organization grows, adds systems, and evolves processes, your data architecture must evolve too. Treating it as a one-time project virtually guarantees failure.
The Human Knowledge Problem
Why can't we simply feed all our documentation into AI and automate business understanding? The conversation reveals a critical limitation: much of the most important business knowledge exists only in human minds.
Marco Wobben shares the story of working with a company that went through 40 mergers, each with incompatible systems and conflicting definitions of common terms. "If you look up these words in a dictionary, it's very clear what they meant, but that was not how it was used in the business."
This specialized, contextual knowledge—what system quirks to watch for, why certain data transformations are necessary, how historical business decisions affect current processes—simply doesn't exist in any documentation that could train an AI system.
AI as Intern, Not Expert
Rather than replacing human expertise, the most successful applications of AI in data modeling treat it as an intelligent assistant. Broekmans uses AI as his "latest intern"—feeding it proper business requirements to generate initial data model layouts that he can then refine and validate.
Marco Wobben takes a similar approach, using AI to generate not just potential solutions but also questions to ask in the next business workshop. "Not just to give me an answer, but to help me think," he explains.
The critical principle: humans must always remain in the loop for validation and decision-making. AI can accelerate the work, but it cannot replace the deep business understanding and contextual knowledge that human experts provide.
Cultural Factors in Data Success
The conversation reveals interesting cultural differences that affect data project success rates. European organizations often have more job security, allowing employees to take time for thorough analysis and push back on management when needed. This creates an environment where the foundational work of understanding business requirements can actually happen.
In contrast, American organizations often operate under intense performance pressure with constant threat of layoffs. This creates a culture of shortcuts and "duct tape solutions" that prioritize immediate results over sustainable architecture.
Neither extreme is ideal. The Dutch experts acknowledge that some European organizations suffer from complacency, while American startups demonstrate remarkable execution speed. The optimal approach likely combines American execution drive with European thoroughness in foundational work.
Personality Over Pedigree
Perhaps the most provocative insight from the conversation concerns hiring for data modeling roles. Marco Wobben notes: "We basically started giving up on looking at resumes and far more starting to formulate what kind of personality traits does somebody need. It's not relevant if somebody has a PhD but cannot communicate."
This reflects a deeper truth about data work: technical skills are necessary but not sufficient. The ability to sit with business experts, ask clarifying questions, understand complex domain knowledge, and translate between business and technical languages matters more than advanced degrees or certifications.
Recommendations for Organizations
Based on these insights, here are key recommendations for organizations seeking to improve their data capabilities:
Treat Data as a Program, Not a Project
- Budget for ongoing data architecture work, not just initial implementation
- Plan for data teams to grow over time as success creates more demand
- Measure success over years, not quarters
Invest in Communication Skills
- Hire data professionals with strong interpersonal abilities
- Provide training in business communication for technical staff
- Create structured processes for requirements gathering and validation
Use AI Appropriately
- Deploy AI as an assistant to enhance human expertise, not replace it
- Maintain human oversight and decision-making authority
- Focus AI on text processing and initial analysis, not final recommendations
Build Cross-Cultural Understanding
- Learn from European approaches to long-term architectural thinking
- Adopt American-style execution speed where appropriate
- Balance thoroughness with delivery pressure
Focus on Fundamentals
- Resist the urge to chase shiny new tools without solid foundations
- Invest time in understanding business requirements deeply
- Build sustainable architectures rather than quick fixes
The Bottom Line
The most successful data initiatives share a common characteristic: they prioritize human understanding over technical sophistication. While technology continues to evolve rapidly, the fundamental challenge remains unchanged—translating business needs into automated systems that serve people effectively.
As Marco Wobben concludes: "There will always be tools and there will always be humans, and as humans we're trying to survive and make a living. That should be the focus, not the tools."
The organizations that recognize this truth, invest in communication capabilities, and build data programs (not projects) will create lasting competitive advantages. Those that continue chasing technical solutions to communication problems will continue experiencing the same high failure rates that have plagued data initiatives for decades.
