Live data from Hacker News

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

reuters.com

321–330 of 361 posts

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

#321

Earlier quoted context omitted.

Well, since I have also successfully managed similar such projects for financial institutions & telcos, and I live in startup land, by your last remark I feel moderately qualified to comment. I'll challenge your view that folks in the startup world don't know enterprise. Maybe some visible fraction are the young and inexperienced hipsters as portrayed on HBO, sure, but most of those I know in CTO+ roles actually have…

Furthermore lots of decisions in enterprises look like the following: An executive is approached by a vendor. The vendor entices the executive, shows them a good time, gives them a really good assurance their service is worth it. An engineer hates this service because it sucks. Because the decision was made based on how cool it looks, not by technical needs. Given that, it is hard for an executive to get approached b…

This reflects a failure of modern corporate structures to empower engineering to the role it should and (ought) to be having.

Thankfully, this is changing rapidly and the valley is leading the way.

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

#322
post #284

Earlier quoted context omitted.

Sometimes, 25 years ago, a solution to the problem wasn't available. I worked on state-of-the-art systems from 25 years ago. We were writing homegrown streaming data protocols over raw sockets, parsed with lex and yacc. We didn't have ssh, we didn't have http, we didn't have xml (much less json). A world-class system from 25 years ago would be scrap today... how many bright young junior programmers today could update…

> how many bright young junior programmers today could update a lex/yacc parse stream, or handle socket programming or DOS HIMEM? Almost all of them – if they're really "bright" anyways. Even given that a lot of the important context is missing, bright programmers can do this stuff.

How many programmers could write a functional machine code?

The wrong question is being asked. Modern programming techniques work because they have successfully abstracted this complexity.

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

#323
post #287

Earlier quoted context omitted.

Semi-related: that's why 'blockchain technology' can be so useful to banks. It's not that they need anything blockchain at all, but in practice CEOs are not actually all that powerful against the vested interests of middle management, but having the excuse of hyped up 'blockchain technology' can help with pushing through common-sensical reforms that you would want to do anyway. What's a wheel house?

It's the core of a baseball batter's hitting area. Eg their core strength. Challenge for you since you invoked block chain: Come up with a situation where "the blockchain" wouldn't be a good fit.

Oh, American sports metaphors. They fly right over my head.

A situation where a hyped up 'blockchain' wouldn't be a good fit: when the organization is competent enough and/or the CEO has enough power to change things.

Google probably falls under the former. Amazon might fall under the former and definitely latter.

Let's quote Steve Yege to see why Amazon doesn't need "the blockchain" as an excuse (https://plus.google.com/+RipRowan/posts/eVeouesvaVX):

> So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses.

> His Big Mandate went something along these lines:

> 1) All teams will henceforth expose their data and functionality through service interfaces.

> 2) Teams must communicate with each other through these interfaces.

> 3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

> 4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.

> 5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

> 6) Anyone who doesn't do this will be fired.

> 7) Thank you; have a nice day!

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

#324
post #31

Earlier quoted context omitted.

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

It's not weird if you think of computers that handle data byte by byte Think of building a DB on an C64 and that will probably be more like it But of course if you still have to worry how your data will be serialized to disk in 2017 that's your problem right there

Byte by byte? Where does that come into it? I don't think there's much Production work on a Commodore 64 these days. You don't have to "worry" about anything. I/O is asynchronous, but your High-level Language doesn't know about that, it will appear synchronous. Meanwhile tons of other stuff is going on, and I can't really think of any of it that would be "byte by byte".

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

#325

Earlier quoted context omitted.

I frequently say that IBM sells websphere to assure that they continue to sell mainframes. Because everyone knows if your going to replace your mainframe, you need to rewrite it in java, and what better framework than one provided by IBM! Then when the whole project ends up taking 100x the hardware IBM can pretend there is some secret sauce in those mainframes. But, to the linked answer. While the details differ a bi…

And this is the comment that hit the nail on the head Of course Java is going to be slow when the "Enterprise Architect" and his minions will push for hundreds of classes that barely do one thing right and have several inheritance levels deep while the "mainframe" people are shuffling data using something that's simpler than a csv Also, the virtualization magic is good enough so that the COBOL people keep playing wit…

What "virtualization magic" do you mean?

You mean taking a program which hasn't been recompiled since 1970 and running it (the 1970 executable) on hardware released in 2014 under an OS from 2015? Of course, it will work. There's no virtualization there, just reality. What 70's technology in particular are you thinking of? The latest Enterprise COBOL compiler is just over a year old.

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

#326
post #304

Earlier quoted context omitted.

Correct about the I/O. You can let the space-bar auto-repeat 1919 times, for instance (nearest equivalent to circling the mouse) and the CPU cost is... zero. When, exactly, do you think that the X86 surpassed the Mainframe processors, and in what particular way? Current generation (expect a new one this year) is 5Ghz (actually slower than the previous) and has lots of stuff. A fully-loaded box has a theoretical throu…

"When, exactly, do you think that the X86 surpassed the Mainframe processors, and in what particular way?" Fairly recently. Through things like affordable ssd, enough Moore's law around intel, and better distributed data stores. And better app side knowledge on how to break up a monolith. I was around for a few failed "rewrite this TPF system" attempts and I saw what broke. Commodity stuff can replace it now...but on…

Moore's runs into the laws of physics: https://www.forbes.com/sites/gregsatell/2016/02/24/how-ibm-p...

Mainframe DASD is the same as "X86" disks, at least for those using "storage arrays".

Pretty much all the smaller Mainframes are gone, many years ago. I've not heard of any successful replacement of a loaded system which used fewer than three times the initial projection of "X86-power".

Anyway, time will tell. In 10 years' time you'll still think X86 is faster and there'll still be Mainframes.

As to your last line, who is "they"? I'm just interested. Thanks.

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

#327
post #78
post #31

Earlier quoted context omitted.

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

Although I was never a mainframe programmer per se, I did quite a bit of interfacing between mini/microcomputers and IBM mainframes, so I got to see under the hood a little. (If I write something stupid, it's either memory issues or ignorance). I recall seeing how files were allocated on disk (remember that mainframes have many different OSes, like OS\390, and even OSes on top of OSes like VM/CMS, and I don't remembe…

JCL is not a language. It is no more than "the language, in the sense of words and symbols, that you use to define resources to a Job Step".

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

#328

Earlier quoted context omitted.

Doubtful. I'd bet a lot of the people who can do this work wouldn't be interested in a whiteboard interview. If you're fishing in a small pond for people that can maintain your legacy code, there's going to be a lot less bullshit in the process. Whiteboard interviews have their place, I'm sure. This isn't one of them.

I'm pretty sure with these kinds of systems, if you can repeat about 10 nouns relevant to working within a mainframe environment like this, you're hired.

I've considered it, seriously even. I could go off, contract for large hourlies, probably get paid a lot more than I do now as a more junior exec with a lot less stress (and when I first moved into management, I had the same thoughts). If you have the skills and reputation, this is an area where you write your own ticket. If I were closer to retirement age instead of in my mid-30's, I think I'd be doing it.

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

#329

Earlier quoted context omitted.

I don't think you need to learn an "ancient technology". There is plenty of work in traditional corporations. You just need to find one that has legs so you can ride it out for the next 30 years. A steady job, 5 weeks of vacation after 15 years, benefits. If your lucky you can become a number and slowly disappear, spending more time doing your own thing. Long lunches, nap in the car, run some errands, etc. Eventually…

> Long lunches, nap in the car, run some errands, etc. Eventually everyone runs out of piss and vinegar. It's not so bad. I hate working with people like that, and would hate myself if I did that.

Life is short, how much of it are you willing to give away. That may not resonate with you now but wait until you're in your 40's or 50's and 10-20 years has passed.

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

#330

Earlier quoted context omitted.

You can't wait for customers to "die out" as their mortgages will go on for decades. You definitely need a customer's old data in the new system. Now you have to maintain and develop two systems - bugs, banking regulation require constant work. Often the clock is ticking for old systems and asking vendors to provide and maintain ancient tools can be expensive or impossible. You can't "manually" move customers over, y…

While mortgages do go on for decades (typically), people will frequently re-mortgage based on new interest rates. e.g. in the UK it's typical to sign up for 2-10 year deals, with the interest increasing after these offer periods, meaning people will likely switch to another deal. So there will be a certain amount or organic churn.

Not enough churn, though. I worked on mortgages for a UK high street bank a while ago, and they were still running the mortgage systems for every bank and building society they'd taken over in their decades of growth, plus a few different attempts at building one system to rule them all.
Post reply on HN