Hi Lee,

Thanks for reading through the article, and for the response. You definitely make some good points. I certainly agree with your sentiment that an absolutist mindset should be avoided. This article was intended to challenge what I've seen as a widely considered "best practice" that is rarely questioned—at least, by those that haven't yet actually lived through its real-world consequences. But admittedly, I may have traded one dogmatic opinion for another. :)

Regarding API change management… the core services model generally makes changes that much more difficult to manage, particularly because they often lead to a sort of "design by committee" approach. Because everyone shares that data, everyone has their own particular view of the data, and their own needs from the data. I've seen this lead to fairly regular churn in the APIs, as teams negotiate to get their specific needs met. Granted, there are patterns (expand-and-contract being a notable one, API versioning being another) to help avoid dependent teams literally needing to halt their work and make changes. But they will have to make those changes at some point, unless the core services team is expected to maintain legacy APIs in perpetuity.

Substituting in a public service is an interesting mental exercise. One important difference between something like AWS Cognito and our in-house User service is that different verticals aren't likely to have their own views of credentials and permissions, the same way that they would have different business views of its users. Although to be honest, I could see third-party services that do attempt to define common business entities possibly being helpful, insofar as they would limit the ability to customize our entities to our different teams' whims in the first place.

Anyway, good feedback, and much appreciated.