Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Banks scramble to fix old systems as IT 'cowboys' ride into sunset

reuters.com

Post reply on HN
Print view View original

271–280 of 361 posts

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#271

Post by ska »

beat wrote: post #231

I worked for years on the modernization of a critical banking infrastructure system. The problems are manifold. The biggest problem is overall architectural impedance mismatch - switching from a batch system (most of those old COBOL mainframe apps are batch systems) to a service-oriented architecture. This makes incremental replacement extremely difficult. But a cutover? On a system that moves more money in a day tha…

   I take it to mean they've never actually worked on a truly hard problem in their lives.
I certainly have some empathy for this view. On the other hand, the right time to have addressed actually fixing some of these problems is 25 years ago. The second best time is today (to steal/abuse a phrase). Enterprise organizations sometimes punt these things down the road with half-assed solutions. It's cheaper today and tomorrow maybe it will be someone else's problem, right? All the while the overall issue becomes worse.

It sucks sometimes to be at the bottom of a deep hole you dug yourself into without a ladder, but at the end of the day, it's your hole.

And you are right that sometimes it's just a hard problem. But you can always make those worse.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#272

Post by diegoprzl »

user5994461 wrote: post #167
tajen wrote: post #115

Earlier quoted context omitted.

French banks are actually doing that! SG/Société Générale, a brick and mortar bank that costs a hundred dollars a year, built Boursorama, an e-bank that's free and that gives you $200 if you subscribe. Advantage: SG has too many manned agencies and can't justify preemptively mass-firing them yet – they first need the customer base to dwindle. Better IT, usage of Internet techniques at the core, and drastically simpli…

Boursorama is not a bank. It's a website to allow people to play on the financial markets ("bourse" = exchange). I think Americans would call that a sort of dealing account. Obviously, a dealing account has to hold funds and handle transfers. That's not any close to a consumer bank though.

Boursorama also owns an Spanish "digital bank" called Self Bank. I have an account there.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#273

Post by pc86 »

ethbro wrote: post #263
binarymax wrote: post #213

Earlier quoted context omitted.

Emulate the mainframe and make a modern abstraction interface over the platform. We investigated this option for some IBM 360 COBOL code for a project I was running. We were a very small team and were market consumers (not implementers) of the original system which got open sourced in a panic. We eventually chose not too - but seriously considered it. If I were the owners (the Fed) I would have.

One of the problems with attempting to write interface is the opaque source/consumer problem. E.g. I'm working on a system that I could hypothetically abstract (I've got access to it, can poke with enough tests and test data, etc). However. What I don't have is access to code or test injection into any of my sources / consumers. Both of which are expecting all the corner case quirks to be exactly identical and may ac…

> we don't have any logging of an example that came through production.

If it's something that's never come through production, it is not already documented anywhere, and it has an occurrence rate of approximately 0.001%, is it really a feature that needs to be replicated?

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#274

Post by grogenaut »

eru wrote: post #186
flukus wrote: post #116

Earlier quoted context omitted.

This is accountant math with capex vs opex. I don't know how but they manage to convince companies that their saving money by spending 10 times as much.

Might still be a good decision: the corporate politics get so much harder, once you have in-house teams. And: that company would probably fail at writing in-house software---most of them do.

Good point. I didn't think about the leverage of having an internal team holding you hostage vs and external.

And yes there is also the, how do you hire up a good dev team when you obviously don't know how to do software yourself. Eg hiring outside your competency. I know this is especially hard, and I've watched large companies who are good at hiring in general fail at it specifically in a wheel house. I think this is why aqui-hires can help.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#275

Post by beat »

humbleMouse wrote: post #261
beat wrote: post #242

Earlier quoted context omitted.

I'm still waiting for the white people from the north to throw a fit because I said this. It's not always well received...

I'm white and from minneapolis and I think your analysis is spot on.

Yeah, I'm in Minneapolis too. When things blew up with the cops and BLM, the rest of the country was shocked that it could happen in nice, tolerant, liberal Minneapolis. Not me. :(

North Minneapolis is as segregated as anything the South can offer.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#276

Post by tenken »

pc86 wrote: post #273
ethbro wrote: post #263

Earlier quoted context omitted.

One of the problems with attempting to write interface is the opaque source/consumer problem. E.g. I'm working on a system that I could hypothetically abstract (I've got access to it, can poke with enough tests and test data, etc). However. What I don't have is access to code or test injection into any of my sources / consumers. Both of which are expecting all the corner case quirks to be exactly identical and may ac…

> we don't have any logging of an example that came through production. If it's something that's never come through production, it is not already documented anywhere, and it has an occurrence rate of approximately 0.001%, is it really a feature that needs to be replicated?

Sure, because clients will say anything short of 100% success is failure.

(Currently migrating a site of 125k pages of content with oodles of edge-cases)

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#277

Post by beat »

wolfgke wrote: post #248
beat wrote: post #231

I worked for years on the modernization of a critical banking infrastructure system. The problems are manifold. The biggest problem is overall architectural impedance mismatch - switching from a batch system (most of those old COBOL mainframe apps are batch systems) to a service-oriented architecture. This makes incremental replacement extremely difficult. But a cutover? On a system that moves more money in a day tha…

> When I see people in the startup world rolling their eyes at the "incompetence" of the enterprise world, I take it to mean they've never actually worked on a truly hard problem in their lives. I worked in a related field in the past. I don't claim that the problems are easy - where I tend to roll eyes rather is: - Bureaucracy: A lot is required by law, I know. But there is a difference between "just following the r…

I'm starting to blog about some of the issues around these things. One I want to write about - especially because it triggers controversy when I say it - is the idea that it's more important to not be wrong than it is to be right. So no matter how obviously right a move is, fear that it just might be wrong hampers decisions.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#278

Post by WalterBright »

chii wrote: post #141
WalterBright wrote: post #112

Earlier quoted context omitted.

I've converted such programs from one language to another. It is not necessary to understand how the program works, only how the language works. What you do is function by function, convert the language by duplicating what it does in the new language. Resist any and all urges to fix it, refactor it, improve it, etc. Just translate.

The problem is if there's some obscure language behaviour that's not documented well, and the code relied on that behaviour. unless you're an expert and knows the language inside out, it's hard to even know such a problem occurred.

True, but languages tend to be far, far better understood and documented than some random application logic.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#279

Post by Clubber »

wolfgke wrote: post #248
beat wrote: post #231

I worked for years on the modernization of a critical banking infrastructure system. The problems are manifold. The biggest problem is overall architectural impedance mismatch - switching from a batch system (most of those old COBOL mainframe apps are batch systems) to a service-oriented architecture. This makes incremental replacement extremely difficult. But a cutover? On a system that moves more money in a day tha…

> When I see people in the startup world rolling their eyes at the "incompetence" of the enterprise world, I take it to mean they've never actually worked on a truly hard problem in their lives. I worked in a related field in the past. I don't claim that the problems are easy - where I tend to roll eyes rather is: - Bureaucracy: A lot is required by law, I know. But there is a difference between "just following the r…

Don't forget rampant offshoring in the early aughts.

Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset

#280

Post by defined »

osullivj wrote: post #127
defined wrote: post #81

Earlier quoted context omitted.

Please don't remind me. I had to convert the expat XML parser to compile on z/OS and work in EBCDIC, and found that round tripping between ASCII and EBCDIC was sometimes impossible because of the existence of not two, but THREE line terminator characters: CR, LF, and NL (0x85). Not to mention that you cannot test for uppercase or lowercase like the ASCII `ch >= 'A' && ch <= 'Z'` because they are not contiguous in EBC…

I did the same to enable XML messages to flow over MQ between an RS/6000 based front office FX options system, and a back office S/390 system. IIRC there were six (!!) different EBCDIC codepages that could be in play. I had a code generator that would crank out C or Java bindings that could martial between the expat results and the COBOL data structure. 20 years ago now!

Oh yeah, I remember the code pages. Joy. I didn't want to bloat my comment, so thanks for mentioning this!
Post reply on HN