Here at Volt we see a lot of customers who come to us having devoted heartbreaking amounts of time, energy, and money to trying to make old and/or broken systems work, before finally realizing that they need a radical change. 

Below are the top five causes of broken tech stacks we’ve seen through more than a decade of helping companies achieve their real-time decisioning goals.

1. Adding too many layers and components

We live in an era where each layer has many potential choices and even many possible sublayers. A classic naive architecture move is to introduce lots of layers and components, each of which is “best in class”. And yes, while each individual choice is unarguable, when you put them all together you get slowness, complexity, high TCO, and unreliability. The application will be slow because of the amount of time spent moving up and down the multiple layers. It will be complex because of the sheer number of different handoffs and API calls an event has to go through. And it will also be unreliable because each layer will have different failure modes that are collectively very hard to test.

2. Never finishing migrations from legacy systems

We’ve seen several cases where a system has to co-exist with its predecessor, the system it was supposed to replace. This happens when the new system doesn’t do all the stuff the old system does, or there may be commercial and contractual reasons why finishing the migration is not possible. The reality is that the last 5% of the functionality to migrate is usually where all the really weird stuff lives — things like orphaned records, oddball transactions, and data that exists to fix some weird problem somewhere else. The classic anti-pattern is that people go live when they’re 95% done with a nice, new, shiny system, only to find that the 5% they left out prevents them from ever getting rid of the old one. The two systems then have to coexist indefinitely, unless a heroic effort is made to move that last 5%. In practice, the overheads of sharing data between the two systems will dwarf any migration costs over time, but this is frequently something people long-finger in the rush to declare victory and launch a new system.

3. Ignoring lifecycle TCO when making architectural choices

If you make a conscious decision to use a lot of different technologies, you’re also making a decision to have to obtain and retain expertise in each of these technologies for the lifetime of the system. Given how much skilled developers cost, the staffing costs of this approach can be massively higher than all the other costs. It’s all very well for a developer to announce that ‘we can support X internally’, but in the real world that lasts until the developer moves on, or a more important deadline appears. There’s a reason people end up paying for enterprise support. 

4. Failing to accept it’s time for a rewrite (e.g, trying to retrofit real-time decisioning) 

Another classic anti-pattern is sticking with a legacy system for far too long. A good example of this would be trying to retrofit real-time decisioning. While the day-to-day costs aren’t obvious, in the long term you’re going to be in the worst of all worlds — supporting a mixture of old and new, with the benefits of neither. Of course, once you start a rewrite you had better finish it (see #2!). Other issues with running ancient software is that support may be less than stellar, new platform and OS features will be ignored, and going cloud-native might be a dream at best.

5. Using the wrong tool for the wrong job

Last on our ‘top 5’ list is using the wrong technology in the wrong place. This can be hard to deal with, as a ‘favorite’ invariably has advocates inside an organization, and sometimes difficult conversations are needed, especially when an awful lot of time has been invested trying to fit a square peg into a round hole. Organizations have to make a tradeoff between using more different technologies than they can manage, and overuse of a smaller subset. Sometimes we see the worst-case scenario: companies getting sucked into the sunk-cost fallacy and ending up using more technologies than they should for the wrong things.

The Answer? Focus on a Small Handful of Tested Technologies

“Simplify your stack” is, of course, much easier said than done, and it’s very easy to get on the “just simplify your stack” high horse without being the one having to deal with all the tough decisions simplifying your stack typically involves. That said, you’ve probably read this far into this article because you really have experienced one (or more) of the problems above. If you can set a clear goal and clear timeline for fixing the issue, lay out a plan for it, and then focus on a small handful of proven technologies or platforms to go with moving forward, you really can avoid tech stack trouble and may even end up being the “star” of your team – ie, the one who saved your stack by simplifying it without forcing your IT department into chaos. 

Volt specializes in saving companies’ tech stacks and getting them set up for success with real-time decisioning. Get started with us here.