Designing for change
When designing for change, you should change the what to how.
The what is the requirement of the business. As any seasoned person involved in a role within software development will tell you, requirements frequently change. As such, the software has to be adaptable to meet those changes. The business is not interested in how the requirements are implemented by the software and infrastructure teams, only that the requirements are met precisely on time and on budget.
On the other hand, the software and infrastructure teams are more focused on how those business requirements are to be met. Regardless of the technology and processes that are adopted for the project to implement the requirements, the software and target environment must be adaptable to changing requirements.
But that is not all. You see, software versions often change with bug fixes and new features. As new features are implemented and refactoring takes place, the software code becomes deprecated...
