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.