3 ms·
At a certain point you reach a point where continuing to try to move elephants around is going to get you no where. Death is a necessary component of change.
by ExactoKnight 9y ago
At a certain point you reach a point where continuing to try to move elephants around is going to get you no where.
Death is a necessary component of change. In fact, renewal could not come without death.
Existing legacy systems bring with them assumptions about how things ought to work, and debt about expectations -- expectations that slow down your ability to change away from existing paradigms.
True innovation requires this breakaway.
So honestly, IMO the best move for a bank that is facing this kind of software nightmare is to maintain existing legacy support for the old system, but do a complete breakaway (NOT REWRITE) that is explicitly NOT dependent on the old contracts of functionality that the old system would have imposed. Make the rules change, acknowledge the old system will break with the existing system, and plan for a data migration over where ever possible.
Accepting defeat and moving on is a saner path. Migrating the data will become possible once it's realized that ultimately data is easier to change over than behaviour.
I say this too as someone who is very against rewrites generally. It's a fallacy to believe that old systems can accomodate new.
- beat 9y agoLooking back on that giant rewrite project, that's how I'd have done it... I'd have built the new system in parallel with the old one, not sharing the data store. The new system would have significant advantages over the old system (ie near-realtime transactions rather than waiting for overnight batch jobs). Get it running, and encourage early-adopter customers to switch over. That will stress-test it and allow it to scale. After a few years, with lots of warning, retire the old system. That gets away from the "Flip a switch on billions of dollars of transactions a day" terror.