Breaking free from legacy systems: advancing banking through core modernization

DM: Welcome everybody to the Zafin Innovation Beyond the Core podcast.

This week, I have a very special guest, Shahir Daya, who is the CTO of Zafin.

Shahir, would you like to give our audience a little bit of background on yourself so they get to know you a bit before we get into the topic of legacy modernization?

SD: Yeah.Thank you so much, Dharmesh.My name is Shahir Daya and I’m the CTO of Zafin. I’ve been with Zafin for just over 11 months.

Prior to Zafin, I spent 27 years at IBM. I was an IBM Distinguished Engineer and the CTO for the financial services consulting business and have gone through several waves of technology, everything from developing mainframe software to client server to cloud and decided to join Zafin at the beginning of this year.

DM: Fantastic.

I mean, you have a career very similar to mine. I started off on the mainframes, but you look way younger than myself, so that’s fantastic.
I’d just like to understand a little bit more about your background because it’s fascinating that you spent 27 years at IBM. What drew you to Zafin?

SD: Yeah, that’s a good question. A couple of things. My IBM career was very focused on consulting client after client. And I did spend most of my time in the financial services sector and a lot of my time at banks doing modernization, and I wanted to try out working with product, building a product and Zafin had the perfect product, cloud-native, SaaS, in the financial services space, great company, great vision, and the timing was just right for modernization, core modernization and Zafin’s point of view around core modernization was in line with what my thinking was and it was a perfect fit.

DM: Fantastic, fantastic.

I mean look we know the topic of this conversation is legacy modernization, but I want you to break that down into 2 halves.

Firstly, for the general audience that isn’t technical, maybe just define what you mean by legacy. What’s a legacy system?

SD: Yeah, so Dharmesh, that’s a very good question because people usually attribute legacy to mainframe and that’s not correct because the mainframes are extremely modern. The technology within mainframes is state-of-the-art and what those mainframes can do is just unbelievable. So the legacy part is nothing to do with the fact that it is running on the mainframe. It’s actually to do with the software itself, right? And if you think about it, I’ve dealt with core systems that are literally 4 decades old, right? And they were built 4 decades ago using architectural styles and patterns that were very popular 4 decades ago. And those things have changed. Programming languages have evolved and using the right language for the right task at hand and so on. And if you think about having a core system, every time the business needs something, you look at it and you’re like, OK, I’m going to make the change in the core. So you continuously make changes in the core, normal adaptive maintenance, new feature request fixes, you keep evolving and changing the core. And it gathered so much technical debt over the decades and to the point where now it’s a drag to make changes. So old architectural styles, old programming paradigms, scarcity of skills, all of those things make these cores legacy.

DM: Fantastic. So let’s get on to the meat of the topic then.

I’ve been in a core banking software company and we sell core banking software.

So literally we’re telling people you need to replace your core. But recently I’ve been hearing, not only from you guys but other players as well about this kind of terminology.

‘Well, look, changing your core is a bit like changing the engine of a plane while it’s still flying’ or other analogies like, ‘It’s like having open heart surgery while the patient’s still awake’. It’s so risky, it’s dangerous, right.

But newer players are now and Zafin are promoting this concept of modernization.

So what does that mean, versus rip and replace of your core, right, right.

SD: So they’re actually right.

I mean core replacement, ripping and replacing: very high risk. I don’t, I don’t think you’ve seen anyone do it successfully without actual problems, right?

It is one of the big challenges with a core replacement is all around feature and function parity.

How do you achieve that before you can cut clients over? And core modernization, if you look at what comprises a core, it’s really three big boxes, right?

There’s the ledger, the subledger, there’s product and everything that comes with product, things like pricing, fees, rates, suitability, eligibility rules and so on.

And then there’s the customer master, right?

And if you think about the challenges and Dave spoke about these challenges right around Agility. If you think about the challenges we are trying to address and all the banks are trying to address, trying to become more agile and we know the legacy core is not agile. It’s very cumbersome, very difficult to make changes because of the regression testing and the languages and the architectural paradigm and so on.

So “hollowing it out” or you’ve heard the words “hollow out”.

You’ve probably heard “strangler”, “the strangler pattern”, “strangling the core”.

There’s many ways of terming it, but pulling these big capabilities out, if you pull the product catalog out or you pull the whole rates and fees out or you pull the customer master out and pull them out and go towards a more modern solution, you start becoming more agile in those areas.

So, if product pricing is an issue, pull out the product catalogue, pull out the capability to a more modern stack.

DM: Yeah, yeah, yeah, I get this.

So it’s a bit like, one of the challenges of the legacy cores that depending on the vendor, but the older the vendor, the more components that they actually have, which is great if you’re a small bank, you can get everything out of one box, but it means that you’re like a Jack of all trades and a master of none.

SD: Yes.

DM: Like you know that you’ve got everything there, but it’s not the best of one thing, it’s not the best credit risk module or the best customer management module or the best ledger.

It’s everything but not the best individual pieces.

And what you’re saying is that you can take out individual pieces and then replace them with something that’s much better. Is that right?

SD: You’re absolutely right. You hit the nail on the head.

That is the exact strategy: let the core be what the core was meant to be, which was the ledger and use best of class, best of breed products for all of the other components and stitch them together in a very tightly integrated way.

DM: Fantastic. And this sounds great, right? Because it means that I’m not doing a big rip and replace exercise, which is fraught with danger, right?

But I’m just going to take a small part of this and now pass that capability somewhere else.

Is that easy to do?

SD: It’s not easy. Nothing in that space is easy to do. But it is a lot easier than trying core replacement.

The risks are minimized and the way you do it.

And because you know the technology has evolved so much that you can achieve coexistence and so on right. So as an example, pulling product and pricing out of the product catalogue out of a legacy core is not that difficult because once you pull out the product and pricing and now you’ve got a modern solution for product and pricing, you’ve got modern APIs and so on.

There are techniques that you can use like bridging the API calls from the legacy to the more modern one and that minimizes the amount of changes that you have to do on the bank side, right? Because the bridge is providing an API that’s exactly what you have today and it’s doing the necessary translation to the more modern one.

And these are temporary solutions.

It’s a transitional state architecture as they actually start modernizing and moving the APIs to move to the modern stack and so on. So there’s techniques like those that really help with minimizing risk and accelerating the timeline.

DM: Oh, that’s fantastic. I mean, what amazes me. The product catalog is such a good example because no bank has a single core anyway. Typically a bank has a different core for its accounts and loans versus it’s mortgages versus credit cards.

You know, there’s three there anyway, right?

And so you know, in the old world each one of those cores would have its own catalogue and now you’ve got 3 catalogues now rather than 1.

So it’s no wonder that we had this problem with the single customer view.

But externalizing it makes it much more sensible because you’ve now got the single customer view and you’ve got one way of defining the products rather than three different ways and you can do it in one system.

So I can, I can see lots of benefits here.

So if a bank wants to do modernization, like how do they start, what are the things that they have to consider before they get engaged in a project like this?

SD: Right. So I think just modernization programs are massive and everybody knows how risky they are. So proper planning on their side is extremely important. And what are the actual pain points we’re trying to address?

It’s very important to understand what are the pain points the bank has that we are actually trying to address. And the other piece of advice is start small, pick an actual use case and go using a vertical slice approach, right. So don’t do anything that’s going to be horizontal.

Always do something vertical that touches the clients because you want to deliver client value, business value incrementally, and that is one of the most important things in a core modernization point of view is yes, we want to modernize the core, but we don’t want to put a pause on innovation and tell the business,

“You know folks, you need to hold on for a while we modernize or get to a new core and that’s going to take us 2-3 years and don’t do anything innovative until the” — that doesn’t work. We need to incrementally deliver value.

So picking vertical slices that have incremental business value is the approach.

DM: And just for my benefit because I should know this I guess, But can you give an example of like a vertical slice? What do you mean?

SD: Absolutely. I’ll give you an example of a vertical slice.

So when you look at the business capability at the top and you look at the technical stack that it needs to call, typically you’ll have a user experience, you’ll have layers of APIs, you’ll have a system or record and so on. I’ve seen banks think that we’re going to build this layer of enterprise APIs and focus horizontally and we’ll build all these APIs and we’ll build them and they will come.

And I find that in some cases, yes, that works.

But in many cases, you’re spending so much time building this horizontal layer of enterprise APIs that you are not delivering business value at the same time. So if you do a vertical slice, you only build the pieces that you need to deliver that vertical slice in the business value associated with that vertical slice.

And you go vertical slice after vertical slice and your horizontal starts to take shape and get filled out.

DM: Right. I mean that makes a lot of sense to me.

Clearly, it’s like if there was a big cake that was the bank.

I’m just taking a slice all the way through and then at some point I finished the cake. So absolutely, and you know I’m a foodie so I had to get a food analogy in there somewhere.

So in terms of pros and cons, I mean it I can see the some of the pros, right?

For example, because you’re taking a vertical slice, you’re going through the entire software stack but not the full breadth of its capability.

So you’re containing its scope but still addressing all the layers. So I can see that lower risk than trying to do an entire horizontal thing like you mentioned about the APIs.

Are there any other positives around the modernization?

So it’s lower risk which means that it can be done quicker, right, with less manpower, What else?

SD: Yeah, it basically risk and incremental value are the key things, right. And incremental value is so important, you want to get the business excited early on as you go on.

And there’s so many strategies that I’ve got when you’re getting the product for a catalog up, for example, you don’t have to move control of all products to whatever new software immediately, right? You can deposit products and checking products and so on.

And like you said, there’s multiple cores, right?

Yes, deposits, credit cards.

And you want to externalize products from all cores to the same place because of the value you spoke about, right?

The whole being able to have the 360° view of the customer, all of the agreements they have with the bank, right.

So there’s just so many advantages, so many ways to do it.

And if you, if you think about it, integration and orchestration becomes the single most important thing, being able to integrate and to be able to then integrate incrementally so that I’m only concerned about this one thing.

Everything else remains the same and I want to be able to keep switching things on as we progress in our modernization journey and orchestrating across the different cores.

We know we are a multicore, we’re going to be in a multicore situation.

So orchestrating across the cores is very important as well.

But risk and incremental value are two of the biggest things that we need to focus on.

DM: Yeah. I love that incremental value thing because when I think about kind of core replacement, I just think risk, risk, risk cost, cost, cost, cost, it’s going to take a huge amount of time and several years later I’m going to get a brand new system that allows me to launch products quicker, etcetera, right, blah, blah, blah.

But it’s well at that time I’m thinking it’s like so much time before I’ve got any value back.

But this thing about giving a little bit of value quickly and often and repeatedly, I love that concept.

I mean, clearly, you’re coming from the consulting background, so you kind of get that very well.

So I love that. OK.

So, I know you want to pitch that “modernization is the way forward”, but are there any downsides to modernizations that you can think of?

SD: There has to be a reason why you’re doing it right?

You don’t want to modernize for the sake of modernizing, just because everybody else is doing it.

You know the pain points on agility are important.

If you don’t have the luxury of going with a new core that’s modern and cloud native and all of those things, again, you are going to modernize from certain standpoint because like you said the core you know they want to focus on everything, they want like a bank in a box, but they’re not going to be good and deep at everything.

You know they need to focus on the ledger and they have to be great at the ledger and leave product pricing, customer master, leave those things to others that are focused on those specific components, right?

So you can expect to see a modern cloud native core that’s built recently that’s still leveraging another component for a customer master, another component for product and pricing and so on.

And it’s focused on the ledger, right. So I see modernization happening whether it’s a legacy core or some of the newer cores. You may not specifically call it modernization because what are you modernizing, right.

But you see the idea of externalizing and using best of breed products and stitching them together to achieve what you need to achieve.

DM: Yeah, I mean I think again, I still love this point about the incremental value because I can see that one of the downsides could be that the overall replacement of a core might take longer because you’re actually releasing on a bit by bit basis, right?

I don’t know if that is the case, would it take longer or could it be quicker? Because obviously one’s a deeply complex project and you’re trying to eat this elephant in one bite whereas the other you’re trying to chop it up into smaller pieces and that’s even more manageable.

But would it take longer or not. I mean what’s your experience?

SD: The thing is if I saw one that actually was successful, I could tell you if it would be longer or not.

It’s very difficult to guess at that. You know trying to eat the whole elephant in one shot is very problematic. You know and there’s different banks have done different things, right.

We’ve got banks that have a legacy core and they stand up a more modern core and they try to coexist them. Coexistence, but having a solid coexistence layer and then you know introducing new products on the new core and then having an experience that’s stitched together.

So I could have products in the old core and the new core, but completely different products, not migrating the products over and that’s a start to try to get value quickly.

But you know, you have to ask the questions is that the right approach for a particular bank and there’s no one-size-fits-all right. Different banks are in very different situations.

DM: Yeah, definitely, I mean what you said about standing up another core alongside your existing, you know, my experience has just taken too long before the old core actually made, got made redundant at some point.

You might as well have migrated the whole lot because it’s been there. It just ends up being another core as opposed to a journey to replace one in its entirety. So I think you’re right on the, standing up one.

But another one that I’ve seen also is where they literally create a new bank, under a new brand typically called the Speedboat strategy, let’s create this brand-new organization and let the customers migrate to the new brand.

I mean again, I’ve seen that you know being done.

I haven’t seen, have I seen any of that as successful, maybe one that’s been successful but not too often. And again typically the new brand has kind of come out, it’s on a modern new platform is able to innovate, but it just didn’t get the customer traction and they didn’t launch enough products soon enough, right.

So it it’s a difficult one, that one as well, right?

SD: Yeah. And that’s the, that’s one of the advantages of the legacy bank, right.

The legacy bank has the accounts, right.

They’ve got the balance sheet, they’re the ones that if they can just innovate fast enough in terms of product and propositions to the clients, they can grow those accounts significantly, right, and attract new clients, right.

So you know the hollow out strategy hollowing that core out and pulling product catalog and customer master, pulling those things out and making them more agile so that you can actually innovate faster in my opinion is a better strategy.

DM: So, so you’re advocating basically that don’t ‘replace the core, build around it with better capabilities.’

And typically you want to innovate around the customer experience, manage the customer separately.

You want to innovate with new financial products, manage the product management separately to the core and maybe just leave the core to the ledger, right.

SD: Yeah, absolutely.

DM: Wow, fantastic.

SD: You can introduce a new core at the same time and just as long as the product catalogue and the customer master are shared across the two cores, you could achieve that as well.

DM: OK. So, all right let’s say that I’m like a bank that has successfully put in a brand new core banking system, it’s cloud native, it’s got micro services, I can do daily releases, it’s got APIs, etcetera, etcetera.

So I’ve got this new core.

Would I benefit from modernization as well or would you say that it’s a job done?

SD: You know if it truly is as you explained it is, then I don’t see what you would be modernizing,

DM: I mean I’ve seen one of those.

SD: I’m curious to see it myself, right?

DM: I think you have to explain what the problem is and if you may, I’m going to, I’m going to answer that one for you because I know where you’re coming from which is basically no bank has achieved putting all of their products onto a single core. So typically, they’re in a multi core scenario and they may have replaced one, but they still got the others to go right?

SD: Absolutely.

DM: OK. So what’s the problem with that?

So let’s say they’ve got a brand new core and when they want to do some new products, yes, they have to run some legacy products.

What’s the problem with that? I mean is there an opportunity for modernization on that?

SD: Yeah, there is.

Absolutely there is, right. And you know if I look at product and pricing and all of the different capabilities, when I was in consulting and when I think about banks or when we think about banks, are we all bank, right?

We think about banks and you think, “Oh it’s a product, it’s a checking product, OK”.

“These are the fees I pay, these are the different ways I can avoid the fees, What’s so complicated?”

And then when you look at Zafin and how we do product and pricing and what’s involved and monitoring behaviour and it is complicated, it’s very complicated, it’s not straightforward, right.

So a new core, a new more modern core that might come out that might have a product catalogue and have product and pricing to match some of the capabilities that banks expect today?

You know I’d be very surprised if anyone could come up with that you know right out of the gap with a new core.

So for some of those capabilities that you just don’t exist in in in cores or that a new core may not have you know your best option is to externalize it to a best of breed product.

And when you think about this idea of a lot of banks are doing this right? They’re externalizing everything and picking best of breed products for all of the moving pieces because it’s a better strategy.

And they’re abstracting them away so that if later on they decide “Hey, what I picked for, anti-money laundering is not a good fit, let me switch it up with something else.”

They can switch it out, right?

DM: So one of the things that I’ve seen and I’ll be interested in your perspective on this is that there are standards like BIAN in Europe that standardize the interfaces between the banking components so that you can take out the ledger or you can take out the credit risk module and you know replace it with something-Yes, you might not get every single parameter matched, but it’s close enough that will minimise the effort for swapping in and out component.

And then you get to what I think the industry is calling a composable architecture, right, where you can mix and match much more like Lego bricks than you could do in the past.

Is that, is that what you’re talking about?

SD: Yeah, absolutely. And BIAN, we’re a big proponent of BIAN. We are BIAN-aligned as well. And so when you externalize and you settle on BIAN as the standard for the interfaces and the data model to replace a component as long as it’s BIAN-aligned becomes a lot easier, right.

And that’s what I’ve seen banks do is they want to externalize, use best of breed products and stick a BIAN layer above them so that if I need to replace them, I know BIAN, the vocabulary is the same and so on. BIAN is also very handy when you think about, Dharmesh, when you think about coexistence.

I have an old core.

If I get the data out and BIAN-align it, and I have a new core, I get the data out and I BIAN-align it.

I have BIAN-aligned data. It doesn’t matter which core it came from, right? The experiences and all don’t know where the data came from.

The BIAN layer abstracts all that away.

DM: Fantastic.

A couple of things surprised me because I didn’t know that Zafin actually was BIAN-aligned. I just mentioned it because it’s an area that I’ve been looking at recently under the banner of Composable and Coreless, right, but also I thought it was much more a European thing.

So it’s quite interesting that you as a Canadian/U.S. company is already BIAN-aligned, that’s fantastic.

SD: Yes.

And there’s there’s a lot of North American banks that are very much focused on BIAN, right.

DM: Right. OK, cool. So what about in terms of adoption, have you seen much like this, this is the space that you’re in, you’re facilitating an aspect of modernization, right? What’s the adoption like and the success, right? Compared to a core replacement, maybe that’s a giveaway answer there, but, what’s the adoption like globally?

Where are the countries or regions that are most open to modernisation versus replacement?

SD: Personally, I think, I’ve seen it across the board, yeah. And across the globe.

Like, I think everyone has come to realize that core replacement is not an option. It just isn’t, right?

Maybe in the last 11 months, I’ve encountered one client, one bank that is thinking that they’re going to replace the core and put everything on hold. And I think they’ll come to fast realization that that is not the right approach for them.

All of the others are very focused on core modernization. They’re all focused on hollowing out the core and many of them are doing it differently, right?

Some are doing it without picking a modern core. They just want to hollow the existing core out and go with best of breed products for the different components and leave the legacy core as the ledger and others are standing up another more modern core and want to coexist.

And so the coexistence becomes important, but with the coexistence again, it starts with hollowing out, get the product out and share the product catalog across the two cores, get the customer master out, share the customer master across the two cores, right.

So even the hollow out strategy and the coexistence going from 1 core incrementally to another core, the idea is still very, very similar in externalizing these big blocks and using best of breed products for these big blocks.

DM: Right.

It’s for some of the banks. I know because I was in one in the 90s roughly when you were doing the mainframes, I was also doing the mainframes and I was involved in a project where we put the customer file into the mainframe as a separate kind of application.

And everything to do with maintaining a customer record was done in one place. And prior to that, we had a few different cores and they had a customer record in each one, right.

And we quickly saw the problem that, hold on one sec, we’re not only duplicating customer data, but all the processes around managing a customer were separate according to each core, right? So it kind of made sense to me and we spent, in the mid 90s, we spent a billion dollars just on creating a customer database and admittedly you know that was in a big mainframe, it was at the time the largest customer database to be sitting on DB2, right?

But the logic stands up to what you said, it was about taking out a piece of functionality and making it so that it’s separate to the core itself, right?

For me that made sense. And later on, when I worked in a core banking software company, I was surprised, I was surprised that the customer record was in the core.

I could see the necessity for it, right. But one of the first things I did was to create a plan to kind of separate it out and we created a digital platform for managing the customer record and the interact customer channels like Internet and mobile etcetera, right?

So that all made sense to me because it was part of that picture.

But the penny never really dropped until I started speaking to you guys about the product catalog and how long has this been going on that people are wanting to centralise their catalog and pull that out of the core.

SD: How long?

DM: It makes sense-

SD: It’s been many years I think, or it’s in five plus years at least that people are trying to centralise the product category

DM: relatively new then, right.?

SD: Yes.

DM: And is that because they’ve seen the problems of having multiple cores and the different catalogues and the different ways of defining products in different systems, right. Any other reason why it’s been later?

And I can create an account at a bank depending on the amount of funds I have in the bank across different accounts, I could move from 1 tier to another, and it unlocks different capabilities.

Everything from like a Netflix account or when those kinds of capabilities start showing up and you realize, well we cannot do that in our existing core and our competitors are doing it. What, what are your options, right?

DM: Yeah.

SD: So externalizing products started to be a very important aspect because of innovation in the market and what customers demanded, right. So Zafin’s been around for a long time, but over the last four or five years, things have really, really taken, taken off.

DM: Yeah, I can see now, I put some of the very first banks online in, 97 to 2001, right. And then that was the beginning of the Internet era and we were talking about like the high street’s been shrunk into a 14-inch screen. That is how big our monitors used to be, right. But, when you have that, you can do the comparison on these products, so much quicker, so much easily that actually the product definitions are now have become far more important than they were, pre the Internet and pre-mobile, right?

SD: Yes!

DM: Really, although we talk about the Internet banking starting in ’97, ‘98, right? It really only took off after the smartphone in 2015, right? Well, not 2015.

But 2015 was like the year it kind of really hit over into the mass market. More than 50% of clients, of banks clients were using Internet banking, right, because of the accessibility of things like smartphones, right?

And now, what you are saying is well, fintech’s added another pressure because not only was everything much more comparable, but they were innovating faster than the banks on the stuff that customers wanted to compare, right. So that makes sense now, why you want to have a catalogue now and a single way of defining products separately?

SD: Absolutely.

DM: Have I summarized it correctly? Am I not putting words in your mouth?

SD: No. You absolutely summarized it really well.

DM: OK, good, good.

Going back to the previous question though which was really about like the spread, is it global or is it more localised? I asked that because when I was, I guess I am more focused on Europe, and in Europe, I see a lot more projects started not always finished in around core replacement but in the US, I just do not hear core replacement being even muttered.

It’s almost like there’s no point in mentioning because nobody wants to do it.

Is that kind of right?

SD: That is absolutely right. Like, no one, none of the banks that I am dealing with in North America are even thinking about a core replacement. Everyone is thinking about core modernization. Some are thinking core modernization with a new core.

Some are thinking core modernization without a new core, but no one is thinking they are going to do a core replacement and they are just overly complicated.

DM: OK. And just to, again, I’m sorry, I’m taking a slightly different tack as well. On the modernization topic, we know that Zafin can help on the catalogue and the product definition side of things, right?

You also mentioned that you could go to another vendor for the customer management side of things. Is there any other kinds of modernization that people can do?

SD: Those are the first two starting points.

DM: Yeah.

SD: Yeah, the first two starting points are typically product catalogue and that means you know product, pricing, fees, and rates and offers and rewards and all of those capabilities and then the customer master.

Those are the two big blocks that I see most clients are, most banks are going down.

DM: And what about anything small?

I mean it’s funny because with tech companies they want to jump on a bandwagon, but they provide very niche components.

But I saw a company the other day that do market data distribution, right.

And they are essentially a layer on top of the Kafka, the messaging layer and they scale it really well and they take pressure off the legacy system. So rather than every single request going to the core banking system, they cache some of the data and they stop it almost at the edge of the network, right, and distribute from there.

And they have started talking about modernisation as well. And I am thinking, actually that is a form of modernisation.

It’s not a business modernisation like you’re talking about, like the catalog for the customer management, but it’s a technical modernisation of well, if the core can’t take all these new requests that are coming in, let’s take the pressure off and do it at this edge layer, which I thought was fascinating, and it kind of means that, there is this, it’s almost like CRM is a given for every kind of company.

It’s like modernisation is looking to start to be part of every kind of bank, I guess.

SD: Yeah, yeah, I’ve seen some of those as well and I have probably implemented some of them as well in terms of, when you think about the number of core systems a bank has and it is quite a few. And those systems of record are data silos, right?

The data is locked up in those different systems of record, and unlocking the data and streaming it out of those systems of record and making it available for querying for reading as a high performance cache after it’s streamed out and you could move all your reads from all your legacy application over to this new high performance cache.

You know moving reads off the legacy, especially mainframe, right? Moving reads off the mainframe and putting it against a cache that is near real-time has been a strategy that has been used many, many times, right. And it does work well.

If you are modernizing a customer master for example, you typically want to start by let me create a proper replica of this customer master in the modern state and I will coexist the legacy customer master and the modern customer master.

I’ll keep them in sync and then I will start by moving the reads off. Now I have all the reads are going to the modern one and I will see how things work and then eventually I will move the rights over, right.

But that progressive modernization of getting the data and saying moving reads over then slowly moving writes over mitigates risk because you could flip back and forth if you needed to, right?

DM : Great. And maybe one last question and we are going to drop into the technology now, right? Because I do like to try and appeal to as many people as possible, but I do love my technology too, right?

So when we talk about modern software versus legacy software, what does modern software look like?

What is it to be cloud native and APIs and what are the things that they should have a modern piece of software?

SD: Yeah, so a modern piece of software. Typically, you hear the word ‘cloud native’ very often, right? And what cloud native means is that I can run in the cloud and not just run in the cloud.

I take advantage of the cloud, right. And the cloud has a lot to offer, right?

It’s not just about “hey, I’m horizontally scalable and I can take advantage of the on-demand elasticity and I can horizontally scale up and down”. But it’s also about taking advantage of the services that the cloud offers.

If you look at Azure, you look at most of the clouds, they have a marketplace of services.

You want to take advantage of those services which are fully managed that you can instantiate with a click of a button. You want to leverage those services, so you don’t try to build those yourself.

DM: What services are those?

SD: Whether it’s a database, you mentioned Kafka, whether it’s Kafka, you want to use fully managed services that you turn on with a flick of a switch and not waste time on doing those things that are not critical to what you do, right?

DM: Right.

SD: So being cloud native is important. Microservices architecture and an event-driven architecture are also important. Microservices obviously you do not want to be a monolith. You want to be able to deploy multiple times a day. You want to give them squads that are developing the software, the freedom and full end-to-end accountability to manage their product and so on.

And people think about microservices and it is usually a technical discussion, it is actually less about technology, it is more about the how and the people and how you structure your teams and so on. And event-driven, because everything is moving to near real-time now and obviously Kafka played a big part in doing that and how you build software is so important, right.

Just like I said, microservice is more about the how, how you structure your team full stack squads into an accountability, use pair programming, use test-driven development.

Those are all aspects of modern software engineering that we need to adopt, right.

DM: So, I am going to try and summarize this for kind of business people.

Being cloud native means that you can take advantage of expanding the hardware for scalability and performance as well as the software for scalability and performance as well.

It means that you can take advantage of the facilities that are in the cloud, things like databases and stuff like that easily, right?

SD: Yes.

DM: Microservices mean that you are not writing one huge piece of software so that even if you make the tiniest of change then you have to ship the whole thing again.

If you ship the whole thing again, really you should have to test the whole thing, which means that you only do changes you know once a quarter at best. Sometimes once a year, right?

So it allows you then to deploy on a daily basis if you want to, right?

So changes can be much faster, but you are only making, you know, a small change means one component gets shipped not, the whole suite of software.

And then one moment, have I missed anything?

SD: No, I think event-driven?

DM: Event-driven, yeah that’s key as well because we’ve come from a world when people used to come into branches or they ring, but now literally they can get notifications and it’s a two-way conversation in real time that’s happening on your phone or any other device and therefore we’re doing more of it, right.

SD: Absolutely.

DM: So that has more pressure on the systems, but it literally means we can’t afford to go down.

And for people that are old as you and I, we know that some banks are still having to switch off their mainframes at night. So, they do their reconciliations over a batch window. I mean that this is just mind blowing for me that banks are still having to do that.

But yes, that happens that ledgers are being reconciled overnight and so therefore in that period, they cannot do anything really. People have come up with solutions that allow you to switch it off and then carry on temporarily on the outside, right.

But yeah, so this event-driven architecture is also really important for real-time world that we’ve kind of moved into, right?

DM: Absolutely fantastic. I feel like we have covered so much ground. We have defined legacy, we have defined modernisation, we have discussed some of the challenges of modernisation, and also the pros and cons behind it, the different styles of modernisation. We have talked about why banks, even with a new core, could benefit from modernisation.

And then finally we talked, really, about or defined what a modern piece of software is. What a valuable podcast you have helped me create. Thank you so much for your time!

SD: Thank you so much, Dharmesh. It was a lot of fun chatting with you.

DM: Absolutely.

DM: I look forward to the next one.

SD: Absolutely. Thank you so much.

Business agility

Operational efficiency

Product profitability

Risk and compliance

Core Modernization

Our approach

Zafin Studio

Product Catalog

Rates & Fees

Proposition Manager

Billing

Deal Manager

Data Fabric

Analytics

Dynamic Cohorts

Signals

Tiering

Product updates

Our company

Careers

Aspire & Achieve Scholarship Program

Leadership

ESG

Locations

Contact Us

Banking Blueprints

Podcasts

Newsroom

Case Studies

Event Calendar

Banking Blueprints

Banking Blueprints
Podcast

Breaking free from legacy systems: advancing banking through core modernization

Transcript

Want to learn more about how Zafin can transform your bank?

Our approach

Zafin Studio

Our company

Banking BlueprintsPodcast

Breaking free from legacy systems: advancing banking through core modernization

Transcript

Want to learn more about how Zafin can transform your bank?

Banking Blueprints
Podcast