I’m going to have a guess and suggest that the website is probably integrated with some much older mainframe system and a batch process or several batch processes run daily overnight to shuttle data between the two systems to keep them updated and in sync.
Syncing the two sets of data while the database is live and changing is a pain the the bum, so they freeze it while the data transfers are taking place.
This is the real answer. Main frame batch processing.
And till you haven’t experienced it, it seems like an excuse. Why can’t you simply do it all the time. Why can’t you get rid of the mainframe, etc.
But if only it were that easy. There is a reason IBM can still acquire multi billion dollar companies and then run them into the ground.
My company has maybe a couple million customers and can’t get rid of its mainframe and in areas that it’s gotten the process away from the mainframe, batch patronizing is still a thing. Because that is the only way to guarantee integrity.
So yea. I wish your comment gets more up votes. Because it is not a conspiracy, it is a technical limitation.
I had to do some legacy app modernization for one of the largest telecoms companies in the US, and their mainframe system and the UI, while ugly, performed so much faster than the modern approach.
Given, we weren’t the most talented team out there, but rendering the UI on the server side was unmatched in performance versus what we could get out of a web browser. I was the UI guy so I didn’t really touch mainframe side, but it was wild to me that they made this system like 30 years ago and it worked so much better than our modern implementation
Its the conspiracy of capitalism. If nothing else this is another example of how megacorps have more say in government operations that the entire population.
It can be, but it’s also an issue of “move fast and break things” doesn’t work in all environments.
You don’t want your bank to have an oops with your checking account, or your medical records to get messed up because someone didn’t code it well enough. If it works and is stable, there needs to be a demonstrable benefit and a guarantee that it will keep working when moving to a newer system. Usually on a budget of “what do you mean you need a budget, just do it”.
This also explains, very basically, why financial systems are the way they are. The backend is ancient but they know how it works so it stays the same and we see it’s weird quirks all the time.
Oh it’s hugely risky. I don’t blame anyone for not wanting to change it. But most people don’t know it’s all held together with duck tape and bubblegum.
I’m going to have a guess and suggest that the website is probably integrated with some much older mainframe system and a batch process or several batch processes run daily overnight to shuttle data between the two systems to keep them updated and in sync.
Syncing the two sets of data while the database is live and changing is a pain the the bum, so they freeze it while the data transfers are taking place.
This is the real answer. Main frame batch processing.
And till you haven’t experienced it, it seems like an excuse. Why can’t you simply do it all the time. Why can’t you get rid of the mainframe, etc.
But if only it were that easy. There is a reason IBM can still acquire multi billion dollar companies and then run them into the ground.
My company has maybe a couple million customers and can’t get rid of its mainframe and in areas that it’s gotten the process away from the mainframe, batch patronizing is still a thing. Because that is the only way to guarantee integrity.
So yea. I wish your comment gets more up votes. Because it is not a conspiracy, it is a technical limitation.
I like working with legacy systems. Post something, go fart around on your phone for fifteen minutes while you wait for it to post.
I had to do some legacy app modernization for one of the largest telecoms companies in the US, and their mainframe system and the UI, while ugly, performed so much faster than the modern approach.
Given, we weren’t the most talented team out there, but rendering the UI on the server side was unmatched in performance versus what we could get out of a web browser. I was the UI guy so I didn’t really touch mainframe side, but it was wild to me that they made this system like 30 years ago and it worked so much better than our modern implementation
I’m not sure whether I want to work with your team or not, considering all fifteen of those minutes farting I get to bill to the client
Its the conspiracy of capitalism. If nothing else this is another example of how megacorps have more say in government operations that the entire population.
It can be, but it’s also an issue of “move fast and break things” doesn’t work in all environments.
You don’t want your bank to have an oops with your checking account, or your medical records to get messed up because someone didn’t code it well enough. If it works and is stable, there needs to be a demonstrable benefit and a guarantee that it will keep working when moving to a newer system. Usually on a budget of “what do you mean you need a budget, just do it”.
This also explains, very basically, why financial systems are the way they are. The backend is ancient but they know how it works so it stays the same and we see it’s weird quirks all the time.
More like, they know of they try to change, and their is an issue and people’s statements payments are at risk, it’s their ass.
Oh it’s hugely risky. I don’t blame anyone for not wanting to change it. But most people don’t know it’s all held together with duck tape and bubblegum.