The stakeholder problem for me is "the data model doesn't describe how the business works" - the data team's response is for me "but that's how your business systems were designed"
And this is where pedantic semantic detail really does come in, as this page is effectively the “North Star” problem statement for the entire guide its the one we always need to sweet the detail on.
It’s also why the words used on this page get iterated all the way to the end, but the core problem statement has to be set upfront.
I see two data team responses that are common to stakeholders who say this:
1) The data team model based on the source systems, the systems of capture. This is deffo a big problem.
2) The data team model based on the technical limitations or patterns of implementing the physical data model. This is also a big problem.
Both of these data models are not fit for consumption by a stakeholder who is not a data expert, as they do not describe how the business works in a language the stakeholder understands.
In my view the North Star problem the guide is trying to solve is response #2.
Response #1 will deffo be in the page with the 9 problem statements, something along the lines of “your data team models based on the structure of the source system”
The reason I think the focus is #2 is that I don’t believe a dimensional data model or a data vault data model, or a ERD is the best type of Map to describe or share the business reality with a stakeholder.
Good discussion. I think the core problem is something like this:
- The business stakeholder wants to fix business problems, and needs to be able to connect the necessary data to these problems as easily as possible.
- The data team wants to deliver solutions, so the data component of those solutions is optimized for fastest and easiest possible delivery.
The crux of the matter is that both sides are optimizing for different things. I don't think the business stakeholder is directly interested in the data model per se, they just want the data to be understandable and available so that they can get the outcome they want - they want to optimize for the business outcome, no matter what happens along the way there. The data team, however, tends to optimize for their own output. This is where the problems appear.
Conceptual modeling is a vehicle for data teams to understand the actual desired outcome, so that they can align their outputs to that.
We need to refine the language in that page, but sounds like your saying the core problem statement of a Stakeholder saying they don’t understand the “data model” and the data team saying well we created a “data model” we needed to make the data work is the main problem to be solved?
The stakeholder problem for me is "the data model doesn't describe how the business works" - the data team's response is for me "but that's how your business systems were designed"
And this is where pedantic semantic detail really does come in, as this page is effectively the “North Star” problem statement for the entire guide its the one we always need to sweet the detail on.
It’s also why the words used on this page get iterated all the way to the end, but the core problem statement has to be set upfront.
I see two data team responses that are common to stakeholders who say this:
1) The data team model based on the source systems, the systems of capture. This is deffo a big problem.
2) The data team model based on the technical limitations or patterns of implementing the physical data model. This is also a big problem.
Both of these data models are not fit for consumption by a stakeholder who is not a data expert, as they do not describe how the business works in a language the stakeholder understands.
In my view the North Star problem the guide is trying to solve is response #2.
Response #1 will deffo be in the page with the 9 problem statements, something along the lines of “your data team models based on the structure of the source system”
The reason I think the focus is #2 is that I don’t believe a dimensional data model or a data vault data model, or a ERD is the best type of Map to describe or share the business reality with a stakeholder.
Juha what’s your thoughts in this?
Good discussion. I think the core problem is something like this:
- The business stakeholder wants to fix business problems, and needs to be able to connect the necessary data to these problems as easily as possible.
- The data team wants to deliver solutions, so the data component of those solutions is optimized for fastest and easiest possible delivery.
The crux of the matter is that both sides are optimizing for different things. I don't think the business stakeholder is directly interested in the data model per se, they just want the data to be understandable and available so that they can get the outcome they want - they want to optimize for the business outcome, no matter what happens along the way there. The data team, however, tends to optimize for their own output. This is where the problems appear.
Conceptual modeling is a vehicle for data teams to understand the actual desired outcome, so that they can align their outputs to that.
I think I prefer option 2
Actually I think I like the left of 2 and the right of 1
We need to refine the language in that page, but sounds like your saying the core problem statement of a Stakeholder saying they don’t understand the “data model” and the data team saying well we created a “data model” we needed to make the data work is the main problem to be solved?
I like this combo