Legacy technologies in Insuretech and Fintech with Jay Antonio

A lot of software is becoming outdated and heritage systems are posing greater problems for businesses, especially in the finance and insurance sectors. Michał Grela and Jay Antonio discuss the biggest issues associated with old systems and explain why migration to new ones can often cause difficulties.

Our Guests:

Jay Antonio: Founder and CEO of CJ Cube Technologies. Enterprise Architect with more than 20 years of experience in developing software solutions for the insurance industry. Skilled in Business Process Design, IT Strategy, Data Warehousing, Business Intelligence, DevOPs and Application Architecture. Strong engineering professional with a passion for finding the right solution and leading a team to implement it.

Michał Grela is Future Processing’s Relationship Manager, working within the marketing department to establish and nurture relationships with prospective customers and expand the company’s network of contacts. He strongly believes that business is about people and that, at the end of the day, it’s all about Human-to-Human rather than Business-to-Business.

Michał Grela (MG): Hi, my name is Michał Grela, and I would like to welcome you very warmly to yet another episode of our IT Leadership Insights by Future Processing. Today we’re going to talk about legacy systems in the insurance sector. A lot of software is obsolete, and heritage systems are causing more and more trouble for global businesses nowadays. Especially in industries such as finance or insurance. A lot of core applications are still the ones that have been written in COBOL, thirty or forty years ago, and that’s a problem. Nevertheless, it turns out that often this migration into new systems is not that straight-forward. Today my guest is Jay Antonio, founder and CEO of CJ Cube Technologies and an experienced enterprise architect. Working with global insurance players. Very glad to have you here.

Jay Antonio (JA): Thank you for having me, thank you for having me.

MG: Could you tell us more about yourself, please?

JA: Okay, yeah, so I started my career in Asia, in the Philippines, with a global insurer, started as a junior developer. Actually, before that I worked with a bank for a couple of years and then moved to insurance as an engineer. I worked my way up as an architect looking after South East Asian countries. Then my career moved me over to the UK where I looked after UK operations, and now in Ireland where I look after EMEA. Just last year like you said, I started my company. My own venture. Insurance technology is my bread and butter.

MG: Thank you, thank you for this introduction. Let’s dive deep into the topic. I found an interesting quote I’d like to start with. “The legacy systems are fine, as long as insurers are serving legacy customers with legacy products, with legacy processes, through legacy channels”.

JA: That’s very true. Before we bash legacy and the whole insurance sector we need to bear in mind that the industry has been there for so many years. A lot of the companies, almost reaching a hundred years, and if you look at the landscape of any insurer, you will see COBOL, you will see client server applications, you will see software as a service, you’ll see SOA, you’ll see OOP, everything. IT’s like every piece of technology, evolution. It means the industry and insurance companies has been innovating and evolving and disrupting themselves before we were even born. So, if you look at it, they’ve been doing this so many times already. The code, the software were built many years ago for the sole purpose of the business vision back then, which is not applicable now, because it changes. Your customer expectation changes, your business model changes, the value proposition changes all the time, but software is not able to cope up. Although it tried to cope up, it’s not able to cope up that quickly, you know? If you look at legacy systems right now, of course it will mismatch with the business value that you want to achieve.

MG: What you say is definitely true. The systems have been there with us for years, but software budget today is bigger than ever before, yet a vast majority of that spent is still dedicated to just keeping the lights on. Maintaining the status quo. Applications that run the business, and that’s a lot of money, that’s not going into sort of, third-developing or enhancement. So, what’s causing the issue with the legacy?

JA: Well, I think there’s a number of factors there, and it’s a complicated beast to maneuver. A lot of these legacy systems are actually very monolithic, very big.

MG: Well, banks and insurers are monolithic and big.

JA: Right. The enterprise is big, the business is big, but the software that supports them are huge as well, are monolithic as well. And back then they weren’t really designed and built to change, right? They’re not componentized. If you look at the software practices that you see right now it’s like microservices. It’s easy-moving pieces: small, agile and everything. All that good stuff. The software back then wasn’t really designed to be that way. You built software back then: it’s big, and there’s always a mind-set of ‘This should last me forever.’ ‘I don’t want to take care of it.’

MG: ‘If I invest, I invest for good.’

[JA] – Yes, If I invest, I want to invest in others’ big thing. It’s catching up to us, wherein we are now paying the price of that. That’s why we pay for lights on, and it’s difficult to replace that. It’s a big system. For example with a big policy admin system, all convoluted into one system, it’s kind of difficult to say ‘Okay, let me replace that simple piece of component.’ It’s difficult to break that apart and replace with another component. Now we’re kind of paying the price as to why it’s quite understandable that a lot of money goes into lights on. But, you know, there’s always a way on how to do a transition out of that, right? It’s tricky and it depends on the company, and it depends on their situation, on how you want to move away from that.

MG: I really like this comparison of a tanker versus a jet-ski, meaning the huge obsolete heritage system, versus modern, nimble solutions. That’s definitely causing heavy dependency, and a lot of insurance executives are definitely recognizing that they are, well, to some extent lacking behind. What are the biggest problems with legacy software?

JA: I think, based on my experience and what I’ve seen and what I’ve dealt with, the biggest problem is the big systems. It’s difficult to break it apart, and it’s difficult to change them, to enhance them. They’re not able to cope. It’s difficult to break them apart. Given that they’re difficult to change, people and operations do a lot of work-arounds.

MG: Not very effective.

JA: Not very effective. They compromise on data, they treat data differently to what it’s meant for. They use certain fields to capture information because it’s difficult to add in an additional field there. This means that your data is a bit screwed up. There’s a lot of bugs so data is not of good quality and not available.

MG: It’s biased.

JA: I think that’s one big problem. The second is that there is a lot of the innovation that I see is forced to run in sylo. It’s difficult to merge them and integrate them with the legacy core. These new and shiny systems become legacies as well and they rot.

MG: That’s a wasted opportunity.

JA: Exactly. I think if you are maneuvering out of that situation you really need to plan out and think: ‘Okay, what’s my vision for the future? What my business vision is?” Always pair it with your IT vision.

MG: I can really relate to what you said about this people factor with legacy software involved as well. Since it was built plenty of years ago, there’s not many people that know how to deal with it, how to maintain it. That’s the first thing. Another thing is that it definitely backfires because you have to sort of invest a lot of time and effort in training new employees. It definitely affects the company’s perception. You can’t just compare yourself or build any proper competitive advantage if you struggle with a forty-years-old system, versus a young company that’s been using the whole innovative stuff.

JA: Exactly, and not only that. It is even in resourcing, in hiring. It’s like ‘I’m a fresh grad, I’m a really clever IT guy.’ And then, you know, do I go with this company and mend old software? Or do I go to a new company and use new technology and stuff? You’ll always go with the shiniest and brightest thing, you know. So that’s another challenge.

MG: You’ve mentioned data. One thing is to use the opportunity and walk the avenue it opens, but the other thing is the security. From what I’ve seen, the old heritage systems increase the risk of breaches, and vulnerabilities are not that easy to address.

JA: Of course because same with your business vision, your security issues and your threats change, right? There are new threats right now that we didn’t have before. We have a lot of data, we have a lot of information. The risk just becomes bigger and bigger, and changes so rapidly so these old systems are not able to cope up with those threats and security. What’s happening is that you just lock them up and say, you know, ‘I hope no one penetrates this’.

MG: Fingers crossed.

JA: One joke I had before it’s like, uh, ‘It’s okay to penetrate that data because I couldn’t understand it anyway’. So even if someone breaks into that, good luck. If you’re able to understand it, talk to me.

MG: We can do something about the information. Talking about data again it’s like data is becoming so unavailable and unreliable to the point that insurers have a wealth of information that they cannot really capitalize and utilize. There’s a lot of information. If you look at it right, insurance is one of the industries where we give all information, no questions asked. ‘What’s our health record? What’s this? What’s that?’, we just give it to them.

JA: You have to.

MG: Right, you have to, right? So I can get my life insured or my car insured, we give everything to them, right? But despite all of that information, it’s kind of difficult to harness that if it’s unreliable and unavailable. If it’s just stuck in one system, you know? You cannot push it to your data warehouse easily, or you cannot push it to another system to do something about it. That’s a challenge as well. What I’m seeing as well it’s that a lot of the data is becoming proprietary meaning I’ve got a platform, right? I’ve got a policy admin or a claims platform, and the data that’s held within that platform is proprietary to the vendor. So, if you look at it, a lot of applications in the industry are very application centric, not data centric. Let me just explain that a little bit. We dictate our solutions based on the features of the application of what we want to do, right? I think it needs to be more data centric, wherein we let data- we understand the data that we need, we understand how we wheel the data, how we use the data, and then we build applications around that. So data becomes the center of your ecosystem. Your application is like surrounding that, managing that, looking after that, and then doing something about it. Whether it’s analytics, whether it’s processing, whether it’s communicating with your customers, at the center of that will be your information. That is the data centricity. The word in data is your asset. As an insurer I own the data, and applications are just serving that data for me.

MG: So it’s the other way around.

JA: Exactly, the other way around. Having this type of architecture allows you to easily recycle your applications quicker. One problem that we can look at is the reason why it’s difficult to get away of these legacy systems. If I get rid of the legacy system, I’m getting rid of my data as well, because the data is stuck there, right? So I need to do either a data migration to move it to another system, or-

MG: Which is a hassle.

JA: Which is a hassle, right? If I even upgrade one platform to another the higher version of the platform might not recognize that data structure properly. In order for you to upgrade, the upgrading part is easy, you know? But the data migration part is the difficult part because you have to understand the nuances and complexities of this data and the problem it has. Bearing in mind that the system probably has been running for the last twenty years. There’s a lot of patching, there’s a lot of quality issues that you need to understand to bring it to that level.

MG: Definitely. This migration is a hassle and we’re gonna talk about it in a minute, but to sum up this part of the conversation. Legacy has a lot of disadvantages, are just wasting the opportunity, and are just not as effective. And if that does not tell enough then I’ve found that when it comes to the US Federal Government spent on IT 80% is dedicated to just maintenance, and 22% to modernization.

JA: That’s a huge cost factor. I didn’t see those numbers but I would say a lot of companies would be like that.

MG: Similar.

JA: We also need to look at the fact that the reality is when we move to the new stage or evolution of technology, we cannot get rid of legacy systems right away. We need to plan our way, our transition, where new and legacy works together.

MG: That was what I was about to ask you. You’ve already mentioned that there’s several approaches and that there are challenges and obstacles on the way. And I was about to ask you, whether it is better to go for an evolution or rather a revolution?

JA: Well, you know, it depends how you define evolution versus revolution.

MG: So how would you approach?

JA: Well, I would look at is as, again, data centricity versus application centricity. I would go with data centricity. It’s like, prioritize your data, not your application.

MG: Architecture wise.

JA: Architecture wise. Then IT vision. This is like our motto in the old company that I worked with: “IT vision should always be your business vision.” They should always go hand-in-hand. Your IT team needs to understand what the business team needs, and the business team needs to understand what the IT team is going through and work together so that you can achieve that. The third thing is ecosystem versus systems. We need to find a way on how, instead of us building big systems all the time, you know, look at ‘How do I build small solutions?’ And incorporate it in the whole ecosystem.

MG: Environment.

JA: Environment. Sometimes we stop at ‘Okay, I built an application, I’m done. Move onto the next one.’ It’s never done, right? It’s sitting there, it’s doing probably one or two integrations, right? And then you build another system, and then you do this, and before you know it, you have many systems with a web matrix of integrations that you cannot even manage and maintain. And you lose data centricity, because each one of them, hold the same set of information, very redundant and you don’t know which is what. I think we need to start looking at data centricity. We need to start looking at ecosystems, and obviously the business and IT vision, together. I think if we start defining our road-map based on those principals, I think we’ll have a better chance of transitioning, revolutionizing how we do things.

MG: Speaking practically: it’s about preserving and protecting the old system, and at the same time, building something new around it.

JA: Well, it’s more of ‘I have my legacy asset, I have my legacy asset’ and then break it down into, ‘Okay, what is my legacy asset good for? What is my legacy asset good for?’

MG: Assess the current situation.

JA: Asses your assets, I think.

MG: So that would be stage one.

JA: Right, stage one. Access your asset, ‘What do I have there, and what’s working nice, what’s not working nice?’

MG: Where am I at this?

JA: Right. For example, if this big table is serving it’s purpose, I’ll keep this. If it’s not, then I’ll get rid of it. But it’s not that simple, because this big table could have five different things, right? And it’s like identifying which one of the five is good, keep that, and then find a way on how that can work well with other, newer systems.

MG: So prepare a scenario of what’s possible?

JA: What’s possible. It’s like catalog for what do I have, what do I need, what’s my vision, and then how do I approach that. It’s like figuring out, ‘How can all of this inter-operate properly?’

MG: That’s important because what we also have to say that there is some level of disruption, that the enterprise just won’t cope with. You can’t just say ‘I’m doing everything from scratch, starting tomorrow.’

JA: I think if you’re a new company and you don’t have anything there, then yes, you know. It’s a green field, you can do whatever, right? Again, it’s like you’re converting a tanker to a several Jet Ski’s right? If you have independent components and they’re not working well together, that’s gonna be bad for you as well. So you want them, even though they’re individual pieces moving in one direction, right? It’s serving a purpose. That is the whole ecosystem approach. So it’s not a tanker, it’s a going-back-there analogy. It’s a multitude of Jet Ski’s, each one having their role and doing whatever a tanker needs to do, so to serve a purpose and serve your business.

MG: I really liked what you said about being data centric, but what I would also add is being security centric from day one, because with data security, it’s not like you can think about it when the product is done, you have to think about it from the very beginning.

JA: Yeah, exactly. I mean, the way I see security it’s just part of your ‘what do I need to do to deliver this software?’ It’s like, ‘How do I secure data? How do I secure the software? What are the regulations around this?’ It’s just part of your understanding the business, and part of understanding your requirement in building this. I think it goes without saying that you always need to put that in place.

MG: Well that was very informative. I was thinking about trying to wrap it up. Legacy is definitely not an excuse. Another comparison I found, that I really like is that “Unlike wine and friends, software is not getting better with age.”, unfortunately. And the limitations of a heritage system definitely outgrow the usefulness. Let’s agree to some extent: it’s still useful to operate on those Legacy systems. But if you want to be a leader, you have to lead, not follow. And customers, especially young customers in the insurance industry now expect more.

JA: They’re expecting the same experience they’re getting from other industries, you know? Retail and even banking, ‘If they can do that, why can’t my insurer do this?’ The expectation of customers are changing rapidly, and we just need to adopt on that and chase on that.

MG: Modernizing and replacing should be a top priority, but it has to be done right.

JA: Yes. A good road map. It’s different per company. You just need to look at the company, and then you to look at what’s the best way to move forward, and just accepting the fact that Legacy software, in some shape or form, will always be with us. We just need to make sure that it can work well with the new target architecture that we’re envisioning to support your business.

MG: And that’s a good summary, I think. It was very insightful. And thank you, our viewers for watching this, another episode of IT leadership Insights by Future Processing. If you liked it and you found it useful, please don’t hesitate to like it and share it on social media, and please do drop us line if you would like to have a topic covered in one of the other episodes of IT Leadership Insights, thank you very much.

JA: Like it.

MG: Thank you so much.