Live data from Hacker News

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

reuters.com

31–40 of 361 posts

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

#31
post #5

The problem really isn't COBOL. COBOL is not a difficult language. It reads almost like English sentences. Any competent programmer would not be challenged by COBOL. The problem is all the glue. JCL, SNA, CICS, ISM, ISPF, etc. It's like the difference between Java (the language) and J2EE, except in the context of 1970s computer technology. It's not intuitive and not something you can really work through without a lot…

At my last employer, there were a few "mainframers" (we called them). I was curious so I would ask my mainframer coworker how things worked on his end. I always struggled to understand, because it seemed everything was different ... the terminology, the culture, the ideas. I couldn't use analogy to tie what he was describing back to what I knew.

You got that right. I had to deal with an interesting banking file format and I asked a question on Stack Overflow and got this gem of an answer.

I politely accepted it as the right answer but boy oh boy does it feel like it's from an alien civilization.

http://stackoverflow.com/questions/28640159/what-is-the-diff...

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

#32
First employee/architect of Kraken here. (Now does >USD$10M+/day of volume by my estimate)

Accounting systems of all kinds should be generic and open source. Why do we need banks at all? It's not like this infrastructure really has any special characteristics. Most of it even has downtime and batch jobs. Fact: The bulk of banking is just recording some numbers at a stupendously simplistic resolution, with maybe 64 characters of description and a date.

A few weeks ago I spent a day interviewing 20 different Hong Kong banks about API availability for cross-border RMB transactions. None at all offered it.

We're reaching a point where the financial systems of a mid-level company exceed those of the banks they are forced to utilize.

Modern requirements include things like: 24x7x365 availability, multilingual, arbitrary asset type support (energy, carbon credits, cryptocurrencies, space, time, etc.), multi-asset type accounts, new settlement networks, real time reporting and AML/KYC, all features API-available, new and established customer interaction through non-snailmail/physical means, customers routinely in different countries, multi-user accounts with disparate access levels (eg. accountant/auditor/spouse/kid), multiple legal jurisdictions with clashing regulatory frameworks, settled-means-settled, regulator-forced free market integration for non-core (ie. account-related) financial services such as loans/forex, redundant service provider availability for every function, meaningful SLAs/reputation for service providers, routing and/or provider selection based upon nontraditional metrics such as ethical investment rationales, etc. The same set of requirements goes up and down the supply-chain: people want to reason with their suppliers and customers about stock, settlement status, payment and contracts, they sometimes need backups in case of failure down the chain, and they care about reputation.

Frankly the whole area is such a mess I am expecting an open source core accounting project to take over the sector. Probably it will begin in smaller/developing world banks and move toward the big guys like a meteor.

For some evolving thoughts on the area (from 2012, but literally picked up again in the last 2 days) see http://www.ifex-project.org/our-proposals/ifex

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

#33
post #27
post #18

Earlier quoted context omitted.

Technically IT is a tool its their to service the business requirements.

That used to be true - up until sometime in the late 1970s/early 80s. Since then, banks are IT. Take that away and what's left?

A banking licence (otherwise known as a licence to print money).

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

#34

First employee/architect of Kraken here. (Now does >USD$10M+/day of volume by my estimate) Accounting systems of all kinds should be generic and open source. Why do we need banks at all? It's not like this infrastructure really has any special characteristics. Most of it even has downtime and batch jobs. Fact: The bulk of banking is just recording some numbers at a stupendously simplistic resolution, with maybe 64 ch…

This sound good, but already exist tons of open source solutions in this space and nothing look good enough.

I wish to build some of this, but how will pay for it?

--- BTW, http://plaintextaccounting.org have some good ideas about this. I think this is the way to go, but how make it work with a database instead

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

#35
post #31

Earlier quoted context omitted.

At my last employer, there were a few "mainframers" (we called them). I was curious so I would ask my mainframer coworker how things worked on his end. I always struggled to understand, because it seemed everything was different ... the terminology, the culture, the ideas. I couldn't use analogy to tie what he was describing back to what I knew.

You got that right. I had to deal with an interesting banking file format and I asked a question on Stack Overflow and got this gem of an answer. I politely accepted it as the right answer but boy oh boy does it feel like it's from an alien civilization. http://stackoverflow.com/questions/28640159/what-is-the-diff...

Wow. That answer took some time and a whole lot of knowledge to write up, so definitely deserved the "accepted" - but if that's just the surface of things I understand why it's like a different world.

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

#36
post #5

The problem really isn't COBOL. COBOL is not a difficult language. It reads almost like English sentences. Any competent programmer would not be challenged by COBOL. The problem is all the glue. JCL, SNA, CICS, ISM, ISPF, etc. It's like the difference between Java (the language) and J2EE, except in the context of 1970s computer technology. It's not intuitive and not something you can really work through without a lot…

At my last employer, there were a few "mainframers" (we called them). I was curious so I would ask my mainframer coworker how things worked on his end. I always struggled to understand, because it seemed everything was different ... the terminology, the culture, the ideas. I couldn't use analogy to tie what he was describing back to what I knew.

Makes sense, as there's little in common for many base concepts.

You deal mostly in stream files, they probably deal mostly in record oriented files..where their "kernel" understands it's record oriented.

Your terminal emulator sends every keystroke the the host. Theirs doesn't send anything until they specifically make it do so.

You have ASCII or utf8, they have EBCDIC.

Some of it is crossing over though. They used to talk about virtual machines before they were common for us. The concept was confusing at the time.

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

#37
I remember running into someone who worked at an insurance company in my home state and mentioned their whole system ran on COBOL. I asked her how she hired programmers and she explained they hired recent college grads with no technical background and trained them from scratch, since it was easier and cheaper than hiring experienced COBOL programmers. Looking back I'm surprised they had the institutional knowledge to maintain systems that way...

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

#38
post #34

First employee/architect of Kraken here. (Now does >USD$10M+/day of volume by my estimate) Accounting systems of all kinds should be generic and open source. Why do we need banks at all? It's not like this infrastructure really has any special characteristics. Most of it even has downtime and batch jobs. Fact: The bulk of banking is just recording some numbers at a stupendously simplistic resolution, with maybe 64 ch…

This sound good, but already exist tons of open source solutions in this space and nothing look good enough. I wish to build some of this, but how will pay for it? --- BTW, http://plaintextaccounting.org have some good ideas about this. I think this is the way to go, but how make it work with a database instead

I am looking at three problems in the area right now from an operations research perspective.

(1) Physical logistics for food machines http://8-food.com/ and their supply chain

(2) Liquidity and settlement logistics for cross-border payments http://moneyclip.cc/

(3) Energy trading for emergent renewables-focused densely interconnected next generation power grids http://fiberhood.nl/

The goal is to get the core markup defined to the point where an engine can be applied to a formally specified risk model to generate various goal-optimized decisions for for all three domains.

Note that there are also many other domains to which this reasoning would apply such as general logistics, supply chain and generic scheduling mechanisms for resource (eg. power)-constrained embedded systems.

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

#39
post #5

The problem really isn't COBOL. COBOL is not a difficult language. It reads almost like English sentences. Any competent programmer would not be challenged by COBOL. The problem is all the glue. JCL, SNA, CICS, ISM, ISPF, etc. It's like the difference between Java (the language) and J2EE, except in the context of 1970s computer technology. It's not intuitive and not something you can really work through without a lot…

Also just half a century of accumulated practice. Before Y2K I used to hear so many stories of people changing or removing things and then finding out that e.g. some manager in a different division depended on a report which needed these two “unused” variables.

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

#40

"Experienced COBOL programmers can earn more than $100 an hour when they get called in to patch up glitches, rewrite coding manuals or make new systems work with old." Any contract-based engineer would charge that, or more, regardless of the language. Fortune 500 companies are happy to pay $300 / hour to a consulting company for engineering time.

They don't give the context. Maybe that's $100/hr w2 for the end contractor after the "Cobol Cowboys" company takes their cut.

Also, it's Dallas, where cost of living is great. 2300 sq ft houses on decent lots in good school districts for $250k.

Post reply on HN