top | item 28542646

(no title)

asien | 4 years ago

> Cobol remains the language of choice

Sigh , those single liner that both illustrate the ignorance and the status of the author.

I’m an enterprise architect in banking , 6 month ago I was hired for IT Transformation.

My mission was very simple « move the bank the out of mainframe »

In 2 weeks or so I presented a Kafka based runtime based with JVM contracts that would enable the bank to perform in a near real-time manner as opposed to « batch » processing while covering and simplifying 90% of banks related scenario ( SEPA , MasterCard , AML etc...)

The project was accepted by directors but devs refused to go into that because much like the authors they are 30 years in the banks and don’t want to learn something else than what they know « cobol ».

90% of our contractors work is spent dealing with mainframe constraint and writing interfaces and top of that piece of crap that can only process data at night or during the weekend.

Mainframe is not there because « it’s superior » , distributed system have largely proven their capability and maturity.

Mainframe are still there because of Corporates Politics and lack of Leadership from top management.

When you are reminded that Citibank lost 0.5 Billions because they spent 0$ on their UI, you may start to understand how much corporates world is rotten to its core and why mainframe is still there.

Has nothing to do with it’s capability , period.

discuss

order

simonblack|4 years ago

devs refused to go into that because much like the authors they are 30 years in the banks and don’t want to learn something else

The way to fix that is to use the method IBM used to introduce the IBM-PC back in 1981. They set up a completely independent project group that had no connection with the main-frame boys, and so weren't 'brainwashed' into the IBM 'way of life'. The rest is history.

Incidentally, while I no longer program in COBOL, I still like it. It was always easy to do maintenance on a program that I might not have looked at for decades because of its wordiness. I normally program in C these days, but it's not as 'maintenance-friendly' as COBOL unless there are lots of comments.

phoehne|4 years ago

The thing is, you solved a very narrow problem to which there is already a solution (and has been) on the mainframe for 30+ years (MQ). The real problem is that in that COBOL code is 50 years of business rules smeared across millions of lines of code, adjusted for all the changes in law (sometimes applied retroactively) which impact how money is handled. It isn't that mainframes don't have message queues or can't interoperate with web services (they can), even if not all customers take advantage of those features. The problem is replacing that code requires extracting all that knowledge out of the code. Then, on top of that, if there's any downtime, it can be existential risk for the bank.

briHass|4 years ago

Yep. It's real easy as an architect to come in and propose an overall architecture that will work, but the rubber meets the road when you attempt to 'strangle pattern' your way out only to find the deep interconnected and undocumented business logic. You're also fighting the business by trying to wrangle SMEs that have no interest in helping or have long since moved on.

skissane|4 years ago

> When you are reminded that Citibank lost 0.5 Billions because they spent 0$ on their UI, you may start to understand how much corporates world is rotten to its core and why mainframe is still there.

That wasn’t actually on a mainframe or in COBOL, it was an Oracle app (Oracle Forms/Reports, PL/SQL, Java, etc). And, it was a product from an Oracle subsidiary (OFSS), the software itself was not maintained in-house. Although, to complicate the story, that subsidiary was started by Citibank and then sold to Oracle in the mid-2000s.

So Citibank no longer directly controls the decision on whether the UI is updated, now that is up to Oracle. They can encourage Oracle to do that, and decide how quickly to upgrade if/when Oracle delivers it, but Oracle controls the actual UI. Or they could decide to look for a new product to replace it with.

(Disclaimer: former Oracle employee, was peripherally involved with OFSS banking products during my time at Oracle, although I never had anything to do with Citibank, and I never saw this specific banking product either.)

lenkite|4 years ago

> and writing interfaces and top of that piece of crap that can only process data at night or during the weekend.

I worked on mainframes and this seems like some deliberate policy not a mainframe limitation.

Also your Kafka+Java architecture is unlikely to still be supportable in 2 decades. Will have the same problems with Java and Kafka in the future as you have with Cobol today.

lmm|4 years ago

> Also your Kafka+Java architecture is unlikely to still be supportable in 2 decades. Will have the same problems with Java and Kafka in the future as you have with Cobol today.

I doubt that. Java has shown a huge commitment to backward compatibility; you can take code from 20 years ago and run it unmodified today. Kafka is younger but it's also a project that takes compatibility seriously.

charadeyouare|4 years ago

> When you are reminded that Citibank lost 0.5 Billions because they spent 0$ on their UI, you may start to understand how much corporates world is rotten to its core and why mainframe is still there.

Mainframe is still there because crypto isn't yet.