Vasyl Soloshchuk
9 April 2019

Retiring Technical Debt from FinTech Projects: Case Studies

In one of our previous articles, we described what pushes FinTech companies migrating to microservices. When they started out, they chose a plain strategy, but as the system have grown in complexity, they have felt the pressure of technical debt.

What drives projects forward today often weighs them down tomorrow. Technologies that were common several years ago are now going to be replaced with state-of-the-art ones. Along these lines, Jason Barry, CTO at Tradier, financial services cloud and open APIs platform for US-based trading, admits that though Tradier initially chose XML for the platform, he now wishes they had built it using exclusively JSON.

“Most of the APIs are JSON-based, though when we launched our product six years ago, XML was still something that people wanted to use. So, we actually launched an XML-focused solution as well. If we had to rebuild all the stuff that we have today, we’d use JSON exclusively.”

In this article, we’ll investigate the experience of FinTech CTOs who successfully avoided technical debt and completed reengineering. Take a look—their tips can be useful for your own project!

Isolation layer implementations by MyVest

Mark Worsey is CTO at MyVest, an enterprise wealth management system. Ten years ago, the application stack he worked on was certainly much more monolithic. MyVest had a fairly large application due to the technology strategies common at the time. By shifting an isolated piece of the application stack to a microservice architecture, the company began to realize the benefits of accelerating new feature development and isolating regression issue impacts.

The idea of reengineering was to write the layers of isolation and segment the methods more granularly so they could interface with each other, as opposed to having one giant monolithic build.

“We started this in a complex part of our platform, our portfolio optimization engine, and that drove some great learnings within the team.”

Mark put a lot of effort into not only remodeling the engine but educating the development team at large. The company assembled skilled architects with years of experience, next to the small program teams working on those microservices. Although this initially seemed like a huge challenge in terms of setting the “microservices mindset” among the teams, it bore fruit in the long run.

Every day, the technical team brainstorms on upcoming commitments and the forecasted product strategy to decide what needs to get to market and when exactly to take that step. This thought process is in sync with customer-facing and revenue-generating aspects when it comes to legacy architecture that needs to be reengineered:

“How we refactor our application to keep us current and competent while at the same time delivering new customer-facing IP that differentiates in the market is an ongoing balancing act—part science and part art.”

How ASI eliminated negative legacy influence

Rishi Srivastava, CTO at Advisor Software (ASI), a digital advice platform, is managing a wide choice of wealth-management solutions. The company’s main challenge is that the plethora of legacy apps prevents it from focusing on particular products and providing these out of the box. Obviously, it also causes problems with integration and sets some limitations on new functionality. Rishi says:

“We have found a way to largely eliminate the negative influence of the legacy code: dividing into core components and visualization. At ASI, the core code remains intact and is a gold mine for the company; visualization, however, may change from one system to another.”

According to Rishi, ASI has a blend of legacy products and more modern ones, so the architecture tends to be distributed and often employs microservices.

“We apply . . . technologies like continuous integration and deployment methodologies in which we are actually trying to get more product releases and fewer cycles. Also, we are using ECS and Fargate technologies for a scalable architecture.”

Retiring desktop solution by Portfolio Pathway

Ryan Brucker is CTO at Portfolio Pathway, a cloud-based platform for financial advisors, asset managers, and broker-dealers. Portfolio Pathway is basically a .NET solution with other Microsoft products applied, such as SQL Server. According to Ryan, this technology stack makes it possible to do the very data-intensive jobs. They started with WinForms desktop applications for internal use and are still in the process of retiring them.

Unfortunately, it’s a common thing that users refuse to switch to the new platform.

Vasyl Soloshchuk, CEO at INSART, FinTech engineering company, states that migrating clients to the new system means more than just migrating data. He took part in the project that had been experiencing reengineering, and they had to run both legacy and new systems until the users finally jump over the new one.

“You (or the product owner) teach them how to work with the modernized system. Here a major problem may arise: clients may dislike the changes, overlooking the benefits and overstating the limitations of the revamped software. That’s why the migration plan should be customized for every client and should be understandable and acceptable.”



What was your attempt to retire technical debt? Have you succeeded at reengineering, or are you still in the process? Or how have you managed to avoid reengineering? The FinTech CTO community is waiting for your input!