Run-Time Product Configuration Management Pattern

This post is a continuation of a series related to product configuration management (PCM) patterns. Here, I discuss the implementation, features and drawbacks of the run-time PCM pattern. With this PCM pattern, a single installation of a product release can be configured as desired by the end-user.

Unlike the PCM patterns discussed in earlier posts, the run-time PCM pattern puts the end-user in full control of the configuration options. To facilitate this, the application UI must contain screens for presenting and configuring product options, and the application functionality must contain run-time checks of the configuration options to control its behavior. Some initial investment must be made in developing the configuration screens and run-time checks, but once that is complete, a single code base, build, release, installer and installation can be used to create any product configuration. This makes it the most scalable of the PCM patterns, especially suited for cases where there are large numbers of possible product configurations.

Run-Time Activation

In its simplest form, the run-time PCM pattern lacks any security, making it useful for only those configuration options which have low intrinsic value or associated third-party royalties. Typically, this type of PCM pattern is employed for handling user preferences, rather than major product features. However, with some additional investment, higher levels of security can be provided that make the run-time PCM pattern a viable mechanism for handling high value options.

One proven method for overcoming the inherent insecurity of the run-time PCM pattern is to couple it with a client-server feature activation system. Each time a user attempts to enable a high-value option, the configuration sub-system will contact a centralized server for instructions. The first time the user attempts to enable such an option, the server will direct the client to present an activation experience. This may be a simple as presenting a license agreement for acceptance, or it may involve a financial transaction to purchase the desired option. Whatever the experience, once it is completed from that point forward, the option is considered to be activated. The user can then enable/disable the option at will.

A run-time activation system is not a simple task to implement, as it requires a highly scalable server, consideration of privacy concerns, possible support for financial transaction processing, and a secure client module that cannot easily be hacked. For smaller businesses or niche products, it may make more sense to use a commercially available activation system rather than attempt to develop a proprietary one.

Application Footprint

In order for the run-time PCM pattern to function properly, the client installation must include all resources and functionality necessary to support the universe of possible configuration combinations. In some cases, this may dramatically increase the size of the installation on the client system. Also, for those applications that include service programs, system tray applications or other continuously running executables, the requirement of having all features persistently available for run-time options can result in excessive consumption of system memory or CPU cycles. Such impact on the client system can result in the application gaining a reputation as bloat-ware.

When evaluating the system performance impact of excessive consumption of storage, memory and CPU resources, it is often memory that proves to be the most limited resource. As such, applications using the run-time PCM pattern should design the configuration sub-system such that, when possible and appropriate, functionality associated with configurations options is unloaded from memory when the corresponding option is disabled.

Implementation

For run-time user preferences, a typical method for storing the options on Windows systems is to use the system registry (typically under HKEY_CURRENT_USER). This leverages existing standard functionality for storing and querying such configuration settings, and also can handle multiple users of an application. The application then needs only to implement the appropriate run-time checks of these registry entries to control functionality execution paths.

Similarly, per-machine configuration settings can be stored in the system registry under HKEY_LOCAL_MACHINE. The system registry is normally used for storing low value configuration options, since the system registry can be easily edited by end users. If a given option requires greater security, such as that afforded by a run-time activation system, then it will likely be stored in a much more secure format, such as a protected database or an encrypted file. It is also possible to use the system registry in such cases, so long as the data stored there is in an encrypted format.

Preparation Effort

All of the work involved with supporting the run-time PCM pattern is in the preparation effort. The primary work involves developing application UI for presenting configuration options to the user, and adding run-time checks to control program execution paths based on the configuration option settings.

As with the release-time and install-time PCM patterns, it is possible to substantially optimize the testing process for products that use the run-time PCM pattern. QA can rely on a single code base and set of binaries as the foundation for testing. Individual configuration options can easily be tested with simple application UI selection changes. This provides QA the ability to instantly generate any desired configuration for testing purposes.

Test/Fix Effort

Since the actual configuration changes have been pushed out beyond release to the customer, there is no need for specific configuration testing. Only the proper functioning of individual configuration options needs to be verified. This effectively eliminates the test/fix cycle for configuration changes.

Effort Summary

Following is a summary of the effort involved in handling multiple product configurations using the run-time PCM pattern:

Worker Time Machine Time Work Description
80 hours Insert conditional run-time checks
80 hours Develop UI configuration functionality
80 hours Test preparation for configuration options
240 hours 0 hours Sub-total – preparation effort
240 hours 0 hours Total effort

The run-time PCM pattern has a relatively large preparation phase, but requires little to no investment of effort beyond that. The one-time cost of the preparation phase is very quickly offset by the saving achieved through the elimination of downstream configuration work and testing. This makes the run-time PCM pattern the most scalable of all the PCM patterns, and well suited to cases where the number of possible configuration combinations is huge.

A potential downside to the run-time PCM pattern is its relative insecurity. However, as discussed, the use of a client-server activation system can be utilized to better protect certain high-value configuration options. This requires an increased investment in the preparation phase to either develop a proprietary activation system or integrate a third-party activation system. It also will incur continuing costs of operating and maintaining the activation server. However, the end result can be the holy-grail of product configuration management, with a secure, scalable, user-driven, configure-to-order mechanism.

About Daniel Brannon

Daniel Brannon founded OSoSLO in 2009 to provide software tools and services for business and technology professionals.
This entry was posted in Product Configuration Management. Bookmark the permalink.

One Response to Run-Time Product Configuration Management Pattern

  1. Pingback: The Superhighway to the Cloud | OSoSLO is Oh So S. L. O.

Leave a Reply