4 ms·

One might be persuaded to believe that IT is actually something that provides a monetarily significant benefit to an organization... but we know that can't be t

One might be persuaded to believe that IT is actually something that provides a monetarily significant benefit to an organization... but we know that can't be true. Just because every iota of every business flows through computers and even minor software projects can multiply the productivity of employees by an order of magnitude, that doesn't mean management should be expected to value IT in such a way that they actually are willing to pay significant amounts for it!

lukasm 12y ago
I worked for a while for Morgan Stanley and have 20 friends that work in finance. They pay a lot for IT. Good hacker can make 300k, but the main problem that big banks have is complexity. Years of M&A, 20 systems that do the same. Simply paying more is not a solution.
- VonGuard 12y ago
  Yup. You like supporting COBOL? FORTRAN? How about some PL/1 running on AIX or something equally as byzantine... M&A can ruin your will to live.
  - opendais 12y ago
    Bah, at least PL/1 is still maintained by IBM. Come back when the language you are running on that AIX system is completely dead since before 1990 and there is no online documentation for it. ;)
    - VonGuard 12y ago
      ALGOL
      - opendais 12y ago
        Fair enough :)
    - deleted 12y ago
      [deleted]
  - valarauca1 12y ago
    Your modern z/OS mainframes are just unix. The problem is the average IBMer will not know how to secure your zOS server. If you ask them how to configure, or how to manage files they'll tell you their aren't any. This is simply amazing double speak because they are, and are not correct. When you first log into this systems you see the old zOS stuff, which looks and feels like MTS system360-67M/70 (its a long story). All your files are data sets, which aren't files, see MTS didn't have files, it had data sets. But it isn't. Its just a mainframe layer running on AIX. Its called something dumb like encom, unicom, in MTS . That brings you into proper unix mode. Which you may think is running inside MTS, but it isn't. MTS is running inside AIX. Because keeping MTS up to date with modern hardware would be impossible. So we just trick it into thinking its processor is running at the Plank frequency. Not 200 PowerPC chips or what ever IBM shoves in these things today. Then your in a standard unix environment. If you attack these things from the outside (and get in), you'll see and feel what looks like a BSD/SysV (ish) system. Because that's what it is. Its a unix system. But nobody configures this crap because the mainframe dudes can just say, "Oh no there are no files on a mainframe, just data sets, they're different." But if I steal a data set in unix mode, its a file. So no, your wrong. Nobody really goes into Unix mode half the time. They just care about keeping the system360 stuff working. Nobody cares about security because "Its a mainframe, they don't have security issues." Well they do, just like every other unix box on the planet. But unlike every other unix box we pretend they don't need security.
    - marktangotango 12y ago
      I don' quiet buy your assertion that z/os is an emulation layer over AIX. When I used to while away the days poking around on a z/os machine, it was not that cut and dry. I couldn't just access a dataset from the shell, and the mainframe permissions model was pretty effective at locking down what I could get too. Do you have any references to back that ie an IBM red book?
      - hvs 12y ago
        I think he is saying that a lot of these companies have a mainframe emulator running z/OS on unix rather than a true mainframe. I'm not sure if that's true or not, but I believe that's why he is saying you can attack from the unix side. z/OS itself is most certainly not an emulation layer over AIX. It's a complex operating system with 50 years of history behind it.
  - cdr 12y ago
    I used to know someone making a pretty good living doing COBOL for banks. Some people really do enjoy that sort of thing. Also a bonus of less (or even positive) age discrimination, since he was an older guy.
  - _delirium 12y ago
    Could be personal preference, but that actually sounds more fun than a lot of things in tech. Software archaeology on ancient and possibly broken systems? Probably has lots of annoying parts, but also sounds pretty interesting. Is it really less annoying to do "modern" work, like learning the Nth new Javascript framework, dealing with piles of Chef scripts, extending Enterprise C++ codebases, spending weeks testing browser compatibility, etc.?
    - blincoln 12y ago
      My experience is that it's a lot less fun in practice than it is in theory. Uncommented spaghetti COBOL code is about as hard to reverse-engineer as an x86 disassembler dump done without debug symbols, IMO.
- Retric 12y ago
  Failing to migrate after a M&A is failure to invest in IT. It's a stupid, short sited, and expensive failure, but good luck finding banks willing to pay for it.
  - GVIrish 12y ago
    Banks will only become willing to pay after experiencing expensive, massive disasters like what JPMorgan is experiencing. Maybe. Migrating and/or killing large legacy enterprise applications is monstrously expensive, so the decision makers often decide against it. Relatively speaking, there haven't been enough very large companies that have been burned by that sort of decision, so executives at these companies (and the government) are less likely to see how badly it can go. Then there's the very real challenge of justifying a big IT spend on retiring legacy applications to the shareholders. And the high chances of large enterprise IT projects going wildly over budget. As much as we like to point the finger at the c-suite guys who keep doubling down on technical debt until there's a disaster, it's not an easy to make the case for paying to fix the problem. At least not until there are plenty of negative case studies out there like this one.
at-fates-hands 12y ago
>>> that doesn't mean management should be expected to value IT in such a way that they actually are willing to pay significant amounts for it! I was at one large financial company similar to JPMo and every time the development team came up with a good idea, it was met with a laundry list of requirements we had to meet in order to show positive ROI over a very short time period. Not sure if they did to discourage us from trying to help processes and development, or they really believed redesigning some parts of their network architecture could be done in a month or two. Either way, it was quite frustrating to say the least, and after a few gallant attempts to get something going, most of the younger developers just opted out and left. I saw the writing on the wall and was in the second wave of people who finally gave up and moved on.
wheaties 12y ago
JP pays programmers very well. In fact, it's very good for the counties in which those programmers are employed. Well, that is, if they were in a money center. Costs centers, like security and infrastructure, those places they minimize the costs! Part of minimizing costs is all about not paying for things that aren't expressly needed or killing programs that might make sense but cost too much. I worked there for half a year before quitting and going back to a start up. Nice people but only the people at the top seem to have a clue as to what to fix and they, themselves, can only focus on so many things at once.

lukasm 12y ago

I worked for a while for Morgan Stanley and have 20 friends that work in finance. They pay a lot for IT. Good hacker can make 300k, but the main problem that big banks have is complexity. Years of M&A, 20 systems that do the same. Simply paying more is not a solution.

VonGuard 12y ago
Yup. You like supporting COBOL? FORTRAN? How about some PL/1 running on AIX or something equally as byzantine... M&A can ruin your will to live.
- opendais 12y ago
  Bah, at least PL/1 is still maintained by IBM. Come back when the language you are running on that AIX system is completely dead since before 1990 and there is no online documentation for it. ;)
  - VonGuard 12y ago
    ALGOL
    - opendais 12y ago
      Fair enough :)
  - deleted 12y ago
    [deleted]
- valarauca1 12y ago
  Your modern z/OS mainframes are just unix. The problem is the average IBMer will not know how to secure your zOS server. If you ask them how to configure, or how to manage files they'll tell you their aren't any. This is simply amazing double speak because they are, and are not correct. When you first log into this systems you see the old zOS stuff, which looks and feels like MTS system360-67M/70 (its a long story). All your files are data sets, which aren't files, see MTS didn't have files, it had data sets. But it isn't. Its just a mainframe layer running on AIX. Its called something dumb like encom, unicom, in MTS . That brings you into proper unix mode. Which you may think is running inside MTS, but it isn't. MTS is running inside AIX. Because keeping MTS up to date with modern hardware would be impossible. So we just trick it into thinking its processor is running at the Plank frequency. Not 200 PowerPC chips or what ever IBM shoves in these things today. Then your in a standard unix environment. If you attack these things from the outside (and get in), you'll see and feel what looks like a BSD/SysV (ish) system. Because that's what it is. Its a unix system. But nobody configures this crap because the mainframe dudes can just say, "Oh no there are no files on a mainframe, just data sets, they're different." But if I steal a data set in unix mode, its a file. So no, your wrong. Nobody really goes into Unix mode half the time. They just care about keeping the system360 stuff working. Nobody cares about security because "Its a mainframe, they don't have security issues." Well they do, just like every other unix box on the planet. But unlike every other unix box we pretend they don't need security.
  - marktangotango 12y ago
    I don' quiet buy your assertion that z/os is an emulation layer over AIX. When I used to while away the days poking around on a z/os machine, it was not that cut and dry. I couldn't just access a dataset from the shell, and the mainframe permissions model was pretty effective at locking down what I could get too. Do you have any references to back that ie an IBM red book?
    - hvs 12y ago
      I think he is saying that a lot of these companies have a mainframe emulator running z/OS on unix rather than a true mainframe. I'm not sure if that's true or not, but I believe that's why he is saying you can attack from the unix side. z/OS itself is most certainly not an emulation layer over AIX. It's a complex operating system with 50 years of history behind it.
- cdr 12y ago
  I used to know someone making a pretty good living doing COBOL for banks. Some people really do enjoy that sort of thing. Also a bonus of less (or even positive) age discrimination, since he was an older guy.
- _delirium 12y ago
  Could be personal preference, but that actually sounds more fun than a lot of things in tech. Software archaeology on ancient and possibly broken systems? Probably has lots of annoying parts, but also sounds pretty interesting. Is it really less annoying to do "modern" work, like learning the Nth new Javascript framework, dealing with piles of Chef scripts, extending Enterprise C++ codebases, spending weeks testing browser compatibility, etc.?
  - blincoln 12y ago
    My experience is that it's a lot less fun in practice than it is in theory. Uncommented spaghetti COBOL code is about as hard to reverse-engineer as an x86 disassembler dump done without debug symbols, IMO.
Retric 12y ago
Failing to migrate after a M&A is failure to invest in IT. It's a stupid, short sited, and expensive failure, but good luck finding banks willing to pay for it.
- GVIrish 12y ago
  Banks will only become willing to pay after experiencing expensive, massive disasters like what JPMorgan is experiencing. Maybe. Migrating and/or killing large legacy enterprise applications is monstrously expensive, so the decision makers often decide against it. Relatively speaking, there haven't been enough very large companies that have been burned by that sort of decision, so executives at these companies (and the government) are less likely to see how badly it can go. Then there's the very real challenge of justifying a big IT spend on retiring legacy applications to the shareholders. And the high chances of large enterprise IT projects going wildly over budget. As much as we like to point the finger at the c-suite guys who keep doubling down on technical debt until there's a disaster, it's not an easy to make the case for paying to fix the problem. At least not until there are plenty of negative case studies out there like this one.

at-fates-hands 12y ago

>>> that doesn't mean management should be expected to value IT in such a way that they actually are willing to pay significant amounts for it! I was at one large financial company similar to JPMo and every time the development team came up with a good idea, it was met with a laundry list of requirements we had to meet in order to show positive ROI over a very short time period. Not sure if they did to discourage us from trying to help processes and development, or they really believed redesigning some parts of their network architecture could be done in a month or two. Either way, it was quite frustrating to say the least, and after a few gallant attempts to get something going, most of the younger developers just opted out and left. I saw the writing on the wall and was in the second wave of people who finally gave up and moved on.

wheaties 12y ago

JP pays programmers very well. In fact, it's very good for the counties in which those programmers are employed. Well, that is, if they were in a money center. Costs centers, like security and infrastructure, those places they minimize the costs! Part of minimizing costs is all about not paying for things that aren't expressly needed or killing programs that might make sense but cost too much. I worked there for half a year before quitting and going back to a start up. Nice people but only the people at the top seem to have a clue as to what to fix and they, themselves, can only focus on so many things at once.