Hi Joe, I like this article (you’ve talked about MMA before) but I don’t think it goes far enough. Data modeling can be seen as a variant of modeling more generally. The Eric Evans (in his Domain-Drive Design book) talks about “model-driven development” and Lawrence Corr (in Agile Data Warehouse Design) also talks “model-driven development”.
In DDD we model aggregates, entities and value objects … these are all forms of persistent data.
In Kimball (and BEAM) we model business events in order to create a dimensional data design.
Remember back to the “good ol’ days” of IBM, Rational and UML. Well UML is merely a language for common notation of models. So, we are sort of re-inventing mixed modeling aspects in order to capture the complexity of our systems. You might model analytical data for dashboards with Kimball, Feature Store modeling for ML and a Wardley Map to capture system evolution.
Bottom line you need competence in a variety of modeling approaches to engage in broad conversations with different stakeholders.
Funny that you say enterprise land is a dead end. Literally the first thought I had when you mentioned the silo skill sets, being in that land, myself. My data team is unique from the rest of the enterprise, though, Still, we’re analytics and BI focused, and also siloed! 🤦♂️ At least we’re able to be a little cross disciplined and do some LLM stuff. Slow as molasses 😂
Precisely what i talked about with bill inmon on my podcast. His fight with IBM is an interesting lesson
Yep, Bill's the OG in being multi-discipline with data modeling.
No doubt on this topic, Joe. Will the modelling techniques depend on, or create different lineages of thinking?
Data mesh vs Centralised
Gracie Vs 10th Planet
DDS Vs B-Team
Oss
Hi Joe, I like this article (you’ve talked about MMA before) but I don’t think it goes far enough. Data modeling can be seen as a variant of modeling more generally. The Eric Evans (in his Domain-Drive Design book) talks about “model-driven development” and Lawrence Corr (in Agile Data Warehouse Design) also talks “model-driven development”.
In DDD we model aggregates, entities and value objects … these are all forms of persistent data.
In Kimball (and BEAM) we model business events in order to create a dimensional data design.
Remember back to the “good ol’ days” of IBM, Rational and UML. Well UML is merely a language for common notation of models. So, we are sort of re-inventing mixed modeling aspects in order to capture the complexity of our systems. You might model analytical data for dashboards with Kimball, Feature Store modeling for ML and a Wardley Map to capture system evolution.
Bottom line you need competence in a variety of modeling approaches to engage in broad conversations with different stakeholders.
You’re right. Thankfully these topics will be covered in the book!
Bruce Lee FTW!
Funny that you say enterprise land is a dead end. Literally the first thought I had when you mentioned the silo skill sets, being in that land, myself. My data team is unique from the rest of the enterprise, though, Still, we’re analytics and BI focused, and also siloed! 🤦♂️ At least we’re able to be a little cross disciplined and do some LLM stuff. Slow as molasses 😂
Slow as molasses indeed