Many DBAs are nothing more than glorified system administrators who are
more concerned with backing up the data and allocating space when
necessary. I'm not a DBA, but I sure do have a deep appreciation for a
clear and concise explanation of data that a data model gives.

But what does this have to do with anything? The question you pose
seems to have more to do with organizational issues and the human
condition. Indeed, the question seems to reflect more of
organizational problem, and even perhaps a struggle for power and
control. It is ironic that such an argument should revolve around who
has control of data, rather than code, given our forum and the seeming
need to trivialize a systematic and computable expression and
enforcement of rules as data (i.e. the data model). It also seems like
a total deflection from the more substantiative arguments in this
thread.

For me, it would be about the countless hours of trying to rationalize
meaningless data and "reverse engineer" a data model reflecting and
representing a business universe of discourse because of quality, or
lack of it. Business rules that are enforced by one part of an
application but not by other parts of some "framework" make the data
meaningless. It might be "agile" in some loose, generalized
interpretation, but it lacks credibility and consistency, if that can
even be defined without a data model.

It doesn't matter whether the database or "persistence engine" could be
swapped out, because garbage with one "persistence engine" is still
garbage in another. And data structures that are now termed agile
having nomenclature such as SOME_OBJ(attr1, attr2, attr3, att4, att5,
att6, att7.......) is utterly meaningless to me. In 100% of the cases
where even asking the developer who had created such structures, not a
one could accurately and concisely give an accountability of what was
held in it, what it represented, or what rules were supposed to
enforced in a declarative manner.

How does one formulate questions, much less get answers, from such a
state of affairs?

In the end, the business must expend tremendous resources trying to
redefine and express rules for data, try to "clean" the data", and then
sometime down the road, throw out the application code anyway in favor
of the next big thing. Rarely does the business ever take the course
of trying to "clean" the code.

In contrast, in cases where where there was a data model that expressed
structure, manipulation, and integrity; and there was a data manager
for systematically enforcing the rules and semantics inherent in the
allowable data states and state transitions, regardless or what or how
many applications, application paradigms, frameworks, and bucket o' bit
pseudo-database application code developer wanna-be's there were, the
conversion from one database manager to another was trivial in
comparison to the reverse-engineering decoding exercise that is now
often the only alternative.