|
|
|
|
|
|
by gutnor
5055 days ago
|
|
|
You forgot * It is near impossible to measure the savings of doing a conversion. * Anyway, a huge chunk of the subtle behaviors of the current system is unknown, or when known, the business reason is lost in history. That makes it near impossible to properly estimate the cost a conversion would be. * All the system in legacy tech are core product - they affect literally everyone in the company - thousands of people in the company. Over 40 that still like new tech have rock solid incentive not to push for them. |
|
|
I've thought long and hard before about how to supplant a current legacy system that's taken root like an old oak tree in a financial services company. I honestly don't know how.
For example, a Life Insurance Administration System in a small insurance company. First, let's make some broad assumptions to make things easier:
1. The system will be "go-forward" only. i.e. we will not convert current policies onto the new system. 2. The system will NOT support any current product lines, but at launch will only support new product X, which is still in the product planning stages.
Given those 2 assumptions, how much customization will the new system require? The answer that everyone hopes for when they buy the software from the vendor (and the story the vendor sells) is, very little. The reality is that the system that goes live is usually very, very customized OR it ends up being very under utilized and simply interfaces WITH THE LEGACY SYSTEMS to meet the requirements of the product team, the regulatory bodies, the actuaries, etc. etc.
So what's a legacy system hating hacker to do?
The only way I could see legacy replacement being feasible is if big corp X decided that they were going to do full in house system development, and then market the core or the resulting system to their competitors. This isn't unheard of, and has been done in the past, but is pretty rare. The trend over the last 20+ years has been to out source virtually all of IT and buy off-the-shelf, vendor supported software to administer daily business. The argument, that big corp X is not in the business of software development is difficult to argue against. Alas, the end result is vendor lock-in, increasingly expensive services contract, and stagnant systems that are impossible to pry your business loose from.
The in-house/out-source cycle is fairly common in big financial services/health care corporations, usually on about a 4-8 year schedule.
I suspect the HN audience is not particularly interested in legacy systems development, or how one's insurance policy is administered. But, the next time you notice how large your insurance premium payment is, or complain about bank fees, or drug dispensary fees, etc. etc., stop and think for a second about what that money is paying for. In the case of insurance (which is the industry I'm familiar with), I'd argue that for a low-risk client, that a large percentage of your premium goes to administration of some sort.