Too Many Configuration Properties? Here's the Correct Approach
Hierarchical Key Configuration Points (KCPs) are an important differentiator of Highly Configurable Software. Hierarchical KCPs are the organization of minimal KCPs where the successive values override each other forming a tree structure. For more information on KCPs, please refer to the previous article, Defining Key Configuration Points in Software. The unique and important difference is that each KCP is represented by a tree of potential values, where the root value of the tree is the default value, and the hierarchy is customizable to meet the user’s needs.
Hierarchical structure provides the following benefits:
- Dynamic KCP resolution using the hierarchy
- Transform from simple name and value pair properties mindset to an entirely new multidimensional hierarchy of KCPs
- Simplified configuration of new environments using the default hierarchy that contains the system type (for example: test, integration, production).
- Refer to our previous two articles for the expanded benefits of Highly Configurable Software and KCPs, The Importance of Writing Highly Configurable Software and Defining Key Configuration Points in Software for more general benefits relating to Highly Configurable Software.
With these benefits in mind, let us discuss how to define the default hierarchy. First, we must identify what the influencers are that cause different configurations? These influencers should be the driver for each level of the hierarchy. The next question to ask is which influencers drive the hierarchy? In order to maintain the smallest number of values per key configuration point, the broadest influencers should be toward the top of the hierarchy, and the narrowest toward the bottom. These hierarchies are completely customizable. Below is an example of a default hierarchy (Figure A):
This default hierarchy provides the default values at the top level, for which we recommend using development values. This creates a ‘do no harm’ default that anyone can use. The next level in the hierarchy corresponds to the environment type (Test, Integration, Production, etc.). Finally, the last level in the hierarchy correspond to the hostnames (NOTE: In a cloud environment, we do not recommend using the hostname).
To further explain the concepts of hierarchical KCPs, let’s explore an example implementation using the default hierarchy.
The example above is the hierarchical tree representation of values for a thread pool size. At the root of the tree is 5, the default value. The development value is simply the default root value, and does not have a distinct place in the tree like Production. Anytime that a developer initializes and starts their environment with the default configuration, it pulls from the root in order to configure the application. The next level of the tree in our hierarchy is decided based on environment. The following environments have been identified (Name:Value): Production:100, Integration: 75, and Test: 50, but each implementation can define their own set. Each environment has the ability to determine its value; consequently, the KCPs resolution happens seamlessly. The second level of the tree is broken down by hostnames. There are two hostnames identified in production (Name:Value), Zeus:200 and Hades:80. In this example, since the Zeus environment has better hardware specifications, the configuration allows the application to be run with more concurrent threads; whereas, Hades has a smaller environment with a lower value. Any other production environments that are not in the present hierarchy will take the root of the subtree, which is Production:100. Though this default hierarchy of environment and hostname works for many of the KCPs, the hierarchy can also be customized to create other flexible models, as seen in the next example.
In the above hierarchy (Figure C), we start again with the default root value and progress through additional levels of the hierarchy. In the US, unemployment reimbursement can be paid on a weekly basis. The federal government sets a default monetary value for all states to use or override as necessary. Each county in a specific state may also override the state value. In the customized part of this hierarchy, we change our hostname level into the State and County levels featured. This allows us to configure the application based on locational data related to State and County instead of hostnames. This fits our intended model, allowing us to specify the minimum value to be paid per the federal limit, the state limit or the county limit, as the specificity of the application increases. By keeping the Environment level, we can configure our application for external services easier across environments. Examples of these services include JMS servers or Database servers, while establishing do no harm defaults in the hierarchy. Let us look at an example of this customized hierarchy.
Shown above (Figure D), the hierarchy follows our explanation in the figure above (Figure C). In the example, the federal default production value is $400 per week (NOTE: The default root of the tree is $250, which is our development value). Any state can increase this value, so Mayland sets its value at $425, while Virginia decides that $450 is sufficient. Furthermore in Maryland, Howard County changes their value to $410, and Montgomery County changes their value to $435. If no county value is defined, the configuration returns the subtree value which is the state’s value. For example, if a Baltimore County application does not specify its county, then it will take the value of the Maryland node. In specifying the minimum amount of configurable values per KCP, hierarchical KCPs are able to configure our environment in new ways.
In the industry, hundreds if not thousands of different environments can exist at any given time, each with their own configurations. By using Hierarchical KCPs, one hierarchy can scale to enormous size by reconfiguring every product across environments. Not only reducing the number of KCPs needed, this instrument of Highly Configurable Software centralizes the management of the configuration, creating opportunity for further automation. The power of Hierarchical KCPs is boundless!