Organizing Key Configuration Points
Highly configuration software thrives on centralized URI based key configuration points (KCPs) in combination with hierarchical configuration. Once these two techniques are implemented, the next biggest challenge is being able to organize these KCPs into the lowest common denominator. For most organizations, this is a shift in mindset and process, rather than a code change. KCPs are able to move further up the hierarchy, which encourages centralization and sharing at the broadest category, eliminating any duplication. We recommend organizing KCPs into three categories: individual products, separate product suites, and globally shared KCPs. This is a recommendation that has worked well for most organizations, though feel free to update the categories based upon different business requirements.
Application configuration points are used for specific products and are not shared because they do not apply to any other product. Normally, a development team will use these configuration points to override the more generalized configuration points to meet the specific needs of an application. The specific application team controls the configuration, and would not share them outside of their environment. User credential overrides for a specific endpoint URI is a good example of application specific configuration. This saves configuration details by reusing the higher level URI and only overriding the custom configuration where it is needed.
Product suites consist of two or more products with similar attributes, inter-product relationships, or developed by the same team. Defining configuration points at this level ensures that each of the products in the suite are maintained across multiple teams in a shared space to support all products in the suite. For example, Google maintains multiple user applications: Gmail, Drive, Calendar, Maps, etc. Each of these products share specific integrations with each other, and can use a shared set of KCPs as such. For example, when a user attaches a Google Drive document into an Email, the resolution may be at a shared endpoint that all applications use. The singular set of KCPs is maintained across all of these products. Simpler configuration management strategies emerge over time as the product suite shares more and more KCPs that are specific at this level of the hierarchy.
Global configuration points are at the highest level and span across all users and products. The entire intended development audience must be able to use them, as the KCPs are publicly accessible. The organization that owns these configuration points can make global changes by simply changing the single KCP. Some common examples are messaging hubs or other shared service endpoints that are globally accessible.
The goal is to promote KCPs to the broadest applicable category to encourage broader KCP sharing. By specifying the key configuration points at each level, default values form through collaboration and configuration sharing. These defaults become promoted to a higher level, increasing reuse across product suite teams and across the enterprise. Application owners need less configuration by using the default configuration set at the highest level, while increasing the leniency of specific customer needs. This flexible strategy gives developers the confidence that the application behaves the same over multiple environments, creating more time to complete the solution for the end customer, while sharing common components throughout an organization and the industry as a whole.