Design for change

As part of your design efforts, identify elements of the solution that change often or need to change urgently under certain circumstances. As a best practice, this type of element is often maintained outside a traditional software development life cycle. Once identified, the team can design and leverage approaches to ensure that changes are made in a quick and cost-effective manner.

Consider an application that collects and processes requests for small business loans. The application likely contains several elements that change frequently or urgently and other elements that do not change frequently.

You, your team, and stakeholders identify elements of the application that must change often or urgently.

Consider the following questions to identify elements that are subject to change:

• Are there business-based decision points in the process that change often or need to change with urgency? For example, automated rules for approval or pricing. 
• Do certain details change often or need to change with urgency? For example, product details like description and price.  
• Are there screens where the content needs to change often or urgently? Can the content be data-driven rather than hard-coded? For example, survey-type questions and best practice checklists.

As the application development progresses, continue to explore the potential for change in each new requirement and design. 

Work with your team to design a comprehensive approach that enables frequent or urgent changes to areas of the application where required.

In the following image, click the + icons to see descriptions of the technical design approaches that are often used to help support frequent or urgent changes. 

In addition to the technical design, the following steps are essential to make frequent or urgent changes a reality:

1. Educate subject matter experts on the key business or decision models used in the application, such as decision tables.
2. Leverage automated testing to validate changes more quickly, with more confidence and less risk.
3. Work through the details of how to make and validate changes.
   1. In some cases, you apply changes directly in production. 
   2. Other cases require you to make the change and validate it in a development or QA environment before applying the change in production.
4. Involve the appropriate system change and release governance leaders in your organization to get approval on the approach. 

Check your knowledge with the following interaction.