You can obtain some independence through software architecture, I agree... But it's no panacea. We thought ORMs would shield us from DBs change, then noSQL app

You can obtain some independence through software architecture, I agree... But it's no panacea. We thought ORMs would shield us from DBs change, then noSQL appeared. We thought 100 concurrent users were plenty and used 1 thread per user, but now it's 100M and we need event loops and sharding. We thought our server had one core, now it has 16, and we use 100s of these. OP's company thought using mySQL was a good idea, but maybe someday, nights will not be long enough for batches to run. Abstracting away mySQL will not help. Nowadays, the number of possible architectures has exploded. Moving from MySQL to Postgres solves no hard problem. But moving from MySQL to a cluster of Cassandra servers does, and it's hard. Just like moving from night batches to real time. I'm biased of course, because I'm working on projects where "old tools" can't be used because of scale. For "old style projects", old tools are still usable, and little benefit can be gained from newest systems architectures. But sometimes, the real "business problem" is scale, not complex business rules. Last word about software architecture: I'm the one who introduced my employer to modular developement, TDD or functional programming (and many others). I'm convinced good software architecture is of paramount importance, but it can't solve most paradigm shifts alone.