Abstraction, When & When NOT
Author: Howard Diesel
Date: March 17, 2023
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.