Hacker News Reader

Comment by tdees40 | Hacker News Reader

Confirmed. I'm in insurance too - variable annuities specifically - and it's the most perfect problem for parallelization. In practice everyone maintains their own in-house grid (which is massively expensive and idle 90% of the time), and the technical staff lacks any serious chops to tackle GPUs. In practice the only way we've found to solve this is to go around corporate IT, so we do things like buying GPU cards and jamming them into boxes ourselves.

View on HN

As someone related to the field, I see a fundamental lack of quality in in-house IT when faced with problems of this magnitude. Which isn't unreasonable.

IT evolved to be able to provision systems and roll out approved software. Maybe there's a development team or two to develop in-house extensions or software (though always viewed as a cost center).

Therefore, the department the organization's rules are set up to funnel you through is simultaneously incapable of fulfilling this need.

In practice, this leads to a ton of business specialty + devOps types from anyone who can hack Python in order to Get Stuff Done.

(For those of you that don't deal with 1,000+ headcount organizations, be thankful ;) )

I think the big thing at the finance companies I've been at is that corporate IT was created to enable people to use Microsoft Office applications. There is no real provision for how to deal with developers writing code, and forget about hardware.

Exactly, I think the telling question to any corporate IT team (not the head of all corporate IT) should be "When did you last identify, trial, and then make available to users a software package / process / cloud service without first receiving a request from management that you do so?"

In my experience, the answer is usually never.

Corporate IT exists to fulfill requirements from above, not to explore how things can be done better.

Sorry I'm very unfamiliar with this - what about variable annuities requires GPU power?

Variable annuities generally have guarantees, which are essentially just embedded options. To price and analyze these options you have to run large-scale Monte Carlo simulations. Many shops have >100K policies and are running 30 year Monte Carlo projections. You can imagine the computational power required, and the inherent parallelism of the solution.

Can you give more information on this? It actually sounds like an easy problem to solve to me.

Oh sure, it's completely solvable. In fact some companies have solved it, but most lack the expertise. E-mail me (address in profile) if you have any further questions.

why do you guys keep it idle 90% of the time? can't you run more finer grained sims on it all the time, or nearly all the time ?

There's lots of issues here. One is simply that people don't submit jobs during non-working hours, and most jobs don't take more than 4-8 hours, so unless you have a pile-up of jobs during working hours, the grid tends to sit idle overnight and on weekends. Another problem is that you plan your grid capacity for peak periods (and add a margin for future growth), so it will generally be underutilized. Another issue is that corporations create redundant grids for business continuation purposes, so often you'll have full grids that are hardly utilized at all.

Reporting tasks are done no more than monthly. Once the job takes longer, management often moves to quarterly or semi-annually especially if the risks involved in not-knowing are limited.

For many types of information, real-time calculations and dashboarding instead of monthly calculations and powerpointing would be preferable, but the same cultural issues apply. Moving from reporting to dashboarding is disruptive for people and processes. And since big businesses tend to create value for the customer via standardization (up to a point), there is a clear reason for the dislike of disruption too.

Reply on news.ycombinator.com