[asien]

> 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.

[simonblack]

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]

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]

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]

> 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.)

[dzdt]

The Oracle outsourcing connection is interesting! I read about this incident at the time in Matt Levine's column. [1] See HN discussion at [2]

[1] https://www.bloomberg.com/opinion/articles/2021-02-17/citi-c... [2]. https://news.ycombinator.com/item?id=26180785

[skissane]

It wasn't exactly classic outsourcing.

In the early 1990s, Citibank decided to outsource banking software development to India. Not an unusual decision, but somewhat unusual the approach to it they chose – they set up an Indian subsidiary (iFlex) to develop banking software for them, but also decided the subsidiary would sell the software as a product to other banks. So Citibank owned an Indian subsidiary which developed banking software both for Citibank and also for others. And then Citibank sold that subsidiary to Oracle in the 2000s, and Oracle renamed it from i-Flex to OFSS. Actually Oracle owns the majority of it but a minority of it is publicly listed on the stock exchange in Mumbai.

It isn't just one product, it is a whole suite of banking software applications. I know there are banks who have deployed just certain apps out of the suite and integrated those apps with their legacy core banking. Or, you can buy it all and use it for everything. Given Citibank is the original customer, I imagine they use more of it rather than less of it, but I’m just guessing.

[lenkite]

> 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]

> 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]

> 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.

[ncr100]

(humor)

> COBOL- still standing the test of time

.. like the plague.

https://en.wikipedia.org/wiki/Bubonic_plague#History