Share This Page


Share This Page


Configuration Management in Trading and Risk Management Systems

Configuration Management is a key activity in Trading and Risk Management (T&RM) systems during project implementation. Hence, it needs to planned and scoped carefully. As a Project progresses, there is a huge dependency on configuration management activity to ensure all configuration is tracked, delivered, deployed, tested and signed off by the relevant Business Stakeholders during various planned validation phases.

Trading System configuration covers various parts of the Trading System application relating to defining products for various asset classes (all of their related elements), Operations/Tasks Automation, reports definition & User Rights etc. Configuration Management is extremely tedious and cumbersome as a particular environment configuration needs to be replicated from an existing environment to a different environment/across multiple environments.

To enable ease of porting of configuration, most of the Trading Systems might provide native tool(s) to help with the import and export of configuration(s) across the environments. Native Tool(s) provided by Trading Systems Vendors around Configuration Management usually cover majority of the configurations available in the Trading System. Where ever native support is not available, the configuration needs to be performed/managed as a manual activity.

Greenfield Implementations or Upgrade of Trading Systems gives rise to design, development and testing of various configuration(s) as part of Project delivery. These configuration(s) like in any project implementation, needs to be tested and be a part of the Production/Project release. Given the presence of various deliveries related to configuration both from Trading System and at times from the In-house development team(s), the need to have these configuration(s) tracked in an orderly manner and deployed to various environments, plays a crucial role in ensuring t the Project is executed in a smooth and safe manner.

It is very normal to have more than 20-30 Trading Systems environments which might be in use for any Greenfield/Upgrade project(s). This is due to diverse project needs/application/Business requests/Custom requirements.

Below is an illustration of an Environment demand that would arise in a Greenfield/migration project involving Trading Systems This is with the assumption that the Project is going to run for a whole year.

5 Steps to Configuration Management in Trading Systems

Trading Systems project(s) are usually executed in an agile fashion. Hence, it is imperative to validate the configuration of the entire project at various pre-defined stages within the project.

The Goal of validating the entire configuration of the application under build or what we say “GOLD” source, differs from Project to Project. It is also based on Organizational needs/Project Context/availability of resources in terms of Project Staff/Go-Live date etc.

Configuration Management Steps

1. Identification of Configuration Manager

The identification of Configuration Manager is an important and first step during the setup of Configuration Management process for a Trading Systems application. Most of the time, this role is taken up by a senior person within the Organization having prior experience in an environment management/support role.

It is desirable to have prior experience of the Trading System which is going to be used for the Project. But at times, this might not be possible. Given that these project(s) in case of big implementations, run for a period of 2-3 years, anyone with reasonable experience around configuration and management of the environment(s) is good enough to fill this role. In any case, there is always adequate training and support provided by the Trading System Vendor around the native Configuration tools.

2. Configuration Management Process

Vendors usually provide their recommendation on how the Configuration Management process needs to be set up for the project as part of their Project implementation activity. The Configuration Manager in most of the cases, proceeds with the activity/workflow suggested by the technology Vendor. In some cases, it may require a few modifications to meet the Organization/Project standards.

5 Steps to Configuration Management in Trading Systems

The above diagram describes the basic workflow diagram around Configuration Management Process for a project involving Trading and Risk Management System.

3. Environment Naming

All the T&RM system environment(s) which are used for Build activity for various stream(s) for FO, BO, MO and Integration are named as “Sliver” environments.

“Silver” environments usually refer to the origin of the configuration which need to be delivered by technology vendors or by In-house Project Team(s).

“Integration” environment refers to the environment where the changes from the “Silver” environments are deployed and tested. This is to ensure that they satisfy the Business requirements and also do not impact any other configuration within the system.

Once all the Configuration within the “Integration” environment proves to be successful and working, it is deployed into the “GOLD” environment.

“GOLD” environment usually refers to the “END POINT” for a particular configuration originating from the “Silver” environment source and which has gone through the testing process in the “Integration” environment.

4. Execution of the Configuration Management Process
5 Steps to Configuration Management in Trading Systems

Post the initial phase of setting the Configuration Process and naming environment(s), a small change is required as described in the above diagram. This change caters to the periodic refresh of the “SILVER” environments with configuration(s) which are now available in the “GOLD” environment.

As the project progresses, the “GOLD” configuration source becomes very crucial . This is because this is the single source of truth in relation to the configuration for the project. This can be achieved only if we ensure every configuration is tracked from Silver → Integration → GOLD. With this, at any point of time, we can come up with a “Delta”/”Difference” in configuration(s) across various environments & GOLD.

The project also requires environment deliveries for various validation activities like System Testing, System Integration Testing, User Acceptance Testing, Dress Rehearsal, Technical Dress Rehearsal & GO-Live. For all these Project validation activities, a new environment is created from scratch. After this, the configuration at that point of time is extracted from “GOLD” through the native configuration tool and then imported back into the “Target” testing environment.

The above process of pushing changes to “GOLD” in an orderly fashion after the required level of testing is completed and then building the new Mx.3 environments with latest configuration imported from GOLD, fits well into the agile /continuous delivery of T&RM project(s).

5. Configuration Tracking & Metrics Reporting

The effectiveness of the Configuration Management process depends on the tracking of various configuration(s) originating from “SILVER” environments, then to “Integration” environment for validation/testing, and finally into the “GOLD” environment.

The above tracking can be setup in a simple xls . The field details can be around tracking, finding the delta around the configuration across the environments or any other reporting information/statistics.

Config # Environment #1 Environment #2 GOLD
Deployment Date Deployment Status Deployment Date Deployment Status Deployment Date Deployment Status
1 xxx.111 COMPLETED xxx.111 COMPLETED
2 yyy.111 FAILED bbb.111 PENDING

Based on the above initial table/matrix structure, we can extract s reporting as follows:

  • # of Deployment(s) Per Day per Environment.
  • # of Deployment(s) Failed/Passed Per Environment.
  • Configuration “DELTA” across two environment.

Pitfalls/Issues during Configuration Management implementation

Below are few of the factors that might hinder the smooth functioning of the Configuration management process:

  1. Human error during deployment resulting in bad user experience during testing phases.
  2. Project team, apart from the Configuration Manager, having superior access rights to deploy/modify configuration.
  3. # of environments is high and # of Deployment requests per Environment is also very high.

To schedule a meeting with our experts or for more information, please write to us at

Let's Talk About Your Needs

Thank you for your submission. We'll be in touch.