4 ms·

The issue in finance is the speed of change in demands. No formalized system platform with proper change control can keep up. The ability to play with data, the

The issue in finance is the speed of change in demands. No formalized system platform with proper change control can keep up. The ability to play with data, the ability to break your work is valuable in end user computing and the type of thing that is hard to recreate in a formal financial system that must pass internal and external audits. edit: I entire a whole.

rapht 9y ago
This - exactly
guitarbill 9y ago
> hard to recreate in a formal financial system that must pass internal and external audits. This should also be the reason for getting rid of Excel, it is basically inauditable. But then again I guess all the auditing firms (e.g. Deloitte, KPMG, EY) probably have a vested interest in keeping it that way, not to mention all the persons who use this deniability for fudging numbers. I guess we'll always have ethics to fall back on /s
- rabboRubble 9y ago
  I've worked in global banking environments (where one holding company contains a traditional banking arm and a securities firm) with a slight lean towards securities operations, although I've serviced both the banking and securities operations. Your exact comment happens constantly in global banking firms. If the banking arm happens to be in a stronger management position, they push towards locked down system with tight development cycle controls. Typically the bankers have low risk tolerances and their systems (ex. savings and payment client account ledger systems, ATM ops, etc.) reflect it. That said, even in a true banking company, the closer the department is to the interest rating trading operations the more the banking environment looks like a securities operation. You will find critical on-the-fly modeling taking place, data integration, data reintegration all happening in Excel spreadsheets and these XLSX will be driving business decisions. In securities operations the pace of change (demands originating from regulatory bodies, external clients, and internal trading operation, etc.) inevitably push the boundaries of what the bankers can support. If your securities side regulatory body says the firm must implement X in order to report Y, the firm is obligated to do it, regardless of what banking IT risk and change control framework the bank thinks should be followed. If the regulatory body says X should be in place by Z date, and banking assessment / change control procedures can not be finished by Z date, guess what X gets implemented by Z date. There is no choice. Same goes for client system demands. Woe be the IT staff who tries to tell a securities side broker their client demand can not be fulfilled by some change control / risk assessment procedure. Do such a thing enough and the desk's profitability will take a hit. Which means the trader's bonus will take a hit. Which means IT will take a hit. If a proprietary / quant / interest rate trader can't respond quickly enough to market change X because it took 3 days for a revised real time report to be created and then vetted by a formal change management process, the IT staff pushing those processes will be replaced. Looking at the situation another way, having these time sensitive demands in Excel instead of in trading systems is actually kind of smart. Try to integrate the rapid trading desk decision making that happens in Excel into the trading / transaction ledger / transaction settlement system will just endanger the smooth operation of the those systems. Fewer changes the better in these core systems.
  - cm2187 9y ago
    And I am sure that like me, you have witnessed multiple production systems used for critical missions that are simply too old or expensive to update, or that have been marked legacy but never replaced. These systems are as problematic as spreadsheets.
    - rabboRubble 9y ago
      Yep! These ancient systems are one more reason why Excel spreasheets exist. The Excel file backfills missing functionality in the ancient system to permit the end user to do their job as defined some 30-40 years after the legacy system first came online!
analog31 9y ago
I wonder if this also describes scientific programming pretty well.
- rabboRubble 9y ago
  Not sure... would be interesting if you could describe a situation in that field?
  - analog31 9y ago
    Granted, I don't know if what I do qualifies as "scientific programming," but I'm a scientist working at a company that makes measurement equipment. I don't write software for widespread use, but use programming as a problem solving tool for modeling, data collection and analysis, visualization, and so forth. I rarely run a program more than once before I change it. Now, maybe I'm excusing myself for being relatively un-disciplined, and in fact I am working on improving my programming discipline. For instance a colleague and I have begun to use git for a code that we share. But when I hear people being told that they shouldn't use ad hoc programming tools, and the resulting reaction from those people, I imagine myself in a similar conversation.
    - rabboRubble 9y ago
      Similar underlying dynamics for sure. Users have job demands, so they find an IT tools to do their work better / faster / smarter. The request goes to the IT department that needs to manage support costs, firm wide licensing requirements, ITIL process demands, and the user request easily goes into a back hole. User base unhappy, pressures IT, IT feels heat and worries about their job so IT fudges X in their process to implement, wash rinse repeat.

rapht 9y ago

This - exactly

guitarbill 9y ago

> hard to recreate in a formal financial system that must pass internal and external audits. This should also be the reason for getting rid of Excel, it is basically inauditable. But then again I guess all the auditing firms (e.g. Deloitte, KPMG, EY) probably have a vested interest in keeping it that way, not to mention all the persons who use this deniability for fudging numbers. I guess we'll always have ethics to fall back on /s

rabboRubble 9y ago
I've worked in global banking environments (where one holding company contains a traditional banking arm and a securities firm) with a slight lean towards securities operations, although I've serviced both the banking and securities operations. Your exact comment happens constantly in global banking firms. If the banking arm happens to be in a stronger management position, they push towards locked down system with tight development cycle controls. Typically the bankers have low risk tolerances and their systems (ex. savings and payment client account ledger systems, ATM ops, etc.) reflect it. That said, even in a true banking company, the closer the department is to the interest rating trading operations the more the banking environment looks like a securities operation. You will find critical on-the-fly modeling taking place, data integration, data reintegration all happening in Excel spreadsheets and these XLSX will be driving business decisions. In securities operations the pace of change (demands originating from regulatory bodies, external clients, and internal trading operation, etc.) inevitably push the boundaries of what the bankers can support. If your securities side regulatory body says the firm must implement X in order to report Y, the firm is obligated to do it, regardless of what banking IT risk and change control framework the bank thinks should be followed. If the regulatory body says X should be in place by Z date, and banking assessment / change control procedures can not be finished by Z date, guess what X gets implemented by Z date. There is no choice. Same goes for client system demands. Woe be the IT staff who tries to tell a securities side broker their client demand can not be fulfilled by some change control / risk assessment procedure. Do such a thing enough and the desk's profitability will take a hit. Which means the trader's bonus will take a hit. Which means IT will take a hit. If a proprietary / quant / interest rate trader can't respond quickly enough to market change X because it took 3 days for a revised real time report to be created and then vetted by a formal change management process, the IT staff pushing those processes will be replaced. Looking at the situation another way, having these time sensitive demands in Excel instead of in trading systems is actually kind of smart. Try to integrate the rapid trading desk decision making that happens in Excel into the trading / transaction ledger / transaction settlement system will just endanger the smooth operation of the those systems. Fewer changes the better in these core systems.
- cm2187 9y ago
  And I am sure that like me, you have witnessed multiple production systems used for critical missions that are simply too old or expensive to update, or that have been marked legacy but never replaced. These systems are as problematic as spreadsheets.
  - rabboRubble 9y ago
    Yep! These ancient systems are one more reason why Excel spreasheets exist. The Excel file backfills missing functionality in the ancient system to permit the end user to do their job as defined some 30-40 years after the legacy system first came online!

analog31 9y ago

I wonder if this also describes scientific programming pretty well.

rabboRubble 9y ago
Not sure... would be interesting if you could describe a situation in that field?
- analog31 9y ago
  Granted, I don't know if what I do qualifies as "scientific programming," but I'm a scientist working at a company that makes measurement equipment. I don't write software for widespread use, but use programming as a problem solving tool for modeling, data collection and analysis, visualization, and so forth. I rarely run a program more than once before I change it. Now, maybe I'm excusing myself for being relatively un-disciplined, and in fact I am working on improving my programming discipline. For instance a colleague and I have begun to use git for a code that we share. But when I hear people being told that they shouldn't use ad hoc programming tools, and the resulting reaction from those people, I imagine myself in a similar conversation.
  - rabboRubble 9y ago
    Similar underlying dynamics for sure. Users have job demands, so they find an IT tools to do their work better / faster / smarter. The request goes to the IT department that needs to manage support costs, firm wide licensing requirements, ITIL process demands, and the user request easily goes into a back hole. User base unhappy, pressures IT, IT feels heat and worries about their job so IT fudges X in their process to implement, wash rinse repeat.