Definition of Key Configuration Points in Software
Properly identifying key configuration points is foundational to achieving the benefits of highly configurable software as outlined in the first article The Importance of Writing Highly Configurable Software. This article, Defining Key Configuration Points in Software, outlines the characteristics and attributes that identify key configuration points, alternative solutions and instances where key configuration points are not appropriate.
Through the implementation of Highly Configurable Software, below are common example usages for key configuration points. This is not an exhaustive list, but gives the most popular and typical key configuration point criteria:
- Environment specific key configuration points are identified by instances where the value changes between environments (development, test, integration, and production). Examples of these key configuration points include but are not limited database hostnames and database passwords.
- Uniform Resource Identifiers (URIs) to internal and or external end-points or services. These end-points or services often change over time and or require changes for outages. Examples of these URIs typically include security service endpoints or enrichment services.
- Virtual or cloud environment scaling settings. Thread counts and other scaling related key configuration points often require tweaking.
- Copy-n-paste code reuse instances should be fixed by refactoring and adding key configuration points; thus, eliminating the duplicate code during the refactor.
- Application specific key configuration points occur when applications have unique driving key configuration points of their own. For example, consider a program that is written for all states to manage unemployment insurance regulations. In this example, state would be a key configuration point as there are likely to be unique settings on a state-by-state basis. Remember to step back and look for these unique key configuration points in each application.
In some instances there are better alternatives to key configuration points. Like all concepts, key configuration points can be overused or improperly applied. In those cases, the value and benefits from high configurable software do not occur, and in some cases it can cause confusion and take away from the value of key configuration points.
- Single valued configuration points that do not meet any of the key configuration point criteria should remain hard coded in the application. Configuration overload can occur and cause confusion in cases where too many needless configuration points are added. As the application evolves and changes these hard-coded values can always be refactored into key configuration points.
- Use enumerations or constants over key configuration points for multivalued configuration points that do not meet any of the key configuration point criteria. Typically this occurs for string constants.
- If a recompilation is required, then the change is not a good candidate for a key configuration point. Remember, key configuration points provide the ability to change values dynamically with a simple application restart without re-compiling and deploying the application. An example of this is switching from topics to queues for JMS as this should require an architecture change. Similarly changing from Oracle to MongoDB database drivers class names would usually require a recompilation.
Highly configurable software becomes easier and more rewarding by identifying and using key configuration points. Applying all of these techniques empowers applications to take full advantage of the benefits that come with highly configurable software.