Have you ever seen this situation?
An organization has prepared a data strategy. On paper, everything looks strong. The roadmap is clear, the architecture looks impressive, and the plan seems well thought through. But when execution starts, the real challenge begins.
Architects, engineering, and delivery teams start debating best practices. The discussion becomes highly technical, the delivery process becomes longer, and sometimes the final solution becomes less practical for the business.
Sound familiar?
This is a classic story in technology and data. In many cases, technical teams focus too much on what is considered “best practice” from a technology point of view. The problem is that some best practices are only good on paper. Some are outdated, overly complex, or disconnected from the actual business problem that needs to be solved.
The Same Concept, Different Names
Let me share one of my experience.
Around 20 years ago, when I started my career as a developer, I was already using the classic analytics layer concept: Staging, Operational Data Store, Data Warehouse, and Data Mart. As my career progressed, I noticed that the concept mostly remained the same. What changed was the naming. Some organisations or Big Tech Brands (just to make it is looked new or better for marketing) call them Landing, Curation, Data Warehouse, and Data Mart. Others use Bronze, Silver, and Gold. I have even seen another variation such as Sand, Stone, Bronze, Silver, Gold, and Diamond layers.
Although the names are different, the goal is usually the same: to prepare data so it is clean, reliable, and ready for consumption. I often feel these naming conventions are more about sounding different or appearing innovative, rather than genuinely improving how data is prepared and used.
Best Practice vs Best Practical
From my personal point of view, instead of being too strict with fancy technology jargon and constantly using “Best Practice” as the reason in every argument, we should focus more on being "Best Practical". That does not mean compromising integrity, quality, governance, or scalability. It means choosing an approach that works, is understandable, and can actually be executed. I often heard data team implement Kimball or Inmon methodology, which were invented 1990ish, strictly without any adjustments, and often forcibly fit business to this this methodology or other technology concept or needs not the another way around. I don't say both methodologies are bad, I use both of them but I usually adjust the use and take the good from both of them based on the business needs.
The name itself is not the most important thing. What matters is how effectively we prepare clean, trusted, and useful data for business consumption. For example, I prefer using simple and business-friendly names such as preparation layer, processing layer, consumption layer, and presentation layer.
If you have worked in data for a long time, you will know that the actual data process is usually much longer and more complex than just three or four layers. Data does not become valuable simply because we give each layer a fancy name. It becomes valuable when people can trust it, use it, and make better decisions from it.
Explaining Data in a Human Way
I do not like using too much technical jargon when explaining data concepts to stakeholders. Instead, I often use a fisherman and seafood restaurant analogy when explaining the data warehouse process. I usually start with asking my stakeholders:
“What is the difference between a data engineer and a fisherman?”
Imagine data as different types of sea creatures living in the ocean: tuna, salmon, prawns, lobster, squid, octopus, clams, and many others. And you as business users is the seafood consumer. Me and my team are the fishermen and also Seafood Chef, which we will catch the fish and will prepare the seafood to you.
As the fisherman, I need to go to the ocean and catch the seafood. After that, I bring it back to land. But before we clean and prepare it, we may need to keep it fresh in a pool or big aquarium tank . When it is ready, we clean it, select it, store it in cold storage, send it to the restaurant, and finally prepare the food based on the customer’s requirements.
How This Relates to Data
This is very similar to the data process.
- Catching the seafood from the ocean is like extracting data from source systems.
- Bringing it to land is like landing the data into our platform.
- Cleaning and selecting the seafood is like transforming the data, removing duplicates, applying business rules, and selecting what is relevant.
- Packing and Storing seafood in cold storage is like storing clean and trusted data in a centralised data warehouse.
- Sending it to the restaurant is like preparing data marts or consumption layers for specific business needs.
We may send certain seafood to a sushi restaurant and different seafoods to a fish and chips shop. In the same way, we prepare different data products or data marts depending on the specific consumer requirement. Whenever I explain it this way, stakeholders usually say it is much clearer and easier to understand.
Proven Through Execution
This is not just a theory for me. I have proven this approach in a number of organisations where I had a few of opportunities to build data departments and data platforms from the ground up.
In those environments, I applied a Best Practical approach. The delivery became simpler, easier to understand, deliver quicker, and more aligned to business needs. For example, in some cases I removed technical naming conventions such as “dim” and “fact” from the data model. The concept of dimensions and facts was still there, but I translated it into more business-friendly terms such as master tables and transaction tables.
This made the data model easier for business users, analysts, and new team members to understand without compromising the integrity of the architecture. The result was a data warehouse that remained strong, reliable, and scalable. In one organisation I worked with, the data warehouse is still actively used today, more than 10 years later. It continues to run in a stable and reliable way, and it still acts as a true single source of truth for the business.
For me, this reinforces the point: best practice is valuable, but only when it helps execution. If it makes the solution too complex, too slow, or too difficult for the business to adopt, then it may not be the best approach.
Making It Simple and Easier
I sometimes joke with my team that instead of calling our layers Bronze, Silver, and Gold, maybe we should call them Data Ocean, Data Pool, Data Storage, and Data Restaurant. Of course, the naming is not the point. The point is that data architecture should be understandable, practical, and connected to business outcomes.
"Make it simple, Sometimes Simple is the Best Solution."
In the end, a good Data & AI strategy is not measured by how sophisticated the diagram looks or how modern the terminology sounds. It is measured by how well it can be executed, how well it supports the business, and how quickly it can turn data into trusted insights and real value.
"Best practice is important. But in execution, best practical often wins."
