My key learnings : 1. Acknowledge the need for change : Sharing outside-in view of how Industry is evolving , how are competitors can get an edge if we don't evolve 2. Training and Enablement : Not being familiar with Software design changes triggers resistance, familiarity will increase participation 3. Right mix of Experts (Catalyst) in the team: If all of the team is learning it might make things difficult - upskill expectations has to be realistic and sometimes hiring new talent is an option if upskill is a huge ask 4. Pair up with Mentors : to guide through the change, Grow mentors with train the trainer construct 5. Upfront answer to 'What is in it for me' : A framework to reward for achieving higher business outcomes with evolution

Please understand that changes you suggest is nothing but an idea you want to sell, if that does not have enough motivation for the buyer (dev team), then it won't through. So to complete the transaction both parties should have win win situation. I recommend to create that win win situation and I am sure it will through. Note: Usually developers affraid of technical failure of product delivered, and if that is not the case then time or resource scarcity. If that is guaranteed it will go through. Please sell your idea ??

I respect my fellow contributors here in this discussion. They all make great points! Put in this situation, I am going to work to understand where this resistance comes from. I am going to bet on that it is based in fear. Fear of failing demotivates innovation and experimentation. Fear of failing comes from places like unreasonable time pressure on projects, blame cultures (overtly or covertly), etc. Depending on what I can control, I will choose a path that allows and celebrates trying and failing, exploration, evaluation, and growth. This could come from a side project to show value of the change, and longer term, work to evolve the workplace into more of a no-blame culture. I hope this provides another perspective.

No product is perfect. What works today may not work few months or years down the line. Change is difficult but things get easier if we are able to explain to the team why the change is needed and how the change can positively impact the product.

By updating the current architecture to accommodate the needs and requirements..... Adding micro service layers that are backward compatible with the existing architecture might help