Very solid approach, which is common framework (5W1H) in the academic settings of ontology engineering and conceptual modeling. The other term is “competency questions”, which serve as the requirements for the data model/ontology.
I was going to say the first two paragraphs mirror what I have come to learn about ontology building. Makes me think what is actually different about ontology building and (conceptual?) data modeling in sql land which where I assume here these data modeling steps will manifest?
Candid feedback on this... It makes sense, but is also very adjacent to the 7Ws of BEAM* and I can see the 2 being conflated. BEAM* 7Ws are who, what, when, where, why, how and how many - sounds pretty much the same, right? Except these are applied in a completely different context. In BEAM* they are used to help describe the contents of a model, whereas the 5Ws here seem more aligned with the purpose of a model. Of course, I have my analytics hat on again, and I guess BEAM* serves a purpose for analytical use cases, whereas I guess the book has a broader scope. I just wonder if there's a way to to make sure the 2 frameworks don't get easily confused.
Yeah, it’s definitely different from BEAM (great book and framework). Definitely something I’ll consider because you’re absolutely right about this possibly being confused or conflated. Maybe a footnote at a minimum?
Yeah I have a lot of time for BEAM*. We reference the 7Ws in our own SunBeam framework. Lawrence Corr is a lovely chap if you ever have opportunity to cross paths with him.
I guess another obvious distinction for the types of readers of this book is most people will know the 5W’s, but I’m guessing a very small handful will understand the 7W’s of BEAM. But as you say, it’s good to make a distinction between between the two.
I have used the Zachman framework to align all data modeling activities and tasks to similar 5W’s (who, what, when, where, why) and then how. I believe you are trying to do the same. Based on the answers to the 5W’s, the how is developed (high RI an 3rd Normal Form, star-schema, what-ever works best approach).
Definitely some similarities. I’d say either approach is valid. I guess if there’s a comparison, my approach is “Zachmann-lite”, because it’s not meant for enterprise architecture, and people might skip the various levels he prescribes (contextual to detailed). I find with data modeling, despite urging people to do conceptual modeling, they don’t and won’t.
Hi Joe - A time-honored approach to just about everything data, from models to analytics. For example, you could ask the same questions of a collection of sales data: Who bought What product, Where, When, and How. 'Why' has two aspects; one practical (Role and Function), the other philosophical. The latter I leave to the sages.
The other interesting thing about Semantium's Kipling approach - we call it the Q6 protocol - is when expanded a little bit (for example the 'Who' class expands to 'Person' and 'Organization') you get nineteen orthogonal classes. That dimensionality is the same from glossary to analytics; and from lists to documents.
The tricky part you may run into is staying consistent. For example, how would you answer your first question: "Who will this data model serve?" You could say "Mabel in Marketing" or you could say "Our customers." One is precise but too narrow perhaps. The other is out of class boundaries.
Hello Joe - really appreciate your approach to this in taking an approach that is not intimidating (eg apply Kimball … go ) as as you say this is half the battle to engagement especially for domain experts who absolutely must engage with the modelling process. Another challenge I have and continue to face in the field is accessing experienced or knowledgeable modelers (be that contract or perm staff, and especially for modeling data that manifests in the unstructured world). Do you have any views on how to go about this issue? Train own team, search for folks with direct or related experience on LinkedIn, agencies ? Many thanks Ben
Very insightful, as always, Joe, the 5WH approach is not only important for various modelling activities as you discussed, but also necessary for each dataset or entity in context of an enterprise data ecosystem (EDE). We are using a knowledge and context construct to model and manage knowledge complexity of each dataset in multi-dimensions, conceptually separate it from its hosting system, and capture relationships between the dataset and other elements (from relevant datasets, tools, systems, processes/activities, stakeholders and governance) in EDE. Through such a modelling exercise, data is no longer treated as the second-class citizen in EDE.
I love this approach, scope creep is always a danger zone in modeling. In addition to your What insights you could declare up front what topics, entities etc are not in scope.
Joe, this is a good approach. Simple and effective. I see how the Data Modeling practitioners will adopt this as soon as they read this chapter. This also reminds me of how everyone kept talking about the 5Rs in the context of Cloud Transformations a few years back when Cloud Wave started. I am sure you are up to something similar. I am excited and looking forward to the rest of the chapters and this book.
Note - I’m sure some are going to ask if I’m covering conceptual, logical and physical modeling in this chapter. Yes.
Very solid approach, which is common framework (5W1H) in the academic settings of ontology engineering and conceptual modeling. The other term is “competency questions”, which serve as the requirements for the data model/ontology.
Cool, I’ll look into those use cases too. Thanks!
I was going to say the first two paragraphs mirror what I have come to learn about ontology building. Makes me think what is actually different about ontology building and (conceptual?) data modeling in sql land which where I assume here these data modeling steps will manifest?
Candid feedback on this... It makes sense, but is also very adjacent to the 7Ws of BEAM* and I can see the 2 being conflated. BEAM* 7Ws are who, what, when, where, why, how and how many - sounds pretty much the same, right? Except these are applied in a completely different context. In BEAM* they are used to help describe the contents of a model, whereas the 5Ws here seem more aligned with the purpose of a model. Of course, I have my analytics hat on again, and I guess BEAM* serves a purpose for analytical use cases, whereas I guess the book has a broader scope. I just wonder if there's a way to to make sure the 2 frameworks don't get easily confused.
Yeah, it’s definitely different from BEAM (great book and framework). Definitely something I’ll consider because you’re absolutely right about this possibly being confused or conflated. Maybe a footnote at a minimum?
Yeah I have a lot of time for BEAM*. We reference the 7Ws in our own SunBeam framework. Lawrence Corr is a lovely chap if you ever have opportunity to cross paths with him.
I guess another obvious distinction for the types of readers of this book is most people will know the 5W’s, but I’m guessing a very small handful will understand the 7W’s of BEAM. But as you say, it’s good to make a distinction between between the two.
I have used the Zachman framework to align all data modeling activities and tasks to similar 5W’s (who, what, when, where, why) and then how. I believe you are trying to do the same. Based on the answers to the 5W’s, the how is developed (high RI an 3rd Normal Form, star-schema, what-ever works best approach).
Definitely some similarities. I’d say either approach is valid. I guess if there’s a comparison, my approach is “Zachmann-lite”, because it’s not meant for enterprise architecture, and people might skip the various levels he prescribes (contextual to detailed). I find with data modeling, despite urging people to do conceptual modeling, they don’t and won’t.
Hi Joe - A time-honored approach to just about everything data, from models to analytics. For example, you could ask the same questions of a collection of sales data: Who bought What product, Where, When, and How. 'Why' has two aspects; one practical (Role and Function), the other philosophical. The latter I leave to the sages.
The other interesting thing about Semantium's Kipling approach - we call it the Q6 protocol - is when expanded a little bit (for example the 'Who' class expands to 'Person' and 'Organization') you get nineteen orthogonal classes. That dimensionality is the same from glossary to analytics; and from lists to documents.
The tricky part you may run into is staying consistent. For example, how would you answer your first question: "Who will this data model serve?" You could say "Mabel in Marketing" or you could say "Our customers." One is precise but too narrow perhaps. The other is out of class boundaries.
You'll have fun with the Kipling kids regardless!
Hello Joe - really appreciate your approach to this in taking an approach that is not intimidating (eg apply Kimball … go ) as as you say this is half the battle to engagement especially for domain experts who absolutely must engage with the modelling process. Another challenge I have and continue to face in the field is accessing experienced or knowledgeable modelers (be that contract or perm staff, and especially for modeling data that manifests in the unstructured world). Do you have any views on how to go about this issue? Train own team, search for folks with direct or related experience on LinkedIn, agencies ? Many thanks Ben
Very insightful, as always, Joe, the 5WH approach is not only important for various modelling activities as you discussed, but also necessary for each dataset or entity in context of an enterprise data ecosystem (EDE). We are using a knowledge and context construct to model and manage knowledge complexity of each dataset in multi-dimensions, conceptually separate it from its hosting system, and capture relationships between the dataset and other elements (from relevant datasets, tools, systems, processes/activities, stakeholders and governance) in EDE. Through such a modelling exercise, data is no longer treated as the second-class citizen in EDE.
Good adaptation! Think 5 times before you act
I love this approach, scope creep is always a danger zone in modeling. In addition to your What insights you could declare up front what topics, entities etc are not in scope.
Joe, this is a good approach. Simple and effective. I see how the Data Modeling practitioners will adopt this as soon as they read this chapter. This also reminds me of how everyone kept talking about the 5Rs in the context of Cloud Transformations a few years back when Cloud Wave started. I am sure you are up to something similar. I am excited and looking forward to the rest of the chapters and this book.