A Series

 I wrote a short post at Raybeam's Focus site.

I've got a couple of follow-on posts written laying out the argument more succinctly than I've been able to so far.  Eventually this will get turned into a longer piece, and better illustrated than most of my usual.

The centerpiece of the first post is this graphic:

It's important to keep in mind that, when we talk about "data architecture" these days we're actually talking about six different paradigms (more or less) of data modeling. 

Each of the systems in the ecosystem diagram above have their own data modeling rules. You can't just apply a Kimball-style star schema to everything. For one thing, there's more than one way to define an attribute in most dbs. You can make the rule that every attribute should be a field in a table, but someome is still going to use a _TYPE field to draw a distinction that doesn't make it into a field.

That conflict is a basic input to the modeling styles for each system in the ecosystem.  (That's one conflict.  There's others.)  Each one plays a role in that ecosystem depending more or less on which other systems it gets and receives data from.  Sometimes data migration is as simple as forcing all the attributes into one long record. Immediately we solve the "we can't find our data" problem. Eventually it happens again when the table gets to be so wide no one can see one end from the other.  And that's when the dimensions multiply like literal snowflakes in little boxes of JSON.

In any event, at least six styles of data architecture in this ecosystem. I grouped all the collection points - the applications - into one because the current prevalent model of data modeling in software architecture is to stick to a "developer driven" NoSQL model of agile development. Ideally the db contains nothing but name-value-key pairs defined by whoever happened to be writing code that day.

Anything more than that? Friction. So there's not much data architecture in modern software engineering practice.