Release Management in Banking

Organizations buy software to help them solve their business problems. The software comes usually packaged with a maintenance contract which allows the companies to get support when needed and to update to the latest releases of the software.

In general companies are trying to be up to date with the software releases as much as possible in order to utilize new functionality and to get the latest bug fixes. This is especially true for business intelligence software that gives the organization a competitive advantage by delivering invaluable insight into the business. Those companies are therefore pretty open when it comes to install new service packs, hot fixes or patches.

This is different for most of the larger financial services organizations.

I am not talking about mayor releases here, i.e. a totally new version with new functionality, enhancements and maybe a better GUI (Graphical User interface). Those migrations usually need very extensive preparation time but for most software companies these mayor releases only occur every 2-3 years.

Larger banks require even for minor releases or service packs a long preparation phase and intensive testing before an upgrade can be implemented. This has to do with the restrict risk & compliance rules, the sensitivity of the data, the business model of financial institutions and with the fact that banks have often outsourced the IT service handling the migration.

They are installing the software typically in a sandbox environment; test the software thoroughly until the results for all their test scenarios are satisfactory and then they plan the technical steps for the upgrade. Part of the testing on the IT side includes carry out random installations in their machines and test for no compatibility issues with other standard applications at the bank.
This process usually takes 3-4 months.

The duration of the implementation – after the completion of the testing and planning mentioned before – is then dependent on the changes to the software and the internal process. The usual setup includes a development, a test and a production environment and proper procedures to move between those environments. As a rule of thumb such an implementation takes another 2 months. On average a migration to new software versions takes therefore in total ~ 6 months.

While there is software in the market that requires a much longer migration cycle, this is a pretty good estimate for most BI software migrations in financial services organizations.
However, some financial services institutions exceed this time by far and are looking for tools and external support to streamline their processes.

The procedures are especially inefficient when it comes to hotfixes and patches that are supposed to solve immediate issues. In case of a not foreseeable real issue that could be a threat for the daily business even banks are very open to implement patches quickly. This patch still needs to follow certain test procedures in the sandbox but this is much faster (can be done in two days till a week). Nevertheless, the companies try to avoid this as much as possible due to the extensive test scripts.

The required effort also depends on who owns the responsibility for the BI resources. As a rule of thumb, if the BI department is the owner of all the resources, it is usually less problematic and the processes are more promptly. Otherwise you could run into delays since you do not have all the resources at your disposal.

In summary, release management is becoming a very important topic for the financial services industry as it ties up budget, resources for a longer time period. As a consequence, those software vendors that offer a single, integrated tool based on a unified platform architecture – usually those that remained independent without the hassle of product integration issues due to newly acquired software – with a simple migration path for their customer base, will have a huge competitive advantage in the market space.