.png)
One of our clients is a global leader in investment banking. In our discussions with the senior directors in the IT division of this organization, they told us about some frequent issues with their Order Management System. The OMS was a crucial revenue generator for the firm as it was the system used by sales for entering and managing all orders for financial securities on behalf of their Private Wealth Management clients.
The application had become hard 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. It used a mix of open source and proprietary technologies. As the code was legacy, there was no automated test coverage. It was critical 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 had taken the shortcut to add new products into the application without touching the functionality of the existing products.
Our strategy to solve the issues was as follows. We decided to remove the code duplication. It 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, large-scale code refactoring would have been risky, almost impossible.
The crucial 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 an order, execute the order at the exchange, and allocate an order to a client account. Another lifecycle – create order, amend an order, execute the 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. Meanwhile, we onboarded the build process into Jenkins. The test cases run as part of the Jenkins build. 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 ensures that we did not break the functionality at any stage.
In summary, we can reduce code duplication, enhance maintainability and adopt the best agile development practices.
