How Technical Debt Impacts the “Build vs. Buy” Dilemma in Banking
Why would you (and your bank) choose to partner with a digital transformation platform provider instead of building a solution yourself?
This fundamental question faces developers more and more every day and the answers are not always clear. There are many factors that influence this decision. You have to carefully evaluate the capability of the platform, the strength of the FinTech company, and the ability of the company to deliver. None of these is a “light” consideration and they all need to be carefully weighed and understood. Unfortunately, none of those considerations address the most critical element of ANY technical decision; the accumulation of technical debt.
Technical debt is the idea that as you build software you will find yourself faced with the need to choose something “easy” or something “right”. Unfortunately, the “easy” option often prevails even if the “right” option was better. This results in a codebase littered with “easy” options that need to be fixed later to be “right”. The financial market comparison is apt here because as the name implies, you are investing heavily in debt-backed instruments. They can definitely pay off in the short run, but when they are exposed, they will cause a major impact in your portfolio.
The core principle of this definition is right, and in particular the “financial market” element it implies. However, it does not go far enough in describing the reality of the debt load created in the aftermath of technology decisions. Technical debt is created through ANY decision involving your technology, even down to the personnel. All organizations using technology have some level of technical debt. That “debt load” can be a heavy burden and will only become impactful when the debt has to be paid. The tricky thing about technical debt is that until it is exposed, it can seem to not exist. Be assured that it is always there and has a real impact on this discussion.
Your technical debt is analogous to owning a house (or any fixed asset). You accrue more the longer you hold the asset, and only get to realize the gain when you transfer the asset (sell the house). You can borrow against the value of the asset, and you can use that gain to improve the asset, increasing its value. This works the same with technical debt, the longer you hold it, the more it accrues. Unfortunately, what people don’t often understand is that technical debt only accrues in the loss column.
Let’s see a simple example in action:
Now here’s where everything shifts:
Obviously, this is a gross oversimplification of the housing market, however, it illustrates the point about technical debt. There is no point at which “the market” recovers for technical debt loads. You have technical debt the second you make a decision about your platform and tech stack. That impact simply doesn’t exist outside of technology and it is the biggest factor in the overall build vs buy decision that must be considered. So why don’t we focus on this debt more?
Unfortunately, the foremost question everyone asks when evaluating build versus buy is not “what debts does this create?” Instead, the focus is often on the platform’s near term benefit. Is there a feature set that provides a significant advantage? Understanding the answers to these questions and digging into the features and functions are obviously of great importance. However, they completely miss the critical question of the debt load that comes with this decision.
The better questions to ask about a build versus buy decision are along the lines of the debt that each will incur:
- Can my existing team, with their current skills, work with this platform? If not then I have automatically created additional technical debt which I must now overcome. Generally, the vendor will have the training and support options. (If not, you probably want to steer clear!)
- Do those options allow my team to acquire the missing skills quickly?
- If I suffer turnover, how long do I lose those skills? (ie. how often is the training made available?)
- Is the skill set required to use the platform common or highly specialized? If it is too specialized I may not be able to repay the debt load down the road if something changes.
Does the vendor have enough strength to manage their own technical debt? Do they have a good track record of growth and steady development cycles? Are they aggressive or keep things status quo for their releases? All of this can indicate that the partner you are evaluating has managed to account for their own technical debt load internally.
Consideration for Financial Organizations Making Technical Decisions
For banks making a long term technology bet, the practical decision comes down to this: does the chosen technology platform reduce or increase the technical debt load for the business? Given the long life of software in financial institutions, the total lifecycle cost must be considered. If the long term debt will rise significantly despite the short term allure of a specific technical path, it’s probably not the right choice for the business.
Technical Debt is an Iceberg
Technical debt is like an iceberg in that most of what you have, you cannot see. It is growing across all sectors of technology as the demands for features and functions increase. There are not enough man-hours in the day to create everything from scratch. Increasingly the build versus buy question is being asked as organizations evaluate the need for a feature-rich experience. It is imperative that that line of questioning includes a deeper exploration of the possible technical debt it can create. All technical decisions create some amount of technical debt. The decision has to be to mitigate the debt risk and find the investment that provides the greatest return.