51 Percent of Financial Services Companies Believe Existing Tech is Holding Them Back (betanews.com) 141
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.
Don't blame the tools (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.
Re:Don't blame the tools (Score:5, Funny)
That and the packard bell you use for legacy applications.
Re: (Score:2)
Re: (Score:2)
I work on a team that maintains a financial application that talks to banks via ACH. I can't believe some of the restrictions they put on it, such as enforcing a single connection at a time, so we have to serially transfer 70+ files for various funds one at a time, waiting for an acknowledgement before the next one can start, and their systems take fucking forever to ack the thing.
That job takes like 3+ hours to run, when it could take 20 minutes total if they allowed parallel connections, even with using
Re: (Score:2)
What you just explained sounds a lot like the exact problems I had 25 years ago. We did however have a pretty cool hardware encrypted 4800 baud modem for it. Still, we were a data warehouse for several thousand banks and ATM machines. I'm pretty sure we spent between 8 and 10 hours a day transmitting and receiving batches.
Tell me, is EDI-FACT in EBCDIC still the hot thing?
Re: (Score:3)
Why isn't the app running fast enough?!
Re: (Score:2)
That and the Data General you use for legacy applications.
There, fixed it for you.
Re: (Score:2)
Re: (Score:2)
I often see people not using the systems they have to their full potential. Implementation if more than hardware. Training users on the use of their own system is also part of implementation.
Source I also work in IT.
Re: (Score:2)
Most people don't like pushing beyond what they are comfortable doing. They rarely go beyond that which they are familiar with. Training doesn't solve that problem, as it doesn't change the dynamic from "go to the freezer, get the box" to "I know this can do that, but I wonder how".
IT people tend to be perpetually curious, which is why we often don't understand our users lack of curiosity.
Source: I also work in IT
Re: (Score:2)
Users don't lack curiosity they simply have no motivation to be curious when it comes to tech.
Jesus. When I started working (in IT), users were afraid they’d get electric shocks when you introduced them to the computer terminal...
But it was kinda a blessing, because the most enthusiastic users were the ones who would fuck up things... Heck, I once saw a financial analyst dance of joy, calling himself “space cadet” when I finished installing a CP/M computer in his office...
Re: (Score:2)
I often see people not using the systems they have to their full potential.
Oh god. I stopped counting the times I got shit for putting some user’s 17 inch CRT to 1024 x 768 resolution up from their customary 800x600...
“Everything is too small!”...
Re:Don't blame the tools (Score:5, 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.
Too hard to change fundamentals (Score:2)
In complex systems some parts depend upon other parts. So it is very difficult to change those at the bottom without upsetting everything.
So the solution is to work around the core issues. For example, a web based banking interface does not attempt to store additional information in the ancient COBOL core. Instead, it copies information into its own database, and then syncs via complex protocols. Over time more and more of these work arounds make the system harder and harder to change.
This is why a sma
Re:Don't blame the tools (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.
Re: (Score:3)
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
Ultimately, that's true for any company that doesn't have techies up to the CEO level. At some point, someone who has no clue about IT will be doing the hiring of (at least) IT management.
Re: (Score:2)
Re: (Score:2)
It's not hard to learn things about IT.
Yes it is. You need to know enough so that you can interview a candidate and tell the difference between someone who is competent and a BSer who knows all the buzzwords, has a surface level understanding of many things, and can even do routine tasks like "set up a VPN on this server", but is unable to troubleshoot complex failures.
That is not easy, and even when interviews are conducted by professional IT managers, you are still going to get about 20% "bad hires".
Re: (Score:2)
Re: (Score:3)
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”...
Re: (Score:2)
"Good IT is expensive. Bad IT is costly"
Was it the president of Harvard who said “You think education is expensive? How about ignorance?”...
Re:Don't blame the tools (Score:5, 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).
Re: (Score:2)
I suspect there's been 15-20 years of programmers telling the higher ups that they need to rewrite this stuff
When programmers are faced with maintaining someone else's code, they ALWAYS recommend throwing it all away and starting over. This is rarely the correct thing to do.
Things you should never do [joelonsoftware.com]
Re: (Score:2)
Re: (Score:2)
VB6 is not all that bad, and it was madness for Microsoft to completely abandon it. A VBA programmer will have a project finished before a Java programmer can configure their Enterprise Application Server, or a C programmer can track down their obscure memory corruptions. .Net is better than VB6, but not that much better in practice. They could have walked VB6 forward. Added real compilation etc. Things like Set vs Let are historical oddities, but OK, and have an advantage of enabling a default value fo
Re: (Score:3)
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 [xkcd.com], as every change and new feature has to duplicated in both codebases. People
Re: (Score:3)
Re: (Score:2)
That is a good approach to take for some projects. Unfortunately, not others. Like a certain company I know who has 20+ clients, all running what should be the same code, but it's 20 different COPIES of code in various stages of development. Try getting that under control, lol.
The code base isn't very TDD friendly. Like there are routines that are 50,000+ lines long, which basically does everything. And there are 20+ copies of that routine, that are all slightly different, most of the time for no reaso
Re: (Score:2)
I don't know that much about it, but would that be all that difficult to migrate to VB.NET?
Re: (Score:2)
I blame outsourcing.
Banks ARE CHEAP and hire Indian kids for programmers and infrastructure and pay them $15/hr to code and maintain the systems.
When you feel $30,000 is all a senior level developer is worth they won't bother upgrading them. After all they work fine right??
Now a good Wall Street trader? Now that generates revenue according to the executives
So they made a conscious decision not to upgrade (Score:2)
Re: (Score:3)
Unless, what they meant was that they had a lack of *IN-HOUSE* technical skill, in which case, stop outsourcing it!
Re: (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....
Unless those who have the technical skills start retiring. (think: COBOL)
Re: (Score:2)
Unless those who have the technical skills start retiring. (think: COBOL)
Unless those who have the technical skills were downsized.
Re: (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.
They only have themselves to blame (Score:5, Insightful)
This is not hard (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.
Re: (Score:2)
You might as well ask caterpillars to tend your flower garden.
Another crap tech article (Score:1)
Just more crap. They state lots of exact percentage numbers, but talk 100% vague about "legacy technologies". Please define "legacy technology".
And please be very specific about 1) what you're using now, 2) what / how you're being limited, and 3) what the new advanced world-saving technology is and how it will solve all of your (perceived) problems.
Then I will tell you about how much productivity you'll lose while people 1) sit in "training" classes, 2) have problems opening up that old document, .xls, et
Re: (Score:3)
Really, no takers? I thought this was one of the best pieces of troll bait to be spun through Slashdot this month.
Re: (Score:2)
Now combine that with a biting comment from a Windows XP footdragger who doesn't like Windows 7 (with "upgraded" literally in quotes) and you have some grade-A SlashDot trollbait.
Brokerage software and Beta (Score:4, 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.
Sorry, I had to laugh (Score:2)
Re: (Score:2)
Don't need no stinking' documentation. We're Agile.
Re:Brokerage software and Beta (Score:5, 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!
Re: (Score:2)
30 years ago, I had a job maintaining Business-Basic programs for an non-IT company. It was okay, and I ran around Business-Basic limitations by writing a "pre-compiler" (a bit modelled after "CPP") that enabled the use of long variable names and labels instead of line numbers. Over the time, the final Business-Basic source-code was pretty well documented so you could work without the pre-compiler.
Then I left for other pastures, never to return.
About 5 years ago, I took a Business-Ba
more like... (Score:3)
Nope (Score:1)
These are financial services companies. They're not upgrading because there's a huge perceived risk taht the upgrade will fail in a manner that destroys the company. Certainly, the kids believe that COBOL is obsolete and inherently bad, but the existing code base is giving 5 nines of uptime, and new code might fail.
Re: (Score:2)
The problem is there isn't any significant number of new Cobol programmers. I sure wouldn't want to use it, and I was willing to put up with Fortran II. OTOH, I never really understood Cobol, so take the rest of this post with a large grain of salt.
I was trying to think what other language might be reasonable to rewrite things in, and couldn't come up with anything. The two that seem closest are Lisp and Ada, and if you have any idea how different those are, it might give you an idea of how poor a fit ev
Re: (Score:2)
(Back when I programmed in COBOL, I would label the fist line of procedure “XXXX000” and the last one “XXXX999”, so I would always call a procedure with “PERFORM XXXX000 THROUGH XXXX999”; that was my way of bringing some kind of structure to the COBOL code I was didling with).
Re: (Score:2)
Actually, I rather liked PL/1. It's a pity that it died rather than improving. It had a lot going for it. And it *was* intended to replace COBOL as well as FORTRAN. It failed at both. Fortran is still going well in specialized areas. In certain ways it's the fastest language beyond assembler. COBOL....well, as I said above, I never really understood it. But PL/1 had more success with Fortran IV programmers than with COBOL programmers, for whatever reason. And the last version of PL/1 that I heard o
Really? (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.
That God! (Score:3)
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.
Re: (Score:2)
Well, there's more than one kind of business that could be called "financial services". For a certain kind of "financial services" your description is quite apt, but I guess I was thinking of a different segment...which still isn't anything that I think highly of, but which doesn't merit wholesale condemnation.
Re: (Score:2)
I was talking banks and brokerages. They do not have customers, they have marks. It makes more sense to keep your money under a mattress these days than in a bank
We need more Blockchain!!!!!!!! (Score:2)
Serverless Blockchain Containers orchestrated by Kubernetes and deployed by Jenkins, Terraform, Vagrant and friends are the savior the financial sector needs!!!!!! Buy CloudWeasel CI/CD today! Any workload, any toolchain, any cloud!
(OK, in all seriousness...if they're talking about mainframes and COBOL underpinning almost everything they do, I might agree.) This just sounds like a study by a consulting firm [[looks-- oh yes, it is!]] planting the seeds of doubt in executives' heads to get the purse strings
Regulations are holding them back (Score:4, Insightful)
Faster and better? (Score:4, Insightful)
What consumers/customers want (even if they don't know how to pronounce it) from financial products is:
So, in other words, not to have to deal with financial institutions at all.
Re: (Score:2)
I think that assessment might be a bit generous to consumers. They only care about security after they've lost money. They only care about privacy after sensitive information has leaked. They only care about clarity when they start to suspect they're being ripped off. They only care about honesty when they discover they're the ones being ripped off.
What most people want from financial products is a fail-safe get-rich-quick scheme. They'll turn a blind eye to a lot of problems as long as they think the
Re: (Score:2)
I don't know about "most people," but I do think you've identified a population. As P.T. Barnum said, there's a sucker born every minute. And I'm sure there is a legion of financial "service" firms ready to take advantage of an easy mark.
Ahh... another one (Score:2)
Consultancy specializing in "digital transformation" (i.e., popular new buzzword) does self-serving survey that miraculously finds that their services are needed.
I especially like the finding that 29% of companies are whining about not having the needed skills in-house. I predict that the survey did not ask companies whether they were investing in any training for their IT staff and, if they had, the responses would range from "Hell, no!" or "No" to "Huh? What is this `training' thing you asked about?"
Probably not wrong (Score:2)
I'm not much of an expert in finance, but I know a fair amount about IT, and I'd say it's a safe bet that crappy technology, legacy tech, and vendor lock-in is holding back a lot of efficiency and innovation.
I mean, technology in general is adding a lot of innovation and efficiency. For sure. But I see a lot of businesses depending on some weird custom-built application that was built in the '90s and doesn't support any OS past Windows XP. I see a lot of simple, common problems going completely unaddres
Re: (Score:2)
The REAL patented problem. (Score:3)
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.
More and more tired old tropes (Score:5, 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.
Re: (Score:2)
We spend as much on testing our security as we do on the security.
Not being in that field, I’m curious: does your company share (both as provider and recipient) methodology information (security best practices, etc.) with others in the financial sector (or with an even wider audience) or is it something that is considered somewhat secret (competitive advantage, etc.)?
Re: (Score:2)
Competitive advantage. I do not know if we share within other security forums, probably yes, when we see either dangerous new methods, but we do not share anything proprietary unless it were a known industry-wide problem and we saw a duty to share.
Re: (Score:2)
Interesting, thanks! I understand the business rationale, and I can also imagine the difficulty to share methods that could reveal too much about one’s infrastructure, or could be too specific to an architecture to be broadly applicable to others. At the same time, as an outsider, I find it striking that mistakes seem to be endlessly repeated (by different entities) and I also imagine that those mistakes have the potential to fragilise not merely those who make them but to also spread to partners, sup
Re: (Score:2)
There's yer problem (Score:1)
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).
Item number 1 is a symptom of item number 2. Item number 2 is a symptom of item number 3. Item number 3 is a symptom of outsourcing everything to India.
You get what you pay for.
Not so (Score:3)
"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.
skill (Score:3)
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.
Re: (Score:2)
Larger problem (Score:3)
Re: (Score:2)
Of course, they've often forgotten that their existing workflow is the way it is to accommodate the limitations of the old tech and the limitations of paper processing before that. Yet, somehow even minor changes are off the table even if it means the difference between using something off the shelf or either spending a fortune in modifications or spending a fortune on spit and bailing wire to hold the old system together for another year.
Clean up your act first (Score:2)
I just want to say one word to you. Just one word (Score:1)
Benjamin: Yes, sir.
Mr. McGuire: Are you listening?
Benjamin: Yes, I am.
Mr. McGuire: Blockchain
Benjamin: Exactly how do you mean?
Mr. McGuire: There's a great future in Blockchain. Think about it. Will you think about it?
Existing tech, how would they know? (Score:3)
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!
Re: (Score:2)
What's holding back innovation? (Score:3)
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
PASS (Score:2)
Re: (Score:2)
Heresy! We must burn fluffernutter!
Consumers want.... (Score:2)
The foolish consumers may want "better, faster financial products.", but that's nearly a contradiction, and is one if better includes more secure.
FWIW, I don't want my financial data going over the internet in any way. Well, I can't stop that, but I can restrict the amount of exposure I give myself. You'd think nobody had ever heard of Spectre or Meltdown. I've given up all purchases over the internet until those are widely patched. And I've never been willing to do on-line banking, despite the ads prom
Alternate Title: (Score:1)