Slashdot Mirror


51 Percent of Financial Services Companies Believe Existing Tech is Holding Them Back (betanews.com)

An anonymous reader shares a report: Legacy technology can be a major obstacle to digital transformation projects and, according to a new survey of financial services technology decision makers carried out for business consultancy Janeiro Digital, almost 51 percent say existing technology is holding back innovation. Three of the biggest roadblocks are seen as lack of support for change (34 percent), legacy technology and infrastructure (31.6 percent) and a lack of in-house technical skill (29.5 percent). As a consequence 23 percent of respondents believe their company is behind in digital transformation compared to others in the industry. Only 47 percent are currently implementing new technologies, with 12.6 percent wanting to do so but not having started. That leaves 40 percent not innovating which could see them lose out in a world where consumers want better, faster financial products.

31 of 141 comments (clear)

  1. Don't blame the tools by Revek · · Score: 5, Insightful

    Blame you're implementation of them. Improperly trained Bosses and ingrained static procedures often are the reason the tech you have isn't working for you.

    1. Re:Don't blame the tools by Revek · · Score: 4, Funny

      That and the packard bell you use for legacy applications.

    2. Re:Don't blame the tools by Archangel+Michael · · Score: 5, Interesting

      The blame doesn't go for implementation, it goes for not understanding the opportunity cost of not doing something you should. When enough opportunities are passed, the businesses will cease to exist.

      I phrase it like this, "Good IT is expensive. Bad IT is costly".

      Do you have backups (expensive)? At some point it will cost you if you don't. It isn't a matter of if, but when.

      --
      Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
    3. Re:Don't blame the tools by the_skywise · · Score: 2

      But the turbo button is pressed on my packard bell PC!
      Why isn't the app running fast enough?!

    4. Re:Don't blame the tools by KingMotley · · Score: 4, Insightful

      I suspect there's been 15-20 years of programmers telling the higher ups that they need to rewrite this stuff and the bosses saying they can't afford it/don't have to time to do it/won't hire the additional people to do it. All the while creating new non-standard tweaks to the system that has turned it into a big hairy ball of mess.

      Sucks to be them now.

      Source: I also work in IT, and deal with financial clients (Most of the big names).

    5. Re:Don't blame the tools by CodeHog · · Score: 2

      Agreed. And banks don't want to pay for good IT folks. Been there and hated it. I worked with one dev who took smoke breaks in the server room. They found it funny that I told them it damages the equipment. God I'm glad I left. Now I have to deal with in-house finance group but I can tell them to shove off when I want to.

      --
      Fat, drunk, and stupid is no way to go through life, son.
    6. Re:Don't blame the tools by ShanghaiBill · · Score: 2

      And banks don't want to pay for good IT folks.

      It is difficult for non-techs to tell "good" IT folks from "bad" IT folks. Why pay more when you can't tell the difference? Of course, you can tell the difference when things go wrong, but by then it is too late.

    7. Re:Don't blame the tools by MachineShedFred · · Score: 4, Insightful

      This is a manager sickness - they don't see the difference between "operations" and "engineering".

      The operations people should be fighting those fires. The engineers should be creating long term solutions that prevent the fires to begin with. If your engineers are working a fire hose all day, nobody ever shuts off the fuel source and all you get is fires.

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    8. Re:Don't blame the tools by Pig+Hogger · · Score: 2

      I worked with one dev who took smoke breaks in the server room.

      I once worked for $BIG_CIGARETTE_MANUFACTURER. On the IBM mainframe computer CPU cabinet was a big ashtray with a sign “thank-you for smoking”...

    9. Re:Don't blame the tools by ShanghaiBill · · Score: 2

      Would you still be saying the same thing if you worked with me and saw the several million lines of VB6 code I maintain?

      Yes. "Starting over" is almost certainly a mistake. That codebase handles much complexity and covers many corner cases that you likely fail to appreciate. It isn't complex because it is "bad code" but because it is solving a complex problem. By starting over, you will need to build and budget for a new team. One team to maintain the existing codebase, while another team works on the new code. Soon you will have this problem, as every change and new feature has to duplicated in both codebases. People will grow frustrated, and quit or transfer to other projects, taking their expertise with them. As the "vision" people leave, and the remaining coders are under pressure to get stuff fixed, the new code base will start to fill up with hacks and workarounds. Then a new manager will take over and ask what should be done. The programmers will unanimously reply: "Throw it all away and start over".

      Instead of "starting over" here is what you should do:
      1. Set up a VPS, with the best OS and all the development tools. Snapshot it onto a thumb drive. Now you can always rollback to a working system.
      2. Set up a Git repository, and use it. Now you can track changes and rollback with much better granularity.
      3. Set up a bug database.
      4. Build a test suite.
      5. As you fix bugs and add features, start commenting and refactoring the code. Refactor where the bugs are.
      6. After every bug fix, add a regression test to the test suite. TDD & FBF.
      7. Once the code is mostly refactored and cleaned up, then, and only then, should you start shifting to a new platform. Make sure you can do it incrementally, the way Johnny Cash built his Cadillac: one piece at a time. This means being able to make function calls from VBA into your new platform (maybe C#?) and vice versa. Run your automated suite after every significant change.
      8. Use "continuous deployment". Don't roll out lots of big changes all at once, and alienate your users, but instead make lot of small changes regularly. Very importantly make sure the early changes are things the users WANT, like bug fixes and GUI improvements. This will give you stakeholder buy-in and build up karma that you can cash-in when problems arise.

      Good luck.

    10. Re:Don't blame the tools by Anne+Thwacks · · Score: 2

      I think you will find banks had computers since the 1950's, and had version control even then. They certainly had it in the 1960's. It was built in to the editors used with mag tape.

      --
      Sent from my ASR33 using ASCII
  2. They only have themselves to blame by Pig+Hogger · · Score: 4, Insightful

    They’re the source of their own problem. Whenever they manage to hire brilliant people, they hold them back with arcane process and lengthy byzantine procedures (mostly enacted to internally cover the bosses’ asses).

  3. This is not hard by PopeRatzo · · Score: 5, Insightful

    Instead of complaining about legacy tech "holding them back", maybe these "financial service" companies should invest in some better tech instead of using those record profits for stock buybacks and bonuses to C-level management. You've been eating out on the backs of taxpayers all through this last decade of the government giving you free money. Maybe it's time to do something that won't, you know, bring down the fucking economy again.

    Just a thought.

    --
    You are welcome on my lawn.
    1. Re:This is not hard by Narcocide · · Score: 2

      You might as well ask caterpillars to tend your flower garden.

  4. Brokerage software and Beta by Hadlock · · Score: 3, Informative

    I used to work for a finance company deploying and automating the deployment of finance software. There's a couple I know of. Talisys out in Denver is one, but the 800 lb gorilla is a piece of software called Beta. It's freaking ancient. Like, core parts still in use today are from the 1970s. I think they've written some API front ends for it, but you have to pay through the nose for every feature, and especially for the fancy features. Beta was written... back in the 1970s perhaps? It doesn't lend itself to modern development methods very well. But it works and has a solid, proven track record, which is exactly what risk adverse finance companies like, especially when they are signing four and five nine uptime SLAs. Talisys is a little newer, developed in the early (1992?) 1990s and came to market around 2002 as production ready, but it's still based on 1998 era technology and were crawling in to the modern age offering Windows Server 2012 R2 support in 2015. There was actually a two year gap between when WS 2003 microsoft windows extended service support ended and when they supported a newer version of windows (2012 R2) and yes you read that right some big (not huge) companies are running financial software on top of Windows.
     
    Other financial technology companies like Robinhood are written cloud-first and cloud-native with APIs in languages like Python and Go and Ruby and what have you. They're just going to eat up these old companies as their overhead costs are much lower and their code better documented and aligned more closely with modern programming practices. Their most modern competitors are running windows software designed in the 1990s. It's ripe for disruption and companies like Robinhood are absolutely going to grind these old companies in to a fine paste in the next ten years.

    --
    moox. for a new generation.
    1. Re:Brokerage software and Beta by goose-incarnated · · Score: 4, Interesting

      Other financial technology companies like Robinhood are written cloud-first and cloud-native with APIs in languages like Python and Go and Ruby and what have you. They're just going to eat up these old companies as their overhead costs are much lower and their code better documented and aligned more closely with modern programming practices. Their most modern competitors are running windows software designed in the 1990s. It's ripe for disruption and companies like Robinhood are absolutely going to grind these old companies in to a fine paste in the next ten years.

      No, they are not. It's easy to start a system from scratch regardless of the language you are using. Let robinhood get to the 10-year mark with their only-break-at-runtime-because-look-ma-no-compilation-step python software and they'll be crying for someone to buy them out.

      It looks easy when you first write the software, but let's see how resistant to breakage it is after 10 years of maintenance when half the code was written by people who weren't part of the original team. Their brand-new system of $X kloc of python+ruby probably works well enough with the existing specs. I want to see how well it works when changing requirements cause that codebase to balloon to $(X * 3) in ten years.

      Even worse, you're complaining about the current systems being written in obsolete languages; FFS Ruby is *already* obsolete and it's in their *new* system!

      --
      I'm a minority race. Save your vitriol for white people.
  5. more like... by swan5566 · · Score: 2

    ...their unwillingness to invest in upgrading it, because it will affect the bottom line in the short term.

    --
    In debates about Christianity, there are two groups: those looking for answers, and those looking to just ask questions.
  6. Really? by AlanBDee · · Score: 5, Insightful

    So a consulting company held a survey and found that 51% of companies believe that legacy technology is the biggest hurtle they face. That's good news for this consulting company that sells "solutions" to that problem. Oddly enough, my banker thinks I need a credit card and that car salesman insists that my old (2007) car is about to fall apart and I should buy a new one.

    Legacy technology and technical debt is a problem that is often overlooked and not budgeted for because it won't affect the stock price this quarter. Still, forgive me if I don't believe that this survey accurately outlines the problems that companies actually have to this degree.

  7. That God! by plopez · · Score: 2

    Their definition of "Innovation" is ripping more people off faster with financial shell games. Anything that impedes the "financial services" sector from "innovating" is a good idea.

    --
    putting the 'B' in LGBTQ+
  8. Regulations are holding them back by rsilvergun · · Score: 3, Insightful

    there are rules about how they change their tech to keep them from pulling all sorts of tricks and shenanigans with their software. They're hoping to make those rules go away. Believe me, you do not want this. Yeah, you'll get your new tech, but you'll get an unstable financial system and a crash that makes 2008 look like a happy memory.

    --
    Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
  9. Faster and better? by Anne+Thwacks · · Score: 3, Insightful
    I think not.

    What consumers/customers want (even if they don't know how to pronounce it) from financial products is:

    • security - as in not having their data leaking all over the place
    • privacy - as in not having their data sold to anyone who pays
    • not to be ripped off
    • clarity - as in being told the truth about what they are paying for
    • honesty (yes, I know they won't get it, but its what they want).

    So, in other words, not to have to deal with financial institutions at all.

    --
    Sent from my ASR33 using ASCII
  10. Re:So they made a conscious decision not to upgrad by freeze128 · · Score: 2

    And they also complain that they have a lack of in-house technical skill. The longer you work with your technology that has become old, the more skilled you will become at using it. Changing it too often just leads to chaos.

    Unless, what they meant was that they had a lack of *IN-HOUSE* technical skill, in which case, stop outsourcing it!

  11. Re:So they made a conscious decision not to upgrad by Narcocide · · Score: 3, Interesting

    They're gonna keep complaining like this until someone makes a computer that will learn to use itself. Then they will complain that it isn't fast enough.

  12. The REAL patented problem. by geekmux · · Score: 2

    The real problem is not existing products destroying innovation.

    The real problem is patent hoarding destroying the ability to innovate altogether.

    Go ahead. Try and invent something. I dare you.

  13. Re:Another crap tech article by xxxJonBoyxxx · · Score: 2

    >> a year or so ago I "upgraded" this very computer to Win7 from XP

    Really, no takers? I thought this was one of the best pieces of troll bait to be spun through Slashdot this month.

  14. More and more tired old tropes by rickb928 · · Score: 4, Interesting

    I deal with tech a lot where I work, an instantly recognizable financial business.

    Our core transaction processing systems run COBOL. When your Python app can settle as few trillion transactions nightly with deadlines met within minutes and downtime measured in seconds per year, present it. Someone will listen.

    The stuff I deal with daily now uses Cassandra for a db backend, all is hosted within LAMP stacks (we said goodbye to WebSphere a while ago), and is tolerating all major browsers for internal and external users. Our constraints aren't tech, they are resources; we decide to support a certain range of demand, and so size the systems according to budget. When our users begin complaining, we will resize.

    I've noticed a bunch of internal apps moved to interesting containers, and using two- or three-factor authentication. Our security methods treat employees as strangers, and internal systems as threats. Nothing is trusted until it is authenticated, carefully. This security problem is the source of much of the apparent lack of innovation in the industry, as we where I work are a top 50 target. Maybe top 10, we have not been told of a breach. We spend as much on testing our security as we do on the security.

    Our single biggest repository is on a custom Linux system, some our own software. It handles the volume you would associate with Google. It has to be secure.

    And we of course have document storage, but that's on old stuff based on Wang systems, which you cannot outperform yet. No you cannot.

    Yet we are faced with demand for flexibility, new and innovative solutions to new problems, and creative products. We've delivered a blockchain based international settlement system with a respected partner, at the same time as we've spun off a product that made all the sense in the world but didn't sell and are turning off one that just isn't working for anyone.

    A previous CIO lamented that a third of our projects failed. That's actually pretty good in the business world at large. But it's really not good enough. And new tech by itself will not do it. Better planning, better management, and better infrastructure will. And we are building those. I can name a few competitors that are clearly not, and I relish the opportunities we have to drink their milkshakes.

    --
    deleting the extra space after periods so i can stay relevant, yeah.
  15. Not so by Archtech · · Score: 2

    "That leaves 40 percent not innovating which could see them lose out in a world where consumers want better, faster financial products".

    Actually, it turns out that consumers want a good life; a happy, healthy family and friends; interesting work that (ideally) helps others; respect and appreciation; healthy, tasty food and drink; plenty of interesting exercise and sporting activities; enough money to enjoy all those things...

    "Better, faster financial products" come absolutely nowhere on the list of things that sane, sensible, well-balanced consumers want.

    --
    I am sure that there are many other solipsists out there.
  16. skill by fluffernutter · · Score: 2

    a lack of in-house technical skill (29.5 percent)

    It's a free market. Keep bumping up the offer until you get what you want. If the market isn't working for you then you're not trying hard enough.

    --
    Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
  17. Larger problem by sgrover · · Score: 2

    The technology is only part of the issue though. Organisational politics are a major factor. But then there are the hidden issues too. Such as "our order flow system does X, y, Z, and a,b, and in some cases c." Each of those areas has subtle and often undocumented/unspoken requirements and interdependencies. Replacing the overall system is highly desirable, but nothing can meet all the requirements out of the box, and sometimes modifying or building a system has extreme costs with zero benefits. I mean why pay a large amount of cash to get a system that does exactly what we have now, just so we can say we have modern technology. How do you justify that expense to shareholders and/or customers. And because the issues is large and ill-defined, managers would rather focus on the smaller well defined issues they have on their plate. There are better ways. But it's a judgement call if it is in a company's economic best interest to embrace the pain of adopting that better way.

  18. Existing tech, how would they know? by FictionPimp · · Score: 2

    How would they know. I still can't find a bank using proper MFA, good password rules, a solid web and mobile app UI, etc. Most of them are stuck in 2005 or 1998!

  19. What's holding back innovation? by najajomo · · Score: 2

    "according to a new survey .. almost 51 percent say existing technology is holding back innovation. "

    How about they stop relying on the industry standard Microsoft Windows.
    --

    I'll bet you're the kind of guy that hangs round Reddit fapping off over pictures of furries and yellow-scaled wingless dragonkin