Comment by Keyframe
2 days ago
Having dealt with same problems for years now (we call our UDM - Unified Data Model, heh), I was under the impression this was an over-engineered Datamart++; It's not though. Calling UDA a datamart would be like calling K8S a bash script, which might be related but wildly different in scope.
I am definitely interested to read more and implement it myself as well. Would also be more than happy to skip the whole GraphQL end of it.
> Would also be more than happy to skip the whole GraphQL end of it.
Netflix benefits from a large GraphQL ecosystem with federation, which is why it's so central in UDA from day 1. But adding a projection to "REST" would be very easy.
I don't doubt their yield out of GraphQL is great. Not something I'm having a need for though. I'm at the helm of the tech group at one part of dun&bradstreet so we have different challenges, unification across different borders being primary one. We manage, but the going gets tough sometimes. Described architecture of UDA certainly seems to be what it was designed to solve. I think our system is even at a perfect inflection point to adopt at least some of the principles described to provide a clear path forward to resolve some of those challenges we face; Not as a replacement, but more of as a control plane over our system. I can already see how we could avoid at least schema bloat, lowest common denominator fields and overall rigidity.
Of course, details on "Upper", PDM, and Sphere are well - missing, but at least I have concepts to focus on :)
> Of course, details on "Upper", PDM, and Sphere are well - missing, but at least I have concepts to focus on :)
Definitely coming soon ;-)