I don't get the `SCIM doesn’t really have anything to do with data retention.`; if SCIM store data to sync between diff. integration / backend / ERPs / tools it is possibly impacted by data protection law like GDPR and co.
I often meet people who think their customer asking for SCIM provisioning means that their customer is identically asking for some newfangled data retention policy. All I meant to emphasize was that SCIM is just a provisioning / update protocol.
Indeed, you are right -- we see customers careful about the data retention policies applicable to SCIM data -- but that's because they'll have reasons to be broadly concerned with data retention matters. Hence my writing "this is usually a separate conversation you might need to have with your customer."
I've also written 1,000+ page books https://wjgilmore.com/books so if a book is defined by its length then I think I have that down pat. In any case, feel free to call it what you will, I'm happy with the information and experiences shared within this slim volume and think readers will find it useful too.
And as is typical of all my books I will continue updating and expanding it over time and always provide those updates for free.
I believe that Eng. Manager and HR are mostly at fault for it, confusing seniority and familiarity as creating and giving higher title to keep people without doing the requirement part of the job: accessing the title, drawing a ladder linked to a skills matrix.
And then one authors of the book state: "if you know nothing about Scrum, implement everything as in the book, otherwise adapt to the situation and the team. If not you will surely fail [...]"
But being "Scrum.org certified PSM", how do you see your colleague from scrumalliance.org?
Like digitalization? Like Solar Panel building (in 2022 like 80% where imported)? Or like in the past about credit cards? ("we don't want plastic money" moment)
> Like renewable energy? 1st quarter 2024: 58,4% electricity from renewable energy. Up from 48.5% last year.
> I call this approach the "API database architecture"
Why people can't search for an existing term before creating a new one, it just add confusion into bucket which already contains "DB as API", "DB over API", "DB 2 API", "DB 2 REST", "DB low-code API"
It's more lack of "second thoughts" skills and possibly lack of State of Art and Decision Records; it is impossible to learn from failure if no trace exist or no one knows who did the decision.
