In this post I will be introducing the main concepts regarding Enterprise Application Configuration, which will form the basis for the rest of this blog series.

Most applications need some kind of configuration to store useful settings and values that should not be hard-coded into the compiled program.  Configuration can take various forms, but some of the most common uses are:

• Storing environment-specific values such as connection strings, file paths, machine names.
• Storing values that allow a program to change behaviour depending on the user, which is very common in UI-driven applications such as multi-tenant ecommerce solutions.
• Storing semi-static business data that is subject to change outside the lifecycle of the program code, such as tiers of shipping charges by weight in an ecommerce application.

In general, the larger and more complex an application the greater the demand for configuration will be, the more settings will be held in configuration and the more complex the configured data.  It is also these larger applications that tend to have the strongest governance requirements and for which there is least tolerance for loss of service that can result from an incorrect configuration change.

This is the problem space we at 345 Systems have been addressing lately, and giving a great deal of thought to.  Broadly speaking, when we talk about systems requiring Enterprise Application Configuration we are looking at solutions that these general features from their configuration solution:

• Applications deployed across a number of separate machines.
• Applications whose configuration needs to be synchronised across multiple machines.
• Applications that are distributed across data centres, especially geographically dispersed data centres where latency of data access may be an issue.
• Cloud-based applications where nodes are provisioned based on load, especially where administrators have no control over the actual node the application runs on.
• Applications whose development lifecycle requires deployment through various environments (e.g. Development, System Test, Pre-Prod, Production), where tracking changes in configuration across these environments is vital.

Throughout the rest of this blog post series we will have a look at some of the issues we have come across when building and maintaining mission-critical enterprise systems and how we have sought to mitigate them when we wrote our own Enterprise Application Configuration solution cloco.