Tim Veil:

All right. Well, welcome to another edition of Big Ideas in App Architecture. Today, I’m really excited to have Mike Murphy, corporate vice president with New York Life joining the show.

Mike, welcome. You and I talked a little bit on our warm-up or pre-show about the insurance industry, all the interesting challenges that it presents. I want to get into that today and talk to the listeners a little bit about all the things related to technology in insurance. But before we get into that topic, I wanted to give you a chance to introduce yourself. Tell us a little bit about who you are, how you got to be at New York Life, your background. Let’s start there.

Mike Murphy:

Tim, thanks for having me. I’m looking forward to the conversation. For me, personally, I started coding at 13 and I fell in love with technology and wanted to be in software. To me, being in software was the place to be, and that’s where I landed. I worked at very small companies. But at 1997, I did join a company called Beacon. And in life insurance, there is something called policy administration, meaning you have a life insurance policy. It has to be maintained. So Beacon was a life insurance software maker. At that time, it was big iron, mainframes. So they were the disruptor doing a non-mainframe implementation, basically Intel Windows/AX. And so Beacon eventually did become a company called NaviSys, which eventually got bought by Accenture called Accenture Life Insurance Platform in 2006. And from there, eventually I did join a startup in 2013 called FAST. They’re also a life insurance platform provider, which led me over to New York Life in 2019, joining over here. And part of I think the reason why New York Life hired me is they’re looking to upgrade their ecosystem.

Tim Veil:

Now, when you were starting to learn writing software at 13, what system, what tools were you using back then? I remember when my parents gave me my first, I think it was Commodore 64, you’re writing a handful lines of what at the time would’ve been basic or something. I don’t remember what it was, but that opened up my whole world. And then we got an Apple and then there was stuff at school. And I don’t remember all the details, but I remember being absolutely blown away by some of that early stuff. So you don’t meet many people who are like, “Hey, I started 13.”

Mike Murphy:

Yeah, it was exciting because I think it was hard. Everything in technology’s so polished. I just talk to my phone or whatever. But back then, everything was ground up you had to do something with it. So mine was Atari 800. So you were the enemy, the Commodore 64 people, the other side of the fence.

Tim Veil:

Yeah.

Mike Murphy:

And I think part of what helped my journey is that back then, there was these computer shows. You would go in Trenton in New Jersey and they would have these big fairs where they would talk about new technology and stuff. And I also used to go to Bell Labs on Murray Hill even though I was in my teenage years. My father was right up there for an Atari user group. And so I did see things evolving and I felt connected to not using what I have, but where things are moving towards.

Tim Veil:

Those are fascinating times. Things were changing so rapidly. New systems, new things being introduced all the time. I wish I could remember all the stuff I had my hands on at the time. But I think that’s when I really realized this is something I wanted to be doing for the rest of my days.

But let’s shift gears. When you and I talked, and as you just described, you’ve been in the insurance industry for a long time. Now, most people obviously are vaguely familiar with the insurance industry. Everybody probably has insurance of some form. But from a technology perspective, there’s lots of challenges in building the systems that support what I think maybe many people might think is a relatively simple thing. Hey, I sign up for something, it’s there for me when I need it. But you’ve been working in this industry for a long time. And it was really fascinating for you to describe earlier some of the big challenges. So I thought maybe we’d start there. And I don’t know exactly how we jump into the pool, but would love to get your perspective. You’ve been in the industry for a very long time. What’s different about software technology that supports insurance from maybe other things? Or however you want to get started. But your perspective, I thought, was really fascinating.

Mike Murphy:

Sure. As far as for architecture, or I might describe the challenges. When I’m talking about the challenges, really if you’re looking into the architecture part is you’re probably thinking, “Well, how would I solve that problem?” And so really good architecture to me is a combination of operational challenges, technology options, and costs. So information, time, license cost, and then legacy fears. Am I doing something that’s going to fall off to their end?

But in the life industry, you have, I’m not really a life insurance expert so I’ll go quickly over the life insurance portion, but we have different products. Something like a term life, which is basically you buy, say, a policy for 20 years and if you unfortunately pass away, then there’s a payout. But then at the end of 20 years, the policy’s expiring. You can do extend it and stuff, but generally it expires. Then there’s something called whole life which is more of a quasi-investment product where it does cover your policy for the life, but you also have build a cash value. So there’s money that has to be tracked about how the cash really builds up. You can take loans against it and things like that.

Then there’s variable universal life, which is they have actually mutual funds that are underneath the policy. So you could have one mutual fund or 10. So there’s complexity there about what’s the underpinnings of that policy and do you rebalance funds, move things across. Then you have something called annuities, which isn’t life insurance policy, but generally speaking, most life insurance carriers sell annuities. The general point was is that a carrier wants to have a single platform, not 20 platforms, to handle all those different things. And so each one has its own different needs and data needs as well as processing needs. But it gets a little more complicated than that even.

So each policy’s actually a contract. And what I mean by that is it’s a legal contract. So if you signed something in 1980, even though the world’s moved on, the terms and conditions of how that product advances, whether the building cash value or other aspects, that’s a contract. It can’t change. If I want to change my underlying software and say, “Ah, I want to do it differently. It’s easier,” I have to come back to you and somehow get you to re-sign, which you’re not going to do.

So not only do you have these different products, but in each line, say a term life, you have different variations of products, what they’re trying to go after. Maybe there’s some component where it’s cheaper if you’re healthier with some new biotech monitoring device or something along those lines or who knows what they’re coming up with. But not only do you have those different products you sell currently, you have the legacy of all the products you’ve sold and each one has a different computational characteristics. And so one more complicated is maybe you’ll install a thousand policies and it was not a great campaign. But now that’s on the software that has to be maintained even though you may never have a product again that computes quite that like that.

And then for each policy, they actually have rate tables. I’m not going to get into actuarial things, but they have all sorts of things about predicting where we’re going. And then you have different states. New York is very strict with life insurance. They have different rules than, say, many other states. And then another aspect is that when you sell a policy, you usually have a life insurance agent. So they have commissions, but then they have a commission hierarchy. Maybe there’s a company that they work for. They get part of the commission. Maybe two of you work together. Now, you have a three-way split. So just to one more level.

But then for all these different products and all these different variations, all these different states, all these different uniqueness, and you have riders. I think I mentioned before. A rider’s like say an add-on to these products like a long-term care rider. So that makes more complexities. But then once you have a policy in force, you have to have, say, monthly payments or withdrawals, or maybe move the money between funds or calculating those commissions or generate correspondence. Then you have to have detail records for each fund. What’s the actual units? And then you also have to counting for all this stuff that moves around.

And then lastly, most people have life insurance policies for 20 years, maybe 75 years. So you have a history of records that goes back potentially 75 years. Now, you don’t have to legally keep that long. I think it’s only seven or eight years is the legal. But depending behind the carrier, maybe you want to be able to have that historical record so you can work with your customers.

So anyway, the reason why I was trying to bring all this up is I’m just trying to say life insurance, what’s the big deal? Just make the software. But you can see there’s a very complicated ecosystem.

Tim Veil:

Yeah, sounds super easy. No challenges there. Given that challenge and that’s something that’s been around for years, these challenges don’t necessarily predate computers, but they certainly predate maybe the cloud and technologies that we’re used to working with in the last 10 to 15 years. But you said you’d been working in the insurance industry in technology for a while. Have there been systems built to try to standardize this? Are there many players? Are there a handful of players? What’s that ecosystem look like?

Mike Murphy:

There’s a handful of players and they’ve evolved over the years. Back in the day, I would say in the ’60s to ’70s, it’s more IBM or a company called CSC. There are mainframe implementations. And New York Life’s been around for 175 years so we have still some mainframe software at our company. But in the current environment, generally speaking, Accenture life insurance platform which I worked at, FAST which I worked at, and then another, Oracle, are the top three general players. But there are other ones who are close to that. There’s probably a dozen providers. But to give you an idea how many sales in this software industry is in one year, back in 2009 when I was at Accenture, we sold one copy that year. Now, that sounds really bad, but there was only two sold in the United States that year, so we got half the sales. So that’s pretty good now.

Tim Veil:

They’re cleaning up the market.

Mike Murphy:

Right. The point of reason I’m bringing it up is that through economic changes, what you have works, what I have works. So making a change is really when you have the extra funds to invest in to lower your costs and help business get greater speed in the market.

Tim Veil:

Well, and just I want to touch on that one sale or two sales. Obviously Cockroach Labs is in the business of selling a database. If we went back to our leadership and said, “We’re going to make one sale this year,” I think they’d lose their mind. Why is that? I think I can guess reasons why.

Mike Murphy:

Well, 2009 was a little special. It was the aftermath from the 2008 crash. But generally speaking, the reason why I give that number is it’s not worth selling thousands in the industry.

Tim Veil:

Yeah, right.

Mike Murphy:

Yeah. No, I would say that these vendors make money in a combination of the license fees, nowadays SaaS hosting fees, and consulting services. Back to all the complexity, let’s talk about the software or the SaaS or whatever the solution is.

If you have all these different products and you have all these different variations, the old school way back in the ’70s, ’80s is you code it. And as you know from low-code, no-code and these trends is that, well, what happens with code is you have a say an actuary who designs a product who gets a business analyst that goes through 13 steps to the end programmer who writes the line of code and all the way back up again. And it’s not very efficient to implement what the person who actually has the knowledge to get it to work. And so these platforms, at least from the ’90s on, I can’t say before, are more I would say low-code, no-code platforms. Before there was a low-code, no-code, these platforms make low-code, no-code platforms. So for example, if you said, “Well, I have a new policy and I want to give discounts based upon shoe size,” which first off you have to get that past new legal which probably wouldn’t pass, but let’s just go with that.

Tim Veil:

Love those shoe size policies. Love those.

Mike Murphy:

Hey, yeah. Discount if your foot’s bigger, I guess. You would want to add that element to the life insurance policy process, which means you have to have the application entry screen and have it, you have to have the policy viewing, the existing policy viewing it. And you might have to have some rules around, hey, based on a size, we’re going to do some sort of discount. These platforms basically create a low-code, no-code environment that, say, well, you can add a variable and it would automatically appear on those different screens and then it would be something that’s available in their rules engine to pull in for part of a calculation. And the reason why I mentioned this is that means that all that complexity, I’m not saying all, but the majority of the complexity is soft-coded. It’s not hard-coded.

Tim Veil:

Yeah, I can see that or I can imagine that. The users of the systems need the ability to write then and there through an interface design and create policies, approve policies. It can’t go off to some person sitting in a dark room writing the code. I would imagine that makes sense.

Mike Murphy:

Yeah. And also the parts of the tale. Ten years from now, you look back, do you want to have to mine the code to find out what it is or look at the configuration to see what it is?

Tim Veil:

One of the things you said, I’m still going back to this one sale. I don’t know why that struck me. It’s so interesting. But not just about that. What is the implementation time? So hey, I may… And I don’t know if this is even something that would realistically happen, but I want to start a new business. I’m going to go buy this software. How long does something like that take to get set up and running? The example I just gave was like greenfield, but the other part I really want to touch on is the migration or the history of data. These can’t be small endeavors to get these products up and running.

Mike Murphy:

Let’s just quickly just use a different example like, say, property and casualty. You have car insurance. If they decided to do a new software platform, they might say, “As of January 1st, 2024 when policies renewed, we’ll use a new platform.” And then January 1st, 2025, they could show off the old platform because everything would’ve renewed annually. With these life insurance policies, since it could be around for 75 years and you have to keep at least eight years of history, you have to bring that stuff over.

So the typical way, and obviously you can do it 20 different ways, but the typical way is that you pick a new platform, you launch a new product on it, you gain confidence that new product works, and then you start looking at your older implementation saying, “Okay, what pieces may I migrate or convert over?” And the conversion is different strategies and things like that. But this isn’t speaking for my current job, but from previous jobs I was on the vendor side, to do a full migration, you’re talking minimum three if not 10 years-

Tim Veil:

Really?

Mike Murphy:

Really, it… Well, it depends upon-

Tim Veil:

I guess I act shocked, but I really shouldn’t be because these are hugely complex systems as you’ve described. Tons and tons of-

Mike Murphy:

Yeah. Well, part of the challenges is the big bang. Do you just do a mass conversion and bite the bullet or do you say, “We’ll do all the life and then the whole life and then maybe we’ll do the term which has member now funds underneath it.” And so how do you chunk it up and move it over? How do you move it over over time? And then I would say that the vast majority might take three to five years and then 30% left. They just run it off because to convert that last, “Oh, I got three policies on this one product,” to reverse engineer and cover, just run it off.

Tim Veil:

Just forget it. That brings up another… Again, and look, to you and to other listeners who may be more knowledgeable, I apologize if I’m asking really dumb questions. But for these, I don’t want to say legacy, but for these older policies and terms and data, would they have been physical sign documents at one point?

Mike Murphy:

Yes.

Tim Veil:

I guess that could have been. So is this just some kind of like, “Hey, we’re scanning. We’re grabbing the metadata. We’re converting these to digital documents, and then those are stored somewhere plus metadata.” What’s that?

Mike Murphy:

Yeah. Life insurance as a whole, there’s everything you can think of where you store images and things like that. For this specific policy administration system, that’s really more about the actual policies and processing and tracking the data and being able to move money and looking at your treasury to make sure that what you have, you think, on your books is actually what’s in the bank account, and doing all that chewing up of the data. But I’m going to just push it back a little bit to the policy admin portion just for a moment.

For the policy administration stuff, even though say you had 5 million policies on one of these platforms. If you look at what’s the next level challenge, there’s two. There’s the users, which is basically your service people, usually not the public, and the concurrencies. So you might have say end of month where there’s people doing a lot of sales and so there’s a lot of online users. Remember, all the work they’re doing is soft code. It’s no-code, low-code. So that processing and rules processing and taking the data in is a challenge.

The other challenge is actually processing the data. At the end of every quarter, there typically tends to be, for legacy reasons, a peak of processing on the 1st or the 15th because the older systems, the mainframe days, a lot of places, they only took payments on the 1st and the 15th. Obviously, spreading across 30 days is way better, but you have to deal with the hand, the cards you’re dealt. So if you have 5 million policies, you may have 2 1/2 million policies that you have to process on the 1st of the month or more. And then to make it more complicated is in order to make your buy sales for the stock market, especially if it’s underlying funds, you have to have that into your banking system typically by midnight. So then that’s a hard stop because otherwise, you have a gain loss next day that you have to eat.

And then on the other side, well, when do you stop taking things? Well, California likes to do business up to 5:00. So now, you’re talking, what, 8:00 at night? You can start your jobs and then you need some inputs, like, say fund values and things. So typically, you only have 9:00 to midnight to process everything. And so if you have these peak needs, and the last thing with that quarter end, the reason why I picked that quarter end is the federal government has rules. Well, you have to evaluate all your policies, not just the 2 1/2, the 5 million, to see what the policy values are, what your reserves are to make sure you’re in compliance. So during that quarter end, you have to process all those transactions, which generates all those detail records and the accounting records and the correspondence and all that stuff. Remember, each one might have, if it’s got variable funds underneath, it might have one to a dozen funds underneath it. I’ve seen one client that had a thousand individual pieces of money attached to one transaction. It was the craziest thing ever.

But the jump point is that when we go back to architecture, to process all that work in a timely fashion and scale up, for me the changes from 1997 to now have primarily been driven by just the infrastructure availability. So obviously, SSD was a game changer back in the day and then cloud’s another game changer.

Tim Veil:

All right, I’m very curious about it. And I don’t know what you can share or can’t share, so you’ll guide me here. But I am curious what kinds of systems, when you say doing you got to run this stuff over a course of three to four hours, what is the technology here, broadly speaking? What is being used to do this calculation, to do all this processing? I was in the big data space for a long time, Hadoop, obviously. I’m in a relational database company now. But give me a sense of what we’re talking about here. I’m very curious about this.

Mike Murphy:

Well, it depends upon when you bought your system. That’s another reason to move up. If you bought your system in the ’60s or ’70s, you’re on the mainframe and that’s how you do it. I would say for current, if we’re buying a new product, it depends upon the vendor. It typically is a cloud database. I don’t know if anyone use Cockroach Labs, but typically the cloud-

Tim Veil:

We’ll change that. Don’t worry.

Mike Murphy:

Yes, definitely. I agree. I learned a lot listening to Peter, Matt Madness the other day. So it’s good stuff.

Tim Veil:

Good. I love that.

Mike Murphy:

But they typically use a cloud database and they’re trying to get to a horizontal scaling model. There’s a whole bunch of problems around that too. But they’re trying to get horizontal scaling model on the database side. And then on the other side, you have, again back to good architecture, you want to have quasi component-based, meaning you don’t want to get down to microservices but you don’t want to get down to say you have a policy processing core, but then you might have another one that’s a commission computational core. So you break it up into modules. Because for example, for New York Life, if we bought a new system, we may not use the commission module that comes with it. We might want to use something else. So you break into pieces that might be replaceable and then use kubernetes and virtualization to scale it up. And so what you want to do is just basically overwhelm your problem with hardware and scaling. And so there’s only so much tuning can do where the only way to get past this problem is just to scale your way out of it.

Tim Veil:

Yeah, that’s interesting. You mentioned SSDs, so I imagine at least at some level this is disk or IO bound. There’s a lot of… Kubernetes is interesting. I guess that makes a lot of sense because you basically scale, create auto-scaling policies for some module. And if it can get through with what it has, great. If not, it bumps up. You mentioned though that it’s been, and again, you tell me how much of this you’re comfortable going into or can’t go into. But what would be some of the challenges of making this technology or this processing more horizontally scalable than it is today? Do you seem to allude that it’s not as easy as it might look. And it isn’t. And I don’t think that’s unique to the insurance business. Building applications and architectures that can take advantage of horizontal scale is not necessarily for the faint of heart. I’m just curious what, if anything, you were thinking about there.

Mike Murphy:

To me, there’s two main, I would say, choke points. One is the whole thing is soft-coded. So how big is the container that you need to process? Maybe the rules are on XML. Who knows what they’d selected for doing that kind of work? Maybe they compile the logic into a byte code and use that which is more efficient. So you have that, what’s your processing engine? How big a footprint is and how many threads and how much concurrency you can do there? Which includes cashing and data and all the things you would think of with a soft-coded system. But then the other end is the database. And for the database, from my experience, the main problem was up until eight years ago or so was that we used, as not just in life insurance but I think everywhere, sequential IDs. And so the problem with sequential IDs is that-

Tim Veil:

Yes, I like this.

Mike Murphy:

… if you’re on the end of the tail and you have your 1 millionth policy or whatever, chances are the highest level of activity’s going to be the last hundred thousand policies because that’s the stuff where there’s a lot more change. And then making things worse, every transaction, header record, detail record, counting records, with all these sequential IDs, you’re basically they have a large database, you’re focusing on as much as possible a hot spot as you can. And so GOODs were an insane game changer for me. In a previous life, I was tuning and re-architecting and scaling a platform and they were using GOODs. And at one point, I noticed that as a database got bigger, things processed faster. And I’m like, “That’s not possible.” My entire life has been more data equals more challenges. I got more data then I went faster. And then I realized that, well, because everything was GOOD-based, that the distribution on the disk was disseminated and the contention was going down.

Tim Veil:

Yeah. I’m so glad you mentioned it because it actually really is. I think it’s one of the biggest hurdles that people who are using distributed technologies or distributed databases, more specifically, face right out of the gate. Because so many applications, you’re right, are these increasing integers or longs, just 1, 2, 3, all the way up. And you’re absolutely right. And what’s so fascinating about that specifically with the insurance business is you’re right, it’s that tail end. It’s those high numbers. It’s the last in that’s probably the most active. And you can get terrible hotspoting. You’ve got this huge cluster of distributed compute and storage power, but all of your energy is focused on a handful of nodes because that’s where those keys are landing.

And so I know with Cockroach, and this is true, I think of most distributed systems and certainly distributed databases, is distributing those keys in an effective manner so that every node can be tackling this problem, not just a small handful, is a huge issue. We’ve spent countless hours, years in fact, improving not just how we distribute data, but observability in that. So that you as an operator or developer can look and see, “Oh geez, I am overwhelming a node or an arc parlance, a range.” It’s super important. So I’m really glad you mentioned it and I’m glad others are feeling this pain because it is. And GOODs are certainly one way to get out of that box. There are other things you can do, of course, but that’s interesting.

Mike Murphy:

GUIs only half the story. Expect your horizontal scaling with, say, Cockroach is you need to change the software to look at how you process and create a common key that enables the distribution of the unit of work. And so in life insurance, it’s a policy and so you’d want to have the policy number on the transaction header records, the transaction detail records, and even down to potentially your others, records like accounting records, simply so that when you send that unit work, say, process this policy, that node is responsible for all the IO and eliminates the cross chatter that you would have.

So back to good architecture at the whole point of this podcast, it is really-

Tim Veil:

That’s right.

Mike Murphy:

You’re trying to take a look at what the tools are available for you today, because I would answer differently 10 years ago and then differently again 10 years before that. But you’re looking at what’s available today and saying, “Okay, what is something that is maintainable? Now, this can’t be too complicated. Cost-effective? I can’t be paying high license costs. And is, I don’t want to say the word elegant, but gets to the point of what is the solution?” And so I think with scaling databases like with Cockroach Labs, it’s not just having their architecture in place but modifying your software to take advantage of that.

Tim Veil:

Well, this is a conversation we often get into with folks and I’m curious what your perspective on this. So if you could design the perfect system that did all the processing in an hour or 50 minutes, what does that mean to a company like New York Life or to anybody in this business? Does that save you money? Does that increase customer? What’s the benefit to solving this problem? Because I think over time, as you rightly said, everybody’s going to get better at this. This is a process that will happen more and more quickly as technology improves. But what does that mean? What does that mean to the business, if anything?

Mike Murphy:

Well, let’s talk about cost, because cost, again, cloud was a game changer. So let’s just say you had a server and it takes 10 hours to process. Or I have 10 servers, I process one hour. What’s the cost difference? There’s none. You’re paying for 10 hours of compute. So if you horizontally scale, your costs are net neutral. Now, there might be some lie to that, like 10%, but it’s from the ballpark net neutral.

Now, the benefit of doing one hour versus, say, three hours is things do fail. And we talked about the banking needs at midnight. Their time doesn’t change. It’s like, “Ah, we have problems. Can you process our buy sales the next morning starting at 3:00 AM?” You missed a window, it’s on you. So if you could do it in one hour instead of three hours and you have an issue, now you have two hours to recover. So the horizontal scale, least for batch, user is a little bit different but for batch, the benefit is that the cost should be ideally net neutral and you gain, I would say a higher, more time to recover from problems.

Tim Veil:

Interesting. And I do wonder if it in fact is net neutral? And just anecdotally, some of the things that we’ve seen, and again, this may not at all apply to this industry, but in these horizontally scalable systems, they become almost prohibitively expensive by you just max out on disk or you max out on CPU. There just isn’t more you can put in that single box kind of thing. And what we’ve seen with Cockroach, at least in many instances, is you can fan out much, much cheaper individual instances.

Mike Murphy:

Well, that’s horizontally, not vertical. Vertical is too big. So this is horizontal. You want basically a small, computational, say four cores or whatever, and then scale out a hundred servers if you had to.

Tim Veil:

Exactly. Instead of one giant one, small, much of small cheaper ones to so that single-

Mike Murphy:

And that was the cloud. You could horizontally scale to meet your demands versus the vertical. Back in the day, you had to do vertical database. I could horizontally scale the compute for a long time with VMware and other things, but my database was a monolith and that was only vertical. So if I wanted to go faster, I had to stop everything, restart the thing just to get faster.

Tim Veil:

And how often, and again, are these things, these jobs failing pretty regularly? Or is that just more of an insurance policy on the processing of insurance policies that if we need it, we can?

Mike Murphy:

It’s not frequent typically historically, but we are moving to a SaaS model. And as you know, change is coming quicker and quicker and quicker. The balancing act is if you just happen to have a bad night and the market dislocates the next morning, then I guess it’s on you to pay that difference. So if you just have bad timing, nobody’s going to say, “Oh well, things happen.” People are going to be furious. They want perfection. So even it’s not frequent, you just want to not take on that risk.

Tim Veil:

And I’m curious too because you mentioned it. We’ve been talking mostly on the batch side, but there is a client, a customer angle to all of this. And I would imagine the use. This is true for me personally. Instead of calling up my agent every time I had a question or wanted to check on something and talking to his admin and talking to him, and I’m doing it all on my app now. There has to be a whole experience and set of architectural concerns on that side as well, doesn’t there?

Mike Murphy:

Yeah. The biggest change for me when I moved from the vendor side to working at New York Life is that I had one product that did a set of things. Now, you’re getting into you need a hundred different products to do all the things. And so the policy admin we’ve been focused on won’t typically be that touchpoint for the customer. It’s the backend work. And then you do have to have your own application or web app where they can do that kind of work. And I think that where companies invest in this insurance is basically a reflection of maybe their customer base or where they’re trying to grow into, what is important to your customer.

Agents need the best tools possible to help service their customer. So not that we don’t have an app or web app presence, we do, but the focus is more of empowering the agent to be your partner in investing and coverage and what’s going on in your life. Maybe you don’t realize you could take a loan against your policy and then that person hears from me and say, “You need? Oh by the way, did you know take a loan out of your policy?” “Oh, I didn’t know that.” So having those agents work with you, and then that’s where we focus on. But there is a whole… There’s correspondence. There’s self-service too. There are competitors out there who just direct to the market. They really don’t have agents. So those competitors really are focusing on maybe the customer experience to the highest degree, but then they’re relying upon you as a customer choosing them because they don’t have anybody who’s advising you.

Tim Veil:

And of course, again, just because we focus so much on resilience and all those stories, if I’m an agent sitting down across the desk from a prospect and I go to log into the system to create or sell a policy and I can’t get to my systems to do that, there’s challenges there.

Well, this is interesting. It’s so funny how complex systems are under the surface. I think that’s one of the most interesting things about, not only being in this industry but doing this podcast is you get to learn about so many interesting things. We’ve talked a lot about what has been and what is. And again, I ask the questions. You don’t have to answer them or you may not know. But you know what’s on the horizon? A day doesn’t go by that I don’t hear about ChatGPT in large language models and there’s all that. I’m just curious. From your seat, what are some of those things that are potentially on the horizon that will be another big paradigm shift in how the insurance technology business works?

Mike Murphy:

There’s two different lenses. One is insurance as a whole, and I’m going to pull it back a little bit to the policy admin just because that’s where my specialty is, is that now we do have legacy systems everywhere. And part of the problem we have with the migration we talked about is understanding what you have. It’s how do you re-implement the processing rules in a manner that’s compatible to what you have today? If you have assembly, you have to spend quite a bit of hours to reverse engineer and figure out what you’re doing today.

So I’m hoping with AI, they’re going to come up with something that says, “Look, we can read your old code and we’ll convert it into something more elegant in a new language or just some rules and a rules engine,” or something like that. And the rate of change can be accelerated dramatically in this industry because we can move off of old to new simply by using an AI that gets you 95% there and 5% error rate and you can figure that out and you can actually move forward quicker.

That also leads into even just product development, big data, looking at your data that you have. These insurance carriers have millions of customers, and is there a way we can gleam information out of, say, social media or some other information out there to help us be more effective at what we do? So I do think there’s a lot of different angles that way. But from a company as a whole for AI, right now looking at things like claims or fraud, you can use AI to detect that. But as an architect in New York Life, I look at all this as what is less about the architecture? What is the capabilities that you can buy as a SaaS that is driven with that good architecture to service you, to be able to advance forward and while we focus on our core, which is serving the insurance customer?

Tim Veil:

Yeah, it’s really fascinating. One thing you touched on which I’m curious about is assembly, for example. Has this been a challenge? I feel like I’ve talked to others, not necessarily in the podcast, but just out in regular work where finding talent to read and maintain some of these legacy systems is a challenge. Is that something that is true in the insurance industry given some of the…

Mike Murphy:

It’s not limited to insurance. Assembly, the challenge of assembly to me is multifold. One is just getting talent who wants to really dedicate themselves to assembly that is on the younger age. But the other is really, there’s a lot of complexity. Think about it. If you have assembly that’s been created over 40 years, how long will it take for you to actually get good understanding of that ecosystem? 5 years? 10 years? It’s not going to take six months. And so it’s the same as you’re just getting people, but getting people up to speed. And so realistically, if you look at no-code, low-code, why are we doing that? Because we don’t even want to have any code, much less assembly. And so really we’re trying to…

I want to take a step back, really a step back here. If you look at technology as a whole, what have we done? We’ve taken complicated work and made it super simple. So if you look at, say, back in the seventies, you call up your phone company, “Hey, I have a problem with my bill.” Think what that person did. “Hey Tim, can I have your phone number? Okay, can you hold on one minute?” Person runs down to the filing cabinet room, pulls out the file, runs back and says, “Oh, I have all your bills. Which day?” “Oh, this day.” “Now, let me go to that. Let me get my calculator out. Where do you think error is?” Start calculating it out. Once you get an agreement, the customer with the problem is then you write out a memo, you put it in your desk. So somebody could run around, pick that up, run it down to somebody. Think about all the mental work that that person who answered your phone call and coordination with others had to do.

Now, what do you do? You call up and say, “Yeah, I see a credit.” 5 cents done. So what we’ve done outside of IT, we’re now trying to do inside of IT. So I look at low-code, no-code as saying the same exact thing. Do I need to have all these complicated resources to achieve my business goal or can I back out of that and make it low-code, no-code? So back to your assembly thing, it’s just diametrically opposite of where we’re going. We’re trying to make it so that if you are the knowledge person, you know how to create a life insurance product, you should have hands on keyboard an easy way to do that and not have to go through 13 layers and have the assembly made. Does that make sense?

Tim Veil:

No, it makes perfect sense. And I think I was just going to say earlier that, I’m a Java developer and write a lot of code. There’s code I’ve written six months ago that I don’t understand and I wrote it. So yeah, reading someone’s assembly code that’s been built up over 40 years is a painful task. And it’s actually, it’s not something I had thought of. But there’ll be lots of things I haven’t thought of when it comes to AI. But I think it’s a terribly fascinating idea because again, and it’s not just insurance-related. There’s so many industries and companies that are having to wrangle with or deal with this very, very legacy technology and there just aren’t people around that can or want to do the work to convert it. And if you could train AI to, like you said, just get it 95% of the way there, think about what that could do and open up for some of these businesses that require or have relied on very, very older legacy technology for so long. It’d be amazing. Huge game changer.

Mike Murphy:

And it doesn’t have to be assembly. All older languages. It could be even a modern language that you want to soft code into a rules engine.

Tim Veil:

Yeah. No, I totally agree. Yeah, it’s very, very fascinating. Well, as we’re wrapping up, any final thoughts, things that we didn’t cover that we should have? Any last words of wisdom that you wanted to share?

Mike Murphy:

As architects or people designing things, it isn’t necessarily just about providing a good solution. It’s also about a company backing up with a great cadence. So you can have the most elegant solution that just doesn’t work because you don’t have that unbelievable discipline to every step of the way automate and implement in best of breed manner. And so I think there’s a culmination of good architecture and excellent operational practices that have to come together to make a great company. And so just creating the one without the other just doesn’t work. You need to have both.

Tim Veil:

Well, Mike, I think we’ll leave it there. I think that’s a great way to close the podcast. Again, thank you so much for joining us here on Big Ideas in App Architecture. It was a fascinating conversation. Learned about an industry I knew very, very little about. So thank you again.

Mike Murphy:

I’m glad to hear life insurance is that interesting to you.

Tim Veil:

It is.