Increase operational efficiency
Technical debt, unlike financial debt, can’t be measured. It’s a bit like carrying an (invisible) weight around – or trying to ride a bike with square wheels. Unfortunately, technical debt is a common challenge investment managers face, which can be a big source of frustration for you if you’re still using legacy technology provided by software vendors that haven’t modernised their tools.
In this post, we’ll explain what technical debt is from a business perspective, why tech debt matters to your business and how you can find out if your vendor has a lot of it or not. With these insights, we’ll help you establish whether your vendor’s technology debt and legacy technology is holding your business development back, what you can do about it, and whether switching to a provider like Limina can help you curb tech debt.
Of course, Limina isn't perfect and we don’t have zero technical debt – you’ll be hard-pressed to find a vendor who does. If you want to explore more aspects where Limina is not perfect, check out our post on the limitations of our offering. Or, if you would like to explore when and why we might be a great fit for your needs, we have a video explaining which business contexts our solution works best in and if we are a worthwhile consideration for your investment management system needs.
We were running one of the established hosted solutions, and certainly had some challenges. The software was very complex since it had grown over a long time, which made it difficult to onboard new team members and some portfolio managers even retreated back to spreadsheets in the end. Change management was another challenge, we had to rely on external consultants to perform upgrade projects and implement new functionality. This resulted high total cost of ownership and slow delivery of enhancements, which in the end impaired our ability to provide the best return for our investors.
- CEO, $6bn Asset Manager, about the state before adopting Limina and why they moved
What is technical debt?
Technology debt is a metaphor to understand choices made in the short term (such as using capital we don’t have) to get something now (like buying a car) and paying the price later (in the form of interest plus principal). In technology, it could be choosing speedy software deliveries in the short term, which usually means slower software development in the future. Another example could be not investing continuously in code rewrites or not taking advantage of modern tools as they become available. This means eventually that all tech eventually needs to be replaced at one go, instead of gradually.
The main difference between technical debt and financial debt is that that former refers to productivity, which we can’t measure. There is a similarity however; both shall be handled with care. We need to understand (and accept) that repayment is eventually due. Hence, we also need to have an idea of what the Return on Investment (ROI) of taking on the debt is.
What would happen if we had no technical debt?
80% of technology spend in the buy-side industry goes to maintenance of existing legacy technology - 80%! That means only 20% of technology budgets are allocated to new solutions and functionality that can unlock business development and lower operational risk for asset managers. Without tech debt, the part of budgets allocated to take us forward into the future would surely be more than 20%! Since we can’t measure productivity, but we can measure dates when software is shipped and the number of bugs it has, this is what is done. What we can measure is what gets managed, i.e. keeping aggressive (or arbitrary) dates and minimising the number of bugs. The price paid? More debt, which year after year slows development down.
As the adage goes, “Software development is a marathon with leadership telling everyone to sprint”. This is true and VERY difficult to avoid, but more often than not, the result is unmanaged legacy technology.
In a world where we had less technical debt to deal with, vendors would be able to provide solutions that:
- Have existing functionality that can be changed easily and quickly
- Allow you to introduce and ship new functionality faster
- Lower your Total Cost of Ownership, because in the end, you need to pay for that 80% of the technology budget that vendors dedicate to “keeping the lights on”
How can you tell if a vendor has legacy systems causing technical debt?
One question you can ask is if the vendor has a microservice or monolithic architecture. In microservice architectures, technical debt is accumulated at a slower pace. You can also check if modern programming languages are used throughout the application or if parts of it run on old programming languages or old technology infrastructure.
Leveraging cloud-native software is also a great way of reducing technical debt, since it (often) more clearly separates areas of concern. Cloud-native means software built for the cloud, not software that was built to run on-premise and has now been moved to the cloud (the latter is "cloud-enabled software"). You can check if your vendor has a cloud-native solution by asking “can the software be deployed, or has it ever been?” – if the answer is “yes” then it’s NOT a cloud-native system.
Technical debt typically piles on with time, at a slow or fast pace, but it’s usually rarely reversed. Hence, a legacy codebase is likely to reach a point at which developers don’t dare to make changes because they are afraid of what they might unknowingly break. A good way to spot if this is the case is to look at the most senior developers – are they making changes to core functionality of the legacy system? If not, then it is probably time to retire the code base.
There is a concept called “clean architecture” which is a way of designing software that, among other things, helps keep tech debt down. One way to spot-check for clean architecture is to ask if you can access the database of the system. If the answer is “yes”, the vendor does NOT follow clean architecture.
Finally, you can also look at the product owners and/or product managers the investment technology vendor employs. If they don’t have a technical background, they are likely to have a lower understanding and appreciation for the problems technical debt will cause over time. Backlog prioritisation will put too low emphasis on non-functional aspects of the code base and the price will be paid, by you, in the future.
The benefits of working with a vendor with less technical debt than most
Limina’s Investment Management System has less technical debt than most vendors, and we hope that this article sheds some light on why this is important for your own processes and functions.
Our Enterprise SaaS solution has helped several investment managers overcome fragmented workflows and increase their confidence in their data and oversight, and we know how to leverage a microservices architecture to reduce the impact you suffer by your vendor's technical debt.
With an on premise system, upgrades take a considerable amount of time and effort, and generally we upgrade annually – meaning we have to wait a long time for software improvements. It also means we have to spend valuable resources on non-core activities such as hosting and IT maintenance. With the current cyber environment and frequency of security patching, on critical systems for us this is a manual, out of hours, process that means Production systems are unavailable. We are strategically moving to SaaS for some critical systems, so that not all our key systems are running on the same environment, so makes BCP/DR more layered – and gives us more options, and less likelihood of all systems outage.
- Head of Technology, $9bn Asset Manager, about the state before adopting Limina and why they moved
To learn more about the benefits of SaaS for your business, download our Ultimate Guide to Enterprise SaaS now.
Summary: Know how to assess the impact of technical debt on change management and launching new funds / strategies
Hopefully by now, you have a better understanding of the impact technical debt has on you as a client to software vendors, being namely slower deliveries and higher costs. You also have a few ways to figure out the level of tech debt a vendor has, and the key questions you can ask to establish if they use legacy technology or not. These will be key in helping you define just how much technical debt you may be getting yourself into when working with a vendor.
Check out our website to learn more about Limina, our people, our solutions and our approach. Or, if you would like to discuss your technical debt concerns in more detail, please don’t hesitate to contact us directly.
