Abstraction, When & When NOT
Howard Diesel
Chief Data Officer @ Modelware Systems | CDMP Master | Data Management Advisor
Confession time: after coding in C for several years and seeing object-oriented programming, I became an overnight Abstraction junkie. I carried this addiction into data modelling and master data management.
Fortunately, Data Warehousing and Data Marts are very concrete, so abstraction isn't practical.
That doesn't mean I didn't try. I remember the day when I was building a virtual cube of multiple fact tables, and SQL Server Analysis Server suggested that the fact tables have a similar structure and I could merge the fact tables. This abstraction (merge) caused many problems for my virtual cube's users.
It was when I did a data modelling course with Steve Hoberman, and he suggested that abstraction was very dangerous and that you need a safety guide that prevents you from going too far.
After arguing for a while, I started to see that my thinking was wrong, and I needed to unlearn the idea of future-proofing everything I did. Yes, I could cater for the inevitable business changes, but the pain that I caused wasn't worth it.
Remco Brokmans made a similar comment: focus on the core business concepts. Do not abstract.
Fortunately, I had conquered the abstraction addiction. I now enjoy the simplicity of using the exact words used by businesspeople and not having to explain what this funny party is all about.
This confession does not mean there isn't an appropriate use of abstraction. You must have an abstraction safety guide to stop you from doing something when you do not need to do it.
Some acceptable uses of abstraction are:
- Conceptual Model or very high-level models: abstraction for presentation
- Feature reduction: abstraction for interpretation
- Reduced Specification Details: abstraction for specification
In the next three weeks, we will look at these abstraction usages and how to ensure that you are not going too far.
Great session. I think Abstraction is what we all do in life in a certain way. By putting it into a framework and processes, will make it easy for a CEO to the Data Worker.
Analytics | Data Architect | Data Management | Data Governance | Data Science
2 年Thanks Howard, for enriching the data management community, Can we get the recorded session
A big thank you to everyone who contributed to the discussion: Penelope Hilton-Barber; Remco Broekmans; Connie H.; Patricio Cevallos, CPDA, CDMP; Ha Nguyen (Annie); Ross Diesel; Rizwana Cassim; Mbando Mbobo; Martin Goebbels; ?Soha Farea; Maher Zaitoun; Amal Almutairi; Jean Maritz; Naresh Puppala; Daphney Motlhoki; Matshidiso Morulane; Molefi Radebe; Hesham Khalil; Prashanth Ramakrishna; Kaylene Kylie Lloyd; Nutan Naran; Yaser ALJassir, MBA; Sonia Vaessler; Itayi S.; Rekha Govardhan; Sandisa Nyokana; Veronica Diesel; Paul Bolton
Software Developer
2 年Am also reminded of Jacobssens idea that before one abstracts, one needs to materialise a couple of concrete instances. Guess thats a bit like premature optimization of design.