This is the final post in a series related to product configuration management (PCM) patterns. The earlier posts covered a variety of different PCM patterns including the following:
- Code-Time PCM Pattern
- Build-Time PCM Pattern
- Release-Time PCM Pattern
- Install-Time PCM Pattern
- Run-Time PCM Pattern
Each of the above patterns is named based on the point at which configuration options are set. This is an important factor since it determines both the inherent level of security of the option and the relative ease with which a configuration option can be changed. In general, the earlier such changes are made in the product’s life-cycle, the more secure the configuration option. However, this comes with a sacrifice of agility, since such changes typically require a larger amount of effort to implement and validate. Configuration changes made late in the product’s life-cycle have the opposite attributes. They are generally associated with insecure configuration options, but require little to no effort to implement and validate.
Note that these characteristics are not absolute. It is possible for early-phase PCM patterns like the Code-Time PCM pattern to be more agile. This could be accomplished by developing sophisticated automation to implement and validate configuration changes. Likewise, late-phase PCM patterns like the Run-Time PCM pattern can be made more secure. For instance, a client-server activation system can be used to check all configuration changes and enforce any required security protections. By and large, it takes some additional initial investment in technology in order to overcome the inherent deficiencies of each PCM pattern.
None of the PCM patterns should be considered as superior to the others. In fact, each fills a distinct need and can be the best choice for specific scenarios. The different PCM patterns are not mutually exclusive either. Nothing prevents a given product from using a combination of PCM patterns to achieve its configuration needs. In fact, this cocktail approach may produce much better results than using a single PCM pattern, since the best PCM pattern will be applied to each individual configuration need, rather than forcing all options to adapt to a single PCM pattern. Note that using multiple PCM patterns for a single product may significantly increase the complexity of managing and tracking configuration options, so this factor should be weighed in when deciding how many different PCM patterns to use.
Scale is one of the dominant factors that will be used to determine which PCM pattern to implement for a given use case. By scale, I mean the number of different product configurations that may need to be supported. If only one configuration is needed, then it is not a configuration; it’s simply standard functionality. If a few configurations are needed, then Code-Time or Build-Time PCM patterns are likely sufficient. If a dozen or so configurations are needed, then the Release-Time PCM pattern is probably the best choice. If very large numbers of configurations are needed, then Install-Time and Run-Time PCM patterns are likely the best alternatives. To determine the number of possible product configurations to be supported, count each unique combination of configuration option settings expected to be used. Also, be sure to include those configurations which are only used internally, such as test or debug configurations.
Keep in mind that the PCM pattern that is the best fit for today’s needs may buckle under the demands of the future. Make realistic projections for the scale of your product’s configuration needs going out at least a couple of years. While choosing a higher scale PCM pattern today will take some extra work and investment, it will be well worth it once the time comes where it is needed. The alternative, of waiting until the product’s configuration needs have grown in scale beyond the current PCM pattern’s capacity, will likely cost you far more in the end.