Creating software that can be easily changed is the nirvana of any software professional. It's infinitely valuable to your business as your assets can evolve with your business. Unfortunately, it's rarely achieved. Its the number one thing I try to measure in a system and the easiest way to measure it is by simplying asking your people:
Me: Hey, Joe - what if next release we cracked up that Order Management system and added multi-currency support? Joe: :|
Me: Hey, Joe - what if next release we ported that product catalog API from SQL Server to PostgreSQL? Joe: :|
The reaction you will get will tell you all you need to know.
I could go on and on about various design patterns that will make your software better and easier to change. For years I believed in these patterns absolutely and universally. They come at a cost and they are not universally applicable (though some are close). As I've gotten older, I've realized that these patterns can only help you for the change you anticipate. And that very much is a moving target. The one silver bullet I've came to know for creating change-friendly software is... test automation. I'm not talking about unit tests or integration tests or acceptance - or maybe I'm talking about all of those things. I often work with teams that get really focused on the types of tests and the precise definition of each. There's value in understanding some of the details, but bottom line: in one step, can you regression test your system
in less than 20 minutes quickly and have full confidence it still functions?
If the answer is yes, then you've found your holy grail. If that in place, you're free to change your system any way you see fit with complete confidence. Few teams can say they have this. My advice is repeatedly ask yourself that question with every release and if you can't confidently answer yes, then fix that immediately. Everything else can be layered on or factored in as you go (with confidence).