I hate to say it, but good documentation is the key here. Visualizing data as interconnected nodes breaks down silos, aligns teams and makes it easier to build reusable, loosely-coupled systems.
Since the article uses lots of big words, phrases and memes (when a few simple words would suffice), and assumes you know it already, Conway's law is simply that your technical architecture will reflect your social/organizational architecture.
"Big words, phrases and memes"? You got this distressed about an article using industry standard terminology for its target audience and assuming that you'd read (or would read) the post it linked to on Conway's law?
> provide “data APIs” to data teams
I feel like I'm reading part of Data Mesh again.
Hah. That is a good reference. Never seen a concept boosted so much.
I hate to say it, but good documentation is the key here. Visualizing data as interconnected nodes breaks down silos, aligns teams and makes it easier to build reusable, loosely-coupled systems.
I missed the part where there was an actionable takeaway about how I as a practitioner am supposed to differently.
reminds me nifi plus kafka
Since the article uses lots of big words, phrases and memes (when a few simple words would suffice), and assumes you know it already, Conway's law is simply that your technical architecture will reflect your social/organizational architecture.
"Big words, phrases and memes"? You got this distressed about an article using industry standard terminology for its target audience and assuming that you'd read (or would read) the post it linked to on Conway's law?
It's a great theoretical point.
> The tools, the practices, all built around the premise that software and data teams don’t work closely together.
In particular, the various teams, even the same team with itself, end up being separated along a timeline.
Information Technology ends up being the embarrassment we all face that our data are rarely, if ever, showing up dressed for work.