From a data stand point I see microservices causing as many problems as they solve. The idea of having a neatly encapsulated application and data store that does one thing well is seductive.
If I liken Microservices to an organ in the body then data is the blood supply. I'm not sure that point gets across enough. The most painful pieces of software that I've had to maintain have been those where there are poorly drawn boundaries and confused responsibilities. In my experience this is as devastating to a microservices architecture as it is to a monolith. The microservices version tends to mask the problems.
I'd agree that customer outcomes need far greater prevalence. When a project is delivered its success is trumpeted from the roof tops but that is celebrating delivery success not customer success. The idea that something so many people across the enterprise have had a hand in did little of benefit for the customer would go down like a lead balloon.
Software and database design are skills. If I can liken it unto furniture manufacture then many of us can do a great job assembling flat pack furniture. Some of us could make a decent job of copying a flat pack pattern or extending it slightly. Far fewer of us could design an innovative piece of furniture, an ingenious expanding table or new type of hinge.
I perceive a lot of tech choices and architecture as attempting to solve problems that are of our own making. Quick fixes that don't last. Some of the best tools are actually the simplest ones.