Separate out "data handling" from "data modeling".

[mikesperber]

Relates to #660.

Note that this also moves "data handling" to a more appropriate place. I don't know how amenable we are to changing the section numbering - but I figured I'd start by putting it in the place I considered best.

[github-actions]

Build Successful! You can find a link to the downloadable artifacts below.

Name	Link
Commit	922c1f6
Logs	https://github.com/isaqb-org/curriculum-foundation/actions/runs/11667518915
Download	https://github.com/isaqb-org/curriculum-foundation/suites/30467911620/artifacts/2141691692

[alxlo]

Even while I recognize that data modelling and data handling are two separate things, I'm not that happy with splitting this LG up. I see the positive side of having a clear conceptual separation. On the other hand they are still connected.: Changes in your data model can very likely have implications on data handling.
Also, we end up with a very anemic LG on data handling. Fragmenting already small LGs into ever tinier units has its downsides. Teaching data handling right after and together with data modelling keeps students connected with the topic and leads to insights of the consequences of design decisions for technical an operational aspects.

I think what we disagree on here are the cohesion criteria for learning goals. So I would like to understand, what is so important for you to propose this and what is the rationale behind it? What is the trade-off here?

[mikesperber]

@alxlo and I chatted about this a bit today at the Open Space.

I agree the separated-out LG is anemic - but it was anemic before, I even fleshed it out a bit!

So let me turn this around: What do you expect trainers to do about "data handling" as part of a training? I honestly did not get that from your wording, and clarifying that might help lead the way to resolving this issue.

[rhoadesre]

I don't have a strong opinion about this either way. My two cents worth.

Summary:
I think we should either leave the two topics (data vs data models) together, or place information about "Data" in the "Design" section of the syllabus and "Data Models" in the "Documentation" section.

Details:

1. I think that data and data models are highly related.
2. I would prefer to see data modelling under documentation. It's analog to the difference of components and other building blocks and their representation in the building block view / models.
3. I question whether "data models have significant impact on the architecture". I would think that the data itself, its structure, and its characteristics have a significant impact on the architecture and these are depicted in the architecture models
4. I don't understand the point "decoupling data models from their representation in databases, files, and transmission protocols". Aren't the "representations [of data] in databases, files, ..." also data models? So what type of data models are you referring to in the first half of the sentence? Are these data models representations of the "business" data as opposed to the representation of the corresponding "technical" data in databases, files, etc.?
5. I think that the point regarding architectural decisions should be reversed. Yes, I agree that "architecture decisions regarding data impact qualities", but it is more important that "architects make architectural decisions regarding data so that their quality requirements are fulfilled".

My proposal:
In the Design section of the syllabus:

Software architects understand the importance of addressing data-related aspects in the architecture. They

• understand the difference between data {glossary_url}products[products] and {glossary_url}sums[sums].
• can identify data, data structures, and data characteristics that have significant impact on the architecture, e.g., storage.
• can make architectural decisions regarding data to meet quality requirements such as integrity, confidentiality, scalability, reliability, and performance.

In the Documentation section of the syllabus:

Software architects understand the importance of data models for the architecture. They

• can design such data models systematically.
• understand the importance of decoupling data from its representation in databases, files, and transmission protocols.

Again, I'm not sure I understood the original statements, which is also a sign that they may need to be refined.

[gernotstarke]

in the FLWG online meeting in December 2024 the group decided currently NOT to merge this PR, but to leave the data-modelling+handling content in a single location (namely the existing LG 01-07).

we keep the branch, though.