Here is a morbid hypothetical: You have been given five years to live, and you have no spouse or next of kin. You have $10 million USD in assets. In your precious time left, you plan to fulfill your dream of living on the Jersey Shore, and you have already located beautiful beachfront property valued at $9 million. You have a choice of paying cash or taking a 30-year mortgage at 10% APR with $1 million down. An APR of 10% seems high, but you’re not exactly thinking more than five years out. You could find a lot of fun uses for $9 million while you count down your days. How are you purchasing? More on that later.
For now, let’s focus on the present. Assume instead you are “married” to a bloated, fashion-challenged policy admin system named Cliff that outlived his original life expectancy by 20 years and counting. His vitals are strong, but he requires constant support. His largesse and resistance to change limit his speed and your variety of activities together, but he is the “devil” you know. Do you consciously uncouple with Cliff and start courting a young, fitter replacement named Blayze? Or do you make it work with your partner of decades — piling on workaround after workaround for his copious limitations? Herein lies the essential question of technical debt.
Gartner defines technical debt as “work that is ‘owed’ to an IT system when teams ’borrow’ against long-term quality by making short-term sacrifices, taking shortcuts, or using workarounds to meet delivery deadlines.”1 The words in the definition — owed, short-term, shortcut, against quality — give technical debt a bad name. They also imply deadlines, perhaps even arbitrary ones, get in the way of high-quality, long-term sustainable decision making. But if you take out the pejoratives, you are left with a perfectly economically rational way of doing business: debt financing.
Promises versus track record
Let’s take a closer look at Cliff. Given how long Cliff has existed, he likely:
- Resides on premises rather than in the cloud.
- Leverages less secure, older technology and requires frequent manual patching.
- Requires support by legacy skill sets that today’s STEM grads may not have.
- Executes tasks on the slower side.
- Contains vast hard-coded exception handling (e.g., for certain endorsement scenarios).
- Has limited native ability to log on and off via application programming interfaces (API).
- Stores most of the information in column-based architecture.
Surely Blayze is better than this! Blayze is cloud native, multifactor, fully API-exposed, format flexible and massively parallel — everything Cliff is not. Actuaries can instantly and securely extract analysis data from Blayze, deploy new rating plans at the push of a Blayze’s button, and wade into the brave new world of nonstructured data (oh how much insight must live in those images and user notes!). Blayze promises that if we court him for five years and whisper all of our exception cases in his ear over that time, then we can have all these benefits and more.
Could Cliff ever offer us all of these things? Maybe! For example, what if we:
- Create a lightweight cloud-based user experience (UX) that “sits on top” of Cliff.
- Build a giant moat around Cliff that no one besides the UX can cross …
- … and a drawbridge (gateway/port) only you and enterprise security can cross …
- … and a gondola (API) as an alternative to the drawbridge.
- Cache data for frequent tasks in the cloud layer so that they run faster.
- Sunset exceptions that no longer make sense.
- Organize images and notes into columns using hashing rather than chucking them.
- Have STEM grads code in Python and use ChatGPT to translate it back to Fortran.
In other words, what if we trick out Cliff to make him look more like Blayze? Cliff promises that if we buy him all the accessories he wants, he can give us all the same happiness that Blayze offers in just six months, and he actually has a solid track record of delivery on such promises. Is that any less reasonable than all the time and money Blayze demands to extricate from Cliff? Even if Cliff fails on one or two fronts, his history shows he will probably deliver on the rest. Meanwhile, Blayze could be just as needy as Cliff, for all we know — once the honeymoon is over.
Now versus later
If it were a sure thing Blayze would deliver, most actuaries could probably build a solid case that Blayze would pay for itself over a useful life of, say, 20 years. Investing more in the relationship with Cliff adds more “kids” (technology components) into the settlement when it inevitably gets ugly. However, three aspects of the business case should receive careful attention:
- What is the opportunity cost of what we lose during the five-year Blayze courtship? Investing in Blayze is time and effort that presumably could not also be spent upskilling Cliff. Organizations may view accessorizing Cliff at the same time as duplicate expense and/or as counterproductive to the transformation (e.g., a distraction or mixed messaging). Therefore, Cliff versus Blayze is an “either-or” that is very likely to occur in practice.
- What are the timing and certainty of Blayze’s value adds? Blayze promises cool things, but it may take longer than we expect to get to the altar. Also, happiness may not feel like we think it will. Blayze may bloat up, i.e., start to take on workarounds and shortcuts during the courtship. For example, what if we learn midway into the overhaul that Blayze’s capabilities are insufficient to natively handle exception handling programmed into Cliff? We may, ironically, need then to invest in making Blayze more like Cliff after we commit.
Blayze may also start to demand more and more over time. For example, Blayze told us he was cloud-native, but did he tell us that this would incur us cloud computing costs beyond just the costs of our matrimony to him? Cliff’s cost model is pretty well understood, but all we know about Blayze at the moment is he seems capable and has expensive taste.
- Will Blayze’s adds still be valuable five years from now? This may be the biggest question. Blayze takes five years of courtship to solve many of today’s problems, but we don’t know for sure if these will be the problems of tomorrow.
On the last front, consider if the goal of our project is to optimize our systems to interact with ChatGPT 4o API and Azure Document Intelligence (ADI) — creating dialog capabilities within the policy admin upstream and enhanced analysis capabilities downstream (e.g., structuring notes and images). Given the current rate of evolution of artificial intelligence (AI), input/output and interaction modes may be completely different five years from now than today, and it may make more sense to wait until closer to the technology asymptote to start courting replacements for Cliff than to anchor to a transitive technology state. On the other hand, optimizing for ChatGPT 4o and ADI may well optimize for future generations (is backwards compatibility still a thing in the AI renaissance?). In other words, OpenAI may not suddenly shut off 4o when it gets obsolesced by Deep Research — so there may be no need to pause. In that case the question reverts to whether AI initiatives are best served by “shortcutting” Cliff or trading up.
The answer could go either way. One overlooked and paradoxical aspect of AI is that it makes it easier to service technical debt but also to accrue it.2 Having AI that can code as well as an experienced developer allows us to seamlessly heap accessories on Cliff and have recent grads translate modern (programming) languages such as Python back to dead languages such as FORTRAN so we can have the tough conversations with Cliff. Committing to Cliff increases debt, but AI helps reduce our interest rate by mitigating or eliminating the effects of his limitations. Switching to Blayze helps eliminate debt from the picture, but re-platforming a core system is a Herculean endeavor that may be harder for AI to solve than accessorizing a current one.
Jumping off the Cliff
The key theme of the prior section is uncertainty. Blayze may protect us from a future that is very difficult to envision (especially at the pace of technological and societal change). Cliff is our best tool to get work done now. Actuaries should consider granting themselves permission to take “shortcuts” and think “short-term” with Cliff. This is debt financing. Short-term and long-term are not always mutually exclusive. We can squeeze more mileage out of Cliff while we flirt with Blayze, and this often happens in practice. But if we bet on Blayze without paying attention to Cliff, and Blayze doesn’t pan out, we pay both the opportunity cost of what we could have gotten done with Cliff as well the technical debt of having spent five more years with him as he ages further.
Speaking of aging, let’s revisit that Jersey Shore property from earlier. Given the two scenarios illustrated in the intro, I’m personally taking the 30-year mortgage and betting that, unlike Cliff, I don’t outlive my life expectancy that significantly. I may wish I’d pursued less predatory financing options (and Blayze) should I receive a new medical prognosis, but it is difficult to know what the state of modern medicine will be in five years. I can always try to unload my Jersey Shore property in that case. In the meantime, I don’t want to miss my opportunity to live the sweet life as a result of excessively thinking long term. Actuaries, of all people, are very well-positioned to help their organizations understand the time value of money.
Jim Weiss, FCAS, CSPA, is a vice president for Crum & Forster and is editor in chief for Actuarial Review.
- https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/technical-debt
- https://www.mckinsey.com/capabilities/quantumblack/our-insights/ai-for-it-modernization-faster-cheaper-and-better
