Creating consumable changes for version 1.1

Imagine that we want to add some kinds of improvements in the next version of the Lunch Catering application. Before beginning work on this, it's important to understand what kinds of changes can be safely consumed by customers after upgrade.

As the article mentions, there are three categories of how features can be consumed:

• They are automatically in force after upgrade
• Admins can Opt-In to enable them
• The application can be customized to use them

Let's consider some examples of each of these kinds of changes.

Example of an automatically consumed change

When you improve your implementation in a way that does not adversely impact any users, and no steps are required to benefit from them, then those changes fall into this category.  Some examples that could apply to the Lunch Catering system we have built would be:

• Improve the implementation of the Meal Order Service to make it more efficient. For example, it could probably obtain the same information with fewer queries.
• Refactor of code to improve clarity or maintainability. Take caution with the renaming of object definitions, however.  If you refactor any Service API interfaces, be sure to provide a wrapper to maintain backward-compatibility with the older interfaces.
• Fix a defect - but only if the customer could not have been taking advantage of the "defect" to create supported value in the offering.
• Improve the implementation of non-customizable Processes (especially "Technical Processes" that are part of the "behind the scenes" implementation), or other objects, that were set to be not customizable in the earlier version, as long as there is no apparent behavior change, and this has no other side effects on the system that customers may have been relying on 

This is not a complete list but gives the general idea.

Example of an opt-In change

The Java-based Meal Order service that was introduced in version 1.0 calculates the cost of a Meal Order using a configurable tax rate. Now a requirement has come in that the tax rate needs to reflect the state or region where the Employee is based. Clearly this requires a revision to the code that computes Order cost, so that it can obtain the Employee's home state, and look up the relevant tax rate. However, it might also disrupt existing customers who have not yet configured the rate information from each region.

One way to make this kind of change "opt-in" would be:

1. Introduce a new Setting of type Boolean called Use Regional Tax Rates, with the default value False.
2. Build out the configuration model for tax rates for different regions.
3. Integrate this in the code, but be sure that without turning on the new Setting, the previous computation delivers the same results when GetOrderInfo is invoked.
4. Document the use of the new Setting and how to configure regional tax rate data.

Example of a change consumable by customization

These kinds of changes are made by providing purely additive value and then instructions on how to consume them. We will dive into an example of this in the next topic.