Order Management System

One of our clients is a global leader in investment banking. In our discussions with the senior directors in IT division of this organization, they told us about some issues they were constantly facing with their Order Management System. The OMS was extremely important revenue generator for the firm as it was the system used by sales for entering and managing all order for financial securities, on behalf of their Private Wealth Management clients.

The application had become difficult to maintain and did not conform to the development standards that the organization wanted to set. The firm wanted to embrace agile development practices, full automated test coverage, automated deployment, faster delivery to the business, etc.

As we delved deep into the code, we started uncovering issues. It had been developed over a long period of time. It used a mix of open source and proprietary technologies. As code was legacy, there was no automated test coverage. This was important, but challenging. There was one more problem, the code had been copied over multiple times, to cater to different types of financial instruments. The developers who did not understand the legacy code deeply, had taken the shortcut to add new products into the application, without touching the functionality for the existing products.

Our strategy to solve the issues was as follows. We decided the code duplication had to be removed. This would reduce the cost of code maintenance many-fold. It would also allow us to leverage all the other improvements we do, to all products. The other major decision was to develop a set of extensive automated test cases. Without automated tests, any large scale code refactoring would have been really risky, almost impossible.

The most important function of an Order Management System is to manage the order lifecycle. Hence the application is essentially a collection of order workflows. The workflows were implemented as SOAP services taking XML as input and giving XML as output. The order lifecycle is essentially a series of such workflows. For example, one order lifecycle could go as follows – create order, execute order at exchange, allocate order to client account. Another lifecycle – create order, amend order, execute order.

We decided to implement tests for these workflows. We developed a framework in which a developer can create test cases for such a workflow through configuration only. A test case includes XML message templates for each step of the workflow, the expected outputs for that step and the outputs that feed into the next step. The framework ties the output of one step to the next. The tests are run automatically through JUnit. At the same time, we on-boarded the build process into Jenkins. The test cases run as part of the Jenkins build. Further SonarQube was used to produce reports for the project.

With a comprehensive test suite in place, we refactored the codebase. We merged the code for multiple products into a single codebase. We evolved a package structure based on functionality, as opposed to technical layers. The continuous build process ensured, we did not break the functionality at any stage.

In summary, we were able to reduce code duplication, enhance maintainability and adopt best of agile development practices.