There have been some discussions around data modeling and the more costly impacts of database changes.
Doing the right amount of up front work precludes doing the costliest of
refactoring.
Doing enough quality modeling of the domain up front usually makes it
easier to accept change — and to find where the change “goes.”
Making a clear distinction between roles of the different software
artifacts (ui classes, business layer services, domain classes,
persistence management layer, DAOs, etc.) and how they play
architecturally in the implementation, also helps to make it easy to
figure out the impact of a change and where to make the changes.
however, if you have crap for architecture and widely-varying approaches
in different parts of the app, and all sorts of logic spread into the
database (like stored procedures doing business functions that could be
done in objects), then you have crap.
data folks being a “bit defensive” to me says i have to pay more
attention to what i do upfront. if it is costly to do certain parts of
development, then i will adjust my techniques to account for that. i
will have the team work a bit harder, possibly, to ensure that we don’t
thrash the expensive parts of our construction costs.