I think the trick is that we're all in the same boat, so stating why you oppose something but knowing that the final decision might be somewhere else is just the reality. It's figuring out how to keep the boat afloat despite whatever happens that is the goal. Playing the blame game just fractures whatever chance for a team there is. We all do it, but the goal is to do it as little as possible and relent once you've done it.
Yes yes, and what Jeff said too. My experience has been the surrender direction has been one-sided going the other way. But I've been promoted up the chain to Senior Director because I treat the data as if it belongs to its appropriate users. Everyone is trying to contribute. "There's the right way, the wrong way, and the way things get done around here." The sooner you get on board with the last one the better for everyone involved.
Imo DBA's haven't had a good alternative to the newer methods of data access, like the Entity Framework, if we're being honest here. What "ease of data consumption" tools exist for DBA's to offer data services in a developer friendly way? In order to request data from a SQL stored procedure the client has to re-code the input and output parameters to be submitted. The response data must be translated again into a format the client can easily consume. In C# it's traditionally been done with 2 methods, 1 to run the procedure and 1 to call that method and handle the outcome. In EF it's only 1 method and serialization is handled automatically. This has been a big bottleneck for a long time.
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können