There is one dimension of your actuarial modeling system that’s often viewed as a point of contention. This is the range of options for allowing model changes. Here we’re going to call that the Flexibility vs. Control Spectrum (FVCS).
The basic point is this: either your actuarial system can be totally locked-down (Controlled), or it can be totally open (Flexible). On the Control end, users cannot make any changes to the actual system. Any code changes, any variable additions, any new table structures (for example) need to be made by the system vendor and will apply to all customers of that system. Whenever they get around to it.
How the Flexibility vs. Control Spectrum Affects Actuaries
On the Flexibility end, users have to do almost everything themselves. The software may provide some basic functionality, and perhaps a few samples to get you started, but then you’re on your own. And good luck if you don’t know what you’re doing.
There are merits to each side. Most actuaries will take a pretty strong stance. Vendors will be even more rigid in their perspective.
Those who are all for Flexibility will argue that they just want to be professionals and not hindered by layers of development bureaucracy. If you add too much control, nothing ever gets done. Or, at least, not on the time frame in which it’s useful.
Those who are in camp Control believe in the merits of making sure each component works as it should, always, and that those pesky end-users don’t go mucking about and breaking things. Plus, keeping Control within the system means consistency and continuity.
At Slope, we believe in starting with a base of Control, and giving Flexibility where it makes sense.
However —
This article is not about that spectrum.
It’s not?
This article is about a bigger issue, one that applies across the FVCS. It’s a bigger issue that actuaries must deal with regardless of where their software falls.
The problem with both sides is not one of perspective. It’s a matter of practice, and it’s not a problem to be addressed with more software or hardware.
The bigger issue is you don’t have a comprehensive model governance policy that you enforce.
When you have a Flexible system, you need to have a policy that dictates who is able to make changes, how they’re reviewed, how they’re approved, and how they’re moved into production. When you have a Controlled system, you need to have a policy that dictates how you’re going to add external components (such as spreadsheets or data warehouses) to get the results you need that aren’t provided by the system. And there you should have a policy written out of who’s going to add to these models, how the changes should be structured, how they’re reviewed and approved, and how they’re moved into production.
It’s the same thing for both sides of the FVCS.
And that’s why we say having a good model governance policy and enforcing it is as important as which type of system you choose. (Dare we say more so?)
Not following (or even worse, not having!) your model governance policy leads to what is called “technical debt”. Technical debt is the buildup of functionality that hasn’t been implemented according to your model governance policy. More on that in a minute.
Here’s An Example
Suppose you just wrapped up quarter-end financial reporting. Your manager approaches you and asks, “What would it look like if we made change X to the Alpha block of business?”
You, as a professional, say, “I’m not sure, but I can get that answer to you in a day or so.” At that point, you either a) make a quick model change and run some tests, or b) make a quick spreadsheet, to figure out the answer.
When you reply to the boss, the next thing that comes is, “Great! The management team is going to implement that next month. Let’s continue to report on that each time.”
And suddenly you’re stuck with either a model change that wasn’t tested and approved or another little bit that’s just been bolted on to your system.
As an aside – that last part reminds us of a “Frankenmodel”, where little bits of functionality get added on haphazardly as you need them, without planning or structure.
Now we get to the idea of “technical debt”.
Technical Debt: the aggregation of functionality in a system which has not been processed according to the rules and standards for development.
Wikipedia defines it a little differently. Check it out here. We like ours anyway.
Technical debt shows up when you have professionals, through no fault of their own, just making stuff work. Well, yeah, it works, but at what cost? That cost, to get something functional which hasn’t gone through your standard development process, is technical debt.
You have a difference between what your functionality should be (planned, tested, validated, and approved) and what it is (hacked together).
Like Financial Debt, Technical Debt Compounds Itself Over Time
If you don’t address your technical debt early on, you’ll add more and more “functional” pieces outside of the model governance standard, because you’re trying to pay off technical debt from earlier iterations.
It’s a vicious cycle.
Like borrowing money without fixing cash flows, and then needing to borrow more to pay off those loans, and so on.
So – how can you address technical debt?
Two ways.
Obviously, the first one is, “Never get into technical debt.” Yeah, thanks, genius, why didn’t we think of that?
Even the best of intentions don’t always match up with reality. It happens to the best of us.
We knew about this concept and still ended up with technical debt in our development. Sometimes, it is just unavoidable.
Technical Debt Is A Reality You Can Address Systematically
The other, more practical way, then, is to reduce your technical debt systematically. Like paying off your financial debt a month at a time by reducing expenses and putting those savings towards shrinking the outstanding balance.
We’ve done the same thing. We allocate a portion (between 10% and 20%) of our development time each release cycle to simply eliminating technical debt. That development adds no new functionality and makes no improvements to the system, but it does address the backlog.
It’s a long term investment in the health of our system.
The commitment to make this happen can’t just be one front-line actuary’s opinion that this is important. Like documentation, having good model governance is essential, even if it’s not always that visible to the end-user or non-actuarial audiences. Because it’s so important, also like documentation, the impetus for this kind of thing must be present up and down the line. Top-level actuaries and supervisors need to have a commitment to identifying, prioritizing, and paying down technical debt until it’s gone.
Though it should be obvious, it still needs to be said: the best way to make sure you don’t add any new technical debt, while you’re paying off your old batch, is to follow your model governance procedures for every change you make to your model.
Whatever your position or your system vendor’s position along the FVCS, every model will benefit when all changes are made according to a defined model governance process that doesn’t allow technical debt to grow unchecked.
It’s like that big flesh-eating plant in Little Shop Of Horrors. If you’re not careful, your model just might swallow you up, too!