Hacker News Reader

>The only financial services companies that are seeing positive uplift from these sorts of initiatives are those with enough resources to try this path, fail at it, and then decide they wanted to build 100% of their own stack in-house anyways.

The issue is a lot of the executives that join the bank's C-suite after 10-15 years of experience usually come from consulting... And as you can imagine they keep hiring and re-hiring their old firms to have 2-3 business graduates come and make a PPT telling a room full of engineers and developers how they should be building complex systems.

> and make a PPT telling a room full of engineers and developers how they should be building complex systems.

This is unfortunately not an experience I am unfamiliar with. I have to pretend to eat a big plate of humble pie on the first technical call with a lot of our clients.

Once you learn their first reaction is going to be to reject your proposal on arbitrary grounds (i.e. a new security theater show), you start to present simpler proposals purely for the sake of tripping their initial response. Once you get them to fire their objections across the way, it is really easy to review the impact and build the real proposal that meticulously deals with each point that was raised.

I'm having this exact issue now. For me, your timing was perfect, thanks.

Priceless and timeless advice for both internal and external engagements.

Bob nailed it for sure. This approach works.

This is usually good advice for any time you're selling a proposal. Your first attempt is going to be shot down. The more detail it has, the more ammunition there is to shoot it down. So build the minimum viable presentation that's going to trigger an emotional response and tease out the actual issues. Build the real proposal once you've triggered your customer into revealing what's actually on their mind.

People often can't express what they want, until you show them what they don't want.

When building a proposal to C-suite or stakeholders bring it to a level they will understand. Don't focus on technology, stacks, interfaces. Focus on efficiency, improved operations, reduced costs, bigger bottom line. This is the language that is hard to argue.

This is my experience as well. I work for a pretty large consultancy and the majority of my projects, when i look up the primary stake holder on the client side that brought us in, oh would you look at that he used to work at my consultancy 3 years ago.

Most of our biggest clients leadership is filled with ex-employees of my firm.

My observation is that everyone is looking to simplify and streamline operations, and the financial sector just suffers more from faults in the pipeline due to every entity being a special snowflake. That said, a proper foundation for these things really isnt that unique to finance imho, once you get past a few of the outliers. My problem is this: you can know how to do this, but the largest hurdle is the army of incompetent middle managers who filter any truth from technically out of date c-suites. No amount of "tech stack" can fix these human problems.

I find myself considering if I even want to turn my years of experience into a bunch of ML-ops rules for these people in the first place...

> No amount of "tech stack" can fix these human problems.

This was the most painful lesson we had to learn so far.

The bootstrapping is the hardest piece looking back on the last half-decade. Once you figure out how to make 3 different customers work using the same code pile, you are moving in a good direction. Implementing for 1 customer at a time in a serial fashion is a path for guaranteed failure if you are expecting to just copy that code pile to the next one and have it fit their needs. We tried to do this 3 times and only by the grace and understanding of our angel investor are we still doing business.

My new job is to ask the question "Will this feature/function/enhancement work for all current and future hypothetical clients?". Forcing the team to think in this way was a challenge, but it's kind of our default mindset now. When you guard for bullshit like "what if the account number is longer than 64-bit integers for some future customer?", you trivially-sidestep things that have literally killed other businesses. Clearly, you can take all of this too far, but only if you actually implement in code the proposal before realizing your mistake.

I wonder how startups are able to do this with 3 enterprise customers. The amount it takes to get us through procurement has almost already killed a startup I’m working with. Any advice on picking the right customers? We also don’t have that many resources to potentially dedicate to serve 3 enterprises at a time.

I think we're in the middle of a bit of a transition phase within the industry.

> Every single one of our customers is looking for a path back to something that looks like the mainframe in terms of vertical integration of the business stack.

I think this is always going to be true as a desire, but it's also true that it's likely an impossible state to achieve completely. There will always be consolidation efforts, but with the rate of M&A and growth of new markets and alternative products, I don't think anyone can afford only consolidation as a strategy today. So in the end, it's a losing battle to try and avoid system sprawl at the moment.

> The only financial services companies that are seeing positive uplift from these sorts of initiatives are those with enough resources to try this path

My view has been the exact opposite, only the resource heavy FS companies are the ones who can afford to pursue consolidation!

> Many of our clients are stuck in some contorted stance with half their stack in AS400-land and the other half scattered to the various "cloud" services which are mostly just random websites/services with shitty SOAP APIs (or no APIs at all).

My take, and what I think this article is poorly commenting on, is that everyone is betting on and trying to pursue open banking. Rather than move internal systems into a more simplified format, pushing the market to use common standards and unify behavior across the industry. We're in a phase that is not quite there yet, but bits and pieces are starting to move, so it's very messy. And that's why it seems that strategies for vertical integration and open-source both can coexist in the zeitgeist today.

Caveat, I do work on tech innovation from a regulator and FMI side, so I'm certainly missing the nitty gritty of your perspective.

yep, a lot of this is fallout from the financial crisis and all of the bank mergers that have happened. A number of the big banks i worked with a few years ago had sooo many different systems from all their acquisitions and what they really want is one

This is an excellent point. It's fun to blame consultants, but the amount of M&A that has occurred can probably be implicated for half of the complexity seen in banking today.

The nuance with M&A between 2 banks is that one usually "wins" in terms of the core tech (i.e. where all the customers and accounts are ultimately stored) and absorbs the other. There are companies that specialize in this exact activity. The part where it gets super messy is with the jurisdiction-specific systems & procedures that have to be folded into 1 operational space.

I relate to this. Is not just a lot of vendors, is that the kind of software stack that is optimal for MOST enterprises/companies get out of fashion in the dev community and is replaced with a lot of moving gears. This is how many devs think JS/html are good for UIs or NoSql + micro-services are ok.

What is this stack? A single, strong, RDBMS and a lang/environment like FoxPro/dBase and equivalents. For reasons, this stack was killed (intentionally?) by their own owners and replaced by a lot of moving parts.

That is why for deploy something you need dozen of things!

---

I think the time is ripped for a return to this kind of stack. I'm betting a little on it at http://tablam.org, if wanna check a small part of the puzzle.

I can't recall any major security lapses with online banking, which would seem to be fairly exceptional for a segment of the economy of its size. And, as far as I can tell, there is some pretty impressive technology being used in market operations (both secure & incredibly fast) as well as trading.

So, while I am sure it can often look like a comedy of errors from the inside, I'm less certain that it is worse than any other sector. Nor would I ascribe such problems on the tired scapegoat of MBAs: plenty of tech people have been promoted to management in the past, and if their results were obviously better, even the most corrupt country club management would have to change their ways at some point.

>Every single one of our customers is looking for a path back to something that looks like the mainframe in terms of vertical integration of the business stack

Thank you very much for mentioning the reality of mainframes.

If something needs to work, always, every-time and with minimal maintenance, mainframe it is, that's the good thing,

The bad thing is, that occasionally you have to change your code (external factors) and since it was just running in the past (say >20y), you completely forgot to have a cobol-dev at hand.

> bad ride by legions of consultants over the last ~2 decades

For a long time the most important factor was a head count rather than quality. Financial institutions often used loopholes to ship workers from 3rd world countries and indirectly paid them their country of origin wages and small allowances. These workers would live in wholly rented hostels and replaced every 6 months (to avoid residency laws messing the tax implications).