You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all let me state that I'm very impressed by the balance and completeness of the curriculum. Thanks a lot for putting this work and deep thought into it.
Given that, my feedback is focussed on emphasis i.e. which topics would need more or less time to sink in from my point of view and my experience.
Chapter 11 should be Chapter 0: Putting these topics last sends the wrong message IMHO. In a training, this terms should IMO be explained first because they should be omnipresent in most other chapters i.e. be mentioned and referenced to make sure their importance really sunk in with every participant
Think about thinning out "Data Privacy and Compliance": This can be a huge topic in itself and architects should rather have a "I know that I don't know, so I rather pull in a data privacy expert to double-check" mindset than thinking "ah, ya, I learned everything there is to data privacy in that iSAQB training"
Think about explicitly separating LLM-containing applications and LLM-Ops. This would help in expectation management
Rethink your subheading to emphasize the "why should I care" for someone who thinks "Huh? I'm dealing with data in every application, I know all there is why should I even read this curriculum". It doesn't have to be a "10 things everybody fails in when it comes to sustainable Data Architectures", but I guess you know what I mean
If your focus is "analytics applications/systems" please clearly state that. Otherwise rethink whether chapter 2 should really take that amount of space without explicitly mentioning "the other types of applications". I am very opinionated on this because my experience is that most Data Scientists are used to building and thinking in analytical contexts only and applying their learnings 1:1 to other contexts. Analytics Applications like providing a data product for a management dashboard is a very different runtime context compared to being responsible for a customer-focussed internet applications with millions of users that has to be available 24/7.
I'd like to encourage you to put more focus on the long-term view i.e. explicitly stating the different application runtime contexts which exist and how architecture decisions on (exposed) data structures, data qualities, and transfer protocols (interactions, information, interfaces) have a huge impact on sustainability, replaceability, resilience, and performance efficiency and thus the lifecycle of software systems.
The text was updated successfully, but these errors were encountered:
First of all let me state that I'm very impressed by the balance and completeness of the curriculum. Thanks a lot for putting this work and deep thought into it.
Given that, my feedback is focussed on emphasis i.e. which topics would need more or less time to sink in from my point of view and my experience.
The text was updated successfully, but these errors were encountered: