PegaWorld iNspire 2024: ING Makes a Monolith Application Scalable

Good afternoon. My name is Darren Reuter. I'm the account director for ING at Pega. And I'm really, really pleased to introduce you to, um, the ING team from Business Lending. Uh, they've over many years developed a platform specifically for the Netherlands. And at one point they started to expand that to different geographies and different countries, um, and different use cases. And that brought complexity and technical debt. And they've spent a good portion of their time in the last few months reducing that complexity and transforming a monolith into a modern, modern application architecture. And so I'm really excited and pleased to introduce a fantastic team ING Business Lending, Sandra, Caroline and Lakshmi, we're going to tell you about their this thing.

Thank you. Thank you for this introduction. And welcome everybody. Happy to see many faces in the room. We were a bit scared after lunch. Lunch dip. Nobody would show up or people would be sleeping. But it's good to see that that you're all here. And we hope to share our story with you.

And and it's going to be interesting for you. Our title is ING makes a monolithic application scalable. And we are going to tell you today how you can slice an elephant. But let's start first with who we are. My name is Sandra Nunez and I'm the head of it for business lending in enGen, Netherlands. Um, currently responsible for 160 engineers working on multiple applications, all servicing our customer, our business lending customers in NL, and have over 15 years of experience in financial services, both business and IT, of which ten years in management roles. Hi. Good afternoon. My name is Lakshmi.

I'm a Pega Lead system architect. Having 14 years of experience in Pega worked in both insurance and banking domains. I am part of ING since 2016 and I act as a lead for a cluster at business lending, and I always ensure my team to provide and to implement best solutions so that we can leverage the technology and also provide optimum business value. Hi, my name is Caroline Luxembourg. I'm an IT chapter lead at ING. I'm responsible for the Pega application within business lending, and I'm heading a chapter of 16 engineers working from both the Netherlands and India. Throughout my experience, my drive has always been to deliver great solutions for customers together with the really engaged team. And in the meantime, I'm also having I'm enjoying the fun things in life and. To wake up everybody a bit.

We will start with a short movie of ING. Let's hope it works. Do your thing. Go! Do your thing. Nah. I think everybody now knows everything about ING. But still. Before we deep dive into the content, we would like to ask you to participate in a short quiz to get a little bit more understanding of ING and specifically for business lending.

I also had some gifts, but then I was told that I'm not allowed to hand over any presents here in Las Vegas due to law restrictions. So sorry, no gifts, only a few minutes of fame at the end, but let's see how far we can come. So if everybody can grab their mobile phones and connect. We are challenging ourselves here a bit with all the techniques that we use in the slides. So we hope that everything works, but we'll see. Darren, can you give us a heads up if it works? We only have 45 minutes, so no pressure. Okay, good. Do people see the first question?

No. Not yet. No. Not yet. Otherwise, I also have them on the slides since there's no prize to give away. We can also do it like that. But yeah. It's working. Okay.

Can everybody see the first question? Not yet. Okay. That's because people are still entering. So we thought, let's give it a few seconds. No. Not not nothing yet. Waiting for people to join. Okay.

Okay. Okay. Yeah. It's good. Good. All right. Thanks. Well, the first question is, how many customers does ING have worldwide? Is it 390,000?

39. 39. 3.9 million or 39 million. Yeah. Everybody filled in. It's actually 39 million at the moment. We have our ING headquarters in the Netherlands, and we serviced 39 million customers over 40 countries. So we are a global company at the moment and we have a focus on retail, wholesale banking and business banking. And our purpose is to empower people to stay ahead in life and in business.

Question number two how many employees does ING have worldwide? 6000 336,000. 63,000. Sorry. Or 630,000. All set? Yep. Correct answer is 63,000 at the moment, and we have many employees around the globe. Despite the fact that we are still digitizing, we do have to do a lot of manual work specifically also for our lending processes.

And therefore we still also have a lot of people working for us. Um, due to the complexity of the products in the Netherlands, we have 80 million private individual customers and we service 630,000 business customers, and many of our customer journeys are supported by Pega workflow. Third question what do we consider to be a business banking customer? And these are always tricky. You have to fill in all that apply. We have some ING colleagues, so I'm wondering if they know the correct answer themselves. On the first row would be a nice one to test. Well, actually the first three are all correct. So this means we are servicing actually quite a lot of different types of customers and a diverse customer group, which also means that we really need to rely on a really good workflow to be able to service them well.

And our last and final question in what year did ING business lending and Pega join forces? The Pega people are not allowed to answer ING people also not. The correct answer here is 2016. So eight years already. And that's when our journey together started. And so it's been quite a while that we have been collaborating together. And uh oh really sorry. The Dutch national team is currently playing soccer and I have somebody here giving me the heads up. It's four zero.

I'm a huge soccer fan. So sorry for that. Um, and I asked him to give me the heads up, so, um. Yeah. So Eng business lending. Who are we? Well, our purpose is to drive sustainable progress for all entrepreneurs with best in class business lending services and journeys. This also means that all our tech solutions need to facilitate this purpose. And we aim to do this by focusing on automation and digitalization to achieve the seamless, sustainable, compliant and data driven business lending journeys not only for our clients but also for our ING employees and of course, also our regulators, which is a really important one since we are in banking.

Sounds really good, right? But having a vision and a purpose doesn't mean that we are always up for success. We always have to challenge ourselves and need to make sure that our. It is also best in class to be able to service our customers in a proper way. So this is how it all started. I'm going to take you on a short journey. Probably most of you know what the building is on the for me, right? For you, maybe left. Does anybody know what it is?

It's the House of Steve Jobs where they created, um, the first Apple product, which started really, actually really small in a garage. A successful journey building one product. We started in a similar way in Eng, not in a small garage, but in our building in Amsterdam. But we did start with one team building, one case type. Um, and at this moment we are actually servicing two countries with 12 squads. So we started really small and we grew into this large application servicing many, many customers. But we are still organized in a way as we started at the beginning. However, our application has grown over time. So as you can see, in 2016 we started building our first journey, which went live in 2017.

And at the moment we have 19 case types and our solution is called Blend Business Lending. Blend. It's not the most creative name, but easy to remember, and it's the target to automate and orchestrate all our end to end journeys. We have currently over 1000 users and 300,000 case types annually. Go through our case types and we use Pega Infinity version 8.8.3, and we host it in our ING public cloud. We want to show you a short testimonial of one of our users. I work at ING at a specific department where we treat clients which are facing financial difficulties for a long time. We manage our work with tools like word, Excel, outlook and SharePoint, but it gives us difficulties with capturing the right data. As a department, we work for several years now with Blend because Pega is the solution for business lending from ING.

We have the aim as a department to digitalize all our processes and where possible, also to automate them. Since we work with Blend, we have one way of working. We get more information of our clients so we can help our clients in a better way. We got more data points for us, but also for our stakeholders. And also our colleagues have one way of working so they make less mistakes. So we actually have happy customers, which is a good thing. But however, we also still face a lot of challenges due to the fact that we are still organized. As I said, the same way as what we were when we started with one team, one case type. Now 19 case types, 12 teams.

That gives us a lot of challenges on the way on how we are working currently, and we need to go to the next level to be able to service everybody in a proper way, and also to be future proof with our application coming back. This is the Apple building, the difference between Apple and ECG at the moment. Well, there are a lot of differences, but I think one specifically for this story is that Apple actually adjusted their way of working quite a lot. So they are really adapted. They have adapted their way of working to be able to service customer demand really quickly with a lot of new features. Everybody knows the big launches in September from Apple and ECG actually needs to do a similar thing. We need to reorganize, restructure and also make sure that we can live up to our customer demand and also deliver on our purpose and vision, and for that we need to take some steps. Yeah. So it starts with facing our challenges.

So as Sandra explained, um, we had one case type in 2016 leading up to the 19th case types in 2024. And what what is the problem with that? You can ask yourself, um, there's a lot of duplication. So you can think of we have several loans processes within uh within our department. You can think of processes like loan origination, problem loan management, these kind of processes. And there's a lot of duplication because you can imagine probably that every process starts with identifying a customer, for example. So that is the duplication already. And then across the 19 case types. Um, so that is one of our challenges.

And that has a high maintenance obviously. Um, also we have big releases. Um, ten squats are currently working in our area and we are doing weekly releases. That means that ten teams need to coordinate across, uh, the different squads to make sure that at the end of the week, the release is ready to go to production. Uh, I think we are doing a good job there. We are combining the work of two teams of ten teams, but still, we think we can do better. We can, uh, deploy to production much faster than, uh, only weekly. Um, so we have a relatively long time to market, and we want to improve that. Um, we have a complex structure, as Sandra already explained.

Um, we have, uh, 19 case types. So when there are incidents, it's sometimes difficult to pinpoint where is the incident. Is it in, um, the framework layer? Is it in one case type specifically, is it across the different case types. So a relatively long time to resolve incidents. Um, and also we are now less flexible because we want to onboard new departments. Um, but with this monolithic setup, if you just add cases, that means that, um, yeah, that you will have a lot of duplication again. Um, so that is the challenge we are also facing. We're also hearing some background noise.

But I will just. Live music on the back. Yeah. Um, and we need to address the elephant in the room. We did a Pega review together with Pega in 2022. Uh, where also Pega gave us the following suggestions. Um, we need to really break out this monolith into few business applications, and we really need to revisit the Layer Cake. Um, so that is, that gave us the hint to really start slicing based on logical business elements. Um, so we, we conducted workshops together with business.

Um, and then we came up with business elements such as loan origination, pricing problem loans that we could isolate to really cut up this monolith. Then the journey continued. In 2023, we did a deep dive together with the Pega consultants that led to, um, a roadmap and a planning that we are now following. And what it actually comes down to on a high level is that we have, uh, four business applications on the one hand, and we separate them into, uh, into the business application at first and then the reusable modules, on the other hand, that you can then use across the business applications. But we'll tell you more about that later. So we will we're working towards a more modular setup instead of the case type setup that we had earlier. Um, and now working on that at the moment, um, how will this help our ambitions? We have quite some ambitions, both on the technical and on the business side. On the technical side, we really want to increase the efficiency, uh, promote reusability.

We will have less duplication, as I already explained. Less maintenance. Less regression testing because you can imagine with ten squads doing regression testing, that's a lot. Um, we're also moving towards a clear, a clearer ownership of code because now and less cognitive load for engineers because now you have to learn the whole, uh, of Blend. And then with this new setup, you can only focus on a specific part of it. Um, we will increase the deployment frequency. As I said. Now it's weekly. We want to do that much faster.

And because we have less dependencies, we can create smaller releases and we will have a shorter time to market. Um, also, our level of service to users is a really important point because we want to really have less incidents, faster to resolve incidents and have a better performance for users as a whole. Um, then also on the flexibility side with the modularization that we're now working on, we can be much faster to implement new functionalities, be more scalable for different business use cases, and easier to adapt to the latest features of Pega. Um, on the business side, we really want to increase the stability, maximize the uptime that we have with our application. Um, really have a good performance for users. Um, we also want to boost the commercial impact. So by increasing the speed of delivery and having smooth releases, we can make, for example, small improvements with a big impact. And we want to really reduce our time to. Yes, that is important for us.

We want to deliver to the customer much faster than we do today. Um, standardize and integrate. Uh, we want to make sure that other products can also use Blend. So we create efficiency because users only have to use one system instead of multiple. So how are we going to organize for the future in 2023? We introduced team topologies within Blend. That is a methodology that creates flows across teams. Um, with doing that for Blend, we introduced the Platform squad where we make sure we have efficient operations and we um, also pick up, uh, work like Pega upgrades, IT risk. And the squad is also working on generic components.

We introduced a Blend design panel where the senior engineers are, uh, sitting in, and they really make sure that the quality is, uh, yeah, assured across all the work that we deliver. And I think that's similar to also what Pega, uh, advises. So to have a center of excellence, really to prioritize the reuse of assets. So I think that's what, uh, that we see a lot of similarity there. Um, at this point also other departments have shown interest in our application. So currently there is lease and commercial finance. So in order to cater for that we have come up with a as you can see on the picture, it's a gray. The gray part and the orange part. The gray part represents the business banking generic layer.

And the orange part contains the product specific layer. So we are organized in that way. So we can really reduce duplication and really look at the customers financing need instead of starting with a product journey. Um, and that allows us to focus much more on on what the customer wants. Um, how far are we with implementing this project or this slicing of the monolith? We did a hackathon where we really showed that the design works. We have really isolated the code within four business applications and also created some reusable modules already. So with that, the design phase has been finalized and we're currently in the implementation phase. So we have isolated reusable components in the framework layer already, such as, for example, the questionnaire or cascading approval.

These kind of examples. And in Q3 we will be really focusing on building those business applications and the reusable modules. And we aim to complete the project early 2025. Okay. Thank you. Now I'll go a little detail about the technical details. So first I'll show you how we move from a large monolithic application into a small scalable solutions. So first I actually wanted to show our current design how it looks like and why we decided to slice our big elephant. And then I will come to the part that how we are going to implement it.

So if you look at this so if you see the left hand side picture, I think it is. The picture itself is representing the complexity. So it is very hard to read the same lines for our application also. The application is in a state where it is hard to maintain and hard to read. So that's where we decided to slice the application, because it is a big mashup application containing 19 case types. So we have so many. If you see the links, there are so many sibling and child case relations, so much of redundant code. And we are also maintaining legacy case steps, which were started in 2016, and a lot of performance issues because of the huge application stack. Can you imagine our application stack is around 80 plus applications when users try to login into Pega.

So they actually they see the problem of loading a Pega screen with 8080 plus applications in the application stack. And apart from this, like Caroline mentioned. So we also have to spend a lot of time on regression. Uh, and also it is more time to market also. So considering all these factors, The other thing. Important thing is like though, we are using the latest versions of Pega which is 8.8. Still, our application design is blocking us to use or to adapt to the latest features of Pega. That is also one of the reason why we decided to slice the elephant then how we are going to slice it. So if you look at the other picture, so we started our analysis how we are going to slice this big elephant.

Then we started our analysis and we had multiple discussions. And one of the Pega consultant from Pegasystems also helped us during our analysis. So we came up with multiple approaches, had multiple discussions, listed down all the pros and cons of each approach. And this is the final approach that we are going to implement. So before we actually start slicing the elephant, what we decided is we first have to clean up our application. So we are still maintaining our legacy applications so that we really wanted to decommission those legacy steps. How we started decommissioning legacy case types is like. So we started moving the features of legacy case types into the new case types. We changed our implementation methodology so that a new case type can serve multiple purposes, providing maximum reusability.

In that way, we started decommissioning our old case types and moving the features to the new case types. And the other biggest challenges we have, like circular dependencies within the case types. So like circular dependencies, you know, right. It refers to multiple case types dependent on each other either directly or indirectly. So because of these circular dependencies, if there is a change in one case type, the other case type also gets impacted. And this makes our system more fragile. And also it is very hard to maintain. We really wanted to break these circular dependencies. And for that what we did is we implemented a separate feature called Event Bus, where we just pass the parameters like the what kind of case I wanted to create and what would be the application context.

And that feature will create a case for us in that we will reduce the application stack. The event bus will run parallelly to our case types, and there is no dependency between case types and also the event bus. In this way, we started creating our sibling cases using event bus component, and we are also going to extend the same component for any Kafka triggers or any external systems that wanted to create a case within Blend. And the third challenge is like now we have a huge Blend framework layer, which is maintained in one ruleset, and we have around 20 plus generic features, and everything is implemented in the same ruleset. So from my team, for my case, if I am using only one of the component and if there is change in other component, I still have to test the complete functionality. And this leads to lot of regression time. And we really wanted to avoid that. What we did is we started extracting all our generic components which are like 20 plus generic components from framework layer and making it as a separate component. From my business perspective, what component I can use, I can just include it in my layer and I can proceed with my releases.

And we also wanted to make our Blend framework layer more lighter, and it can only contain the classes and the data model and no business logic. And next slicing up mashup application into four business application. Before going into details of this part, I will also focus more on the global reuse. As I already mentioned that we started extracting generic components from our framework layer. Now it is only used by Netherlands Business Lending and also Belgium business lending teams. But we also wanted to make use of these external generic components to other Pega applications within ING. So at the time of extraction, we are also checking. We are also discussing with the Center of Excellence teams the requirements, whether they can reuse any of the components which Blend already have based on the discussions we had already started extracting whether the component can go into business banking Blend layer, or it should go into ING layer, which can be used by other departments also. So that way we are also moving some of the components like I mentioned, like Event Bus, cascading Approval and Pricing engine, all these components.

We are planning to move to the generic layer. ING so it can be used across other departments. And the breakdown of a big monolith application into four business applications. So we started breaking our application into these four business applications called loan origination, problem loan management pricing and MDL. So we have considered multiple factors like which case type should go into which business application. So the main thing that we considered is the business purpose. So all the similar business use cases should go into one business application. And also the maximum reusability between case types within that particular business application. And the other thing is like the less dependency with with other business applications.

So if the business application is very much isolated, then we can move our features, we can implement our features easily and and it will lead to faster time to market. So this is our target architecture. So from the current design to this target architecture if you see we have four business application called loan origination in life pricing and temporary limits. And we also have the specific framework framework layer for those four business application. Why. Because if some components or integrations are used only for that business application, that will go into the framework layer of that business application. And apart from this, next to that we also have Belgium where they can reuse maximum of the generic components, maximum features from the business banking layer. And we are also trying to onboard other departments within ING where Luis and Commercial Finance will also start using Blend application, and they can also get benefited from the components or the functionality that is already available in Blend. So.

So now actually if I look at this picture, we are moving from Situational Layer Cake to modular reuse layer which is suggested by Pega. So we have our own application layer where it contains only case lifecycle and data, and the framework layer which is specific to the business application with all the generic components. And we have a business banking layer which is common to our business banking applications for business to business lending, Belgium business lending Netherlands lease and commercial finance. And on top of it we have ING enterprise layer where we can get use maximum reuse from the enterprise layer and then Pega out of the box layer. So all these steps are taken to be able to deliver on our customer promise, which is to drive sustainable progress for all entrepreneurs with the best in class business, lending, services and journey. So it's been quite a journey already so far. We are not there yet, so we still have some steps to take, but we are heading in the right direction to be future proof. Also on the long term for our clients. And eventually you have happy clients.

Thank you. Thanks. Are there. Any questions? Perhaps. A presentation? It's not on, but thanks. Um, so you talk about the monolith application. How do we actually define like what's the monolith application for you?

I think the short summary is that it's too big looking. Also at what Pega recommended is that, um, yeah, it has grown too large. And that's why we mentioned all the, the disadvantages of that. It's very difficult to maintain. It costs a lot of time and that's why we want to split it up. I think maybe to add to that, what we see today is that we have added a lot to the original application. So we started small and we just continuously added new features to it. New case types. We integrated a lot of other features to to the current application as well, which makes it really complex.

So once like for example, when we want to bring something to production, we need all the squads integrated in the testing. We need all the squads that need to do the sign off to make sure that we have once we go to production, nobody has an incident that everything works correctly. So we have a lot of dependencies, which is not helping in our time to market. And my second question would be, um, I think you had several options how to solve this problem. You chose to slice the monolith. Maybe another option was to build a new application from the ground up, based on the latest and greatest Pega technologies. Did you even consider that option? And what actually influenced your choice to slice it and not build an entirely new application? So it is actually with 19 case types, it's not that easy to start rebuilding all these 19 case types using the latest features of Pega, we thought.

And if we also consider the time and the effort that we have to put in. So for breaking the monolith, it is easy and it can be done within a couple of quarters rather than building all 19 case types. And also once we start splitting it, then we are ready to use the latest features of Pega. So thanks. Thank you. No questions. Yeah. There's someone coming. Hi.

This is Uday from U.S. Bank. So how do you guys deal with in-flight cases? I know the same lines. So are you maintaining different infrastructure and slicing out? No, not. Not same. Same infrastructure, but we just use different application stack. But now we have only one application.

Under one application. We have all these 19 case type related application so that we are actually breaking it. But infrastructure it is the same infrastructure. Infrastructure all the in-flight cases you are resolving and then moving to new case types. No, we are not building new case types. We're just breaking the application. The application case types will stay as is, but from user perspective. Instead of seeing 19 K steps, they can only see 4k steps. So the application stack will get reduced.

Got it. Thank you. I'm Halina from Bank millennium. So very similar business. I would like to ask one question. How did you measure the success? Because the major goal was to make the time to market faster. But did you have some other KPIs kind of that we decrease the time of testing. We decrease the number of test scenarios.

We increased our efficiency by x percent. Did you measure it or you just you just knew that you want to do the project and it was enough for you to to achieve this final goal of time to market. I think both. So we also have quite a lot of measurements in place, which also showed us that currently we we are facing a lot of challenges, whether it's time to market, whether it's incident resolving, but also maintenance. We spent quite a lot of time on maintenance. If you have everything in 19 case types and sometimes also multiple times the same. So those kind of numbers do we do have and we also have indeed targets on how to reduce that. But there's also the user aspect to this which is really important for us. We have some business, uh, colleagues also with us.

So maybe if you have some questions for that, we can also do that separately. But that was also an important one because of the stability and performance which which play a big role for us, of course, as well, there were also quite heavily impacted by the way we were organized. So that was also one of the reasons why we looked into this, to see how we could improve. And next to all the complexity and also the dependencies that we are facing with this current setup. Thank you. So I will I think I will catch your colleague. Get some more details. Good. Hello ladies.

Thank you so much for such a wonderful session and it's a proud moment to see you all like especially the ladies presenting there. My name is Radhika and I have a question for you, as since you're already slicing down the application and you're also going in the modular way, uh, you know that with Constellation coming up, first of all, what's the UI that you are using for this new application? And we're still using UI kit. First we wanted to slice our application and make it future proof. Then maybe we can think of moving it to Constellation and also Infinity. Yeah, I guess so. So, uh, with this Constellation thing coming up, you're already on the track of this, uh, modularization, and you're already creating a modular layer. But as you know that there is not there is no concept of framework once we go to Constellation. So what is your vision?

Because the entire this Blend is a framework, as you mentioned, it's for Netherlands, it's for Belgium. And you're also trying to onboard more, uh, line of businesses. So what's your vision for not having that framework and going to Constellation? Do you already, uh are you already preparing for that and how? anyhow. Yeah, I got it. So we still maintain we are calling it as a framework, but it is more of a business banking layer where it contains only the generic features with all different kinds of rules, set of all the generic components and extra data model and classes apart from nothing will be there in that layer. It is where as a Pega terminology, we are calling it as a framework, but I don't think it will break because of Constellation because there is no UI in the business banking layer. Okay.

Yeah. That's it. Thank you. Yeah. Hello? Miriam here. Um, I have a question. Are you able to do all these refactoring changes and do all this parallel to new developments, or did you need to pause some projects and then, uh, do all the slicing up first and then continue to implement new business requirements? That's a good question.

Um, both. I think it's the most honest answer. We do indeed also deliver new features. And we do still a lot of change. But part of our capacity, which is also being used for this, and if you use it for this, you cannot use it for something else. So it's a constant trade off on priorities together with the business to see, okay, what can we do? At which moment in time. Um, but we also um. See also.

And fortunately, our business partner also recognized that is that we need to take certain steps also to be able to deliver faster in the future. So it's not only for today, but it's also an investment for later, which will eventually, hopefully also enables us to deliver more, faster, better quality and hopefully also with less, because that's also one of the challenges we currently quite, quite a lot of people, uh, to do this. Um, and we are also looking for ways on how to reduce that. Um, but so I think the most honest answer is both. Yeah. Thank you. One follow up question. Are you able to bring that to production in increments or are you doing full refactoring first and then bring that into production incremental basis? Yeah.

Okay. So we have like weekly releases. So whenever we are ready with the component we'll just include that in the release. And then yeah. Thank you. Very interesting. Thank you. Thank you. Thanks for the deep dive.

And I have one question. How many users are there using your application. At the moment? Approximately 1000. 1000. Yeah. So those are concurrent users or like. No, I don't think they are concurrent users. No.

That will be less. This is the amount of users that has access. Yeah. What is uptime of your application like is those users thousand users or like more like on weekdays and weekends. It's Piyush wants to answer that. Yeah, I'm interested in because we have an application we recently OK. You need to talk in the mic, I think, because nobody can hear you. Okay. That's fine.

So we have around 450 concurrent users and the user base is in Netherlands as well as Belgium. And uh, this, uh, what was the next question you were saying? Like uptime. Yeah. So our application is online. So, uh, all the weekdays 24, seven and then weekends also online channel, not the live users, but the online channel is using the application. Uh, we have so we have a central team in ING, which is called OP one Pega Platform that is managing the infrastructure. Uh, we are one of the tribe for them. So it's kind of setup and uh, infrastructure wise we are still using ING internal cloud, the cloud.

So it's like ING IPC and uh, we have around 12 production nodes as of now. Yeah. Yeah we do. Yeah. So we have for lower environments for testing. We have selenium scripts written. Uh, so all the testing is automated. And we are also integrating with a lot of around three plus 300 plus external integrations are happening. Uh, so we are using latest node type set of Pega.

Yeah. So all the nodes are separated. We have web users on separate nodes, uh, real time Kafka integration or separate APIs on background nodes. A lot of batches. So multiple things happening. Thank you. Thank you. Thank you. Piyush.

Hi. Um, one question. So we have a similar problem at our enterprise. And we have about 3000 case types. And we want to pitch to the business converting and doing the modular apps like you guys did. How did you convince the business that this is a good investment and, and also, uh, what was kind of the average time to convert for one case type? Maybe your first question, how did we convince the business? I think we were also helped a bit with the complexity of today's product, which is quite visible also for business, that things are quite complicated and take a lot of time. So I think that already helped a lot, but also with knowing that multiple other parties want to make use of our platform as well.

That was also, I think, leveraged for us to explain that if we are going to do this, if we are really going to service other internal clients other than business lending. So like for instance, we need to have an application which is fit for future. And with today's application, at least before we started this whole journey, um, I was not so secure to say, okay, please hop on and you can use it. And I can promise you that it will always be stable and performing. So I think that helped us. We did the Pega review, as I mentioned, um, two years ago, we started that last year where a lot of input also came on what they saw as a burning platform for us, which we could also use in our discussions with the business. So I think that helped a lot for the converting part. I think, Lakshmi, maybe you can have a better insight in how long that will take. Actually, we are not converting the case types, so the case types will stay as is, but only we are extracting some of the features from the framework framework layer.

So that part I think how much time it is maybe in 1 or 2 quarters the framework will layer will be finished. So that's our uh uh what do you say? Estimation. Estimation? Yes. Yeah. 30s. Sorry. Oh.

Hello. I'm from Netherlands. So, uh, one question. Do you. How do you mitigate from this treat sliced applications from becoming three big models. Again, what steps you are having in in the practice and how do you plan to govern that? I think what we see at the moment is that we will have the four business applications are also differently sized. So one of them will be a little bit bigger and it will be used by more users. The other ones will be relatively small.

And I think we should really also look at it from that perspective that for example, when we add new functionality that we take a conscious decision like should this be added to one of the four applications, or should we have a separate application for that? So in that way, you keep the size and you make conscious decisions about, uh, where does the new functionality need to go? I think that is how we will approach it. Okay. One more technical question. Um, so the slicing now, um, how how it is given to the users. Like how? How does the authorization happen? Is it built on model or.

Yeah. At the moment there is no impact for users. So we are just changing internally within the implementation part of a Blend. But our target is that users, instead of logging into 19 case types, they can directly log into. We also have to make segregation of duties at users. So whatever access they get for a particular case type, they will only get access to that application. That's actually our target. Okay. Thank you.

All right. I think we're running out of time. Oh, you said 30s. I'm running. Well, it's counting again. Up. So we have 45 minutes. I think I have more questions than one. Hello.

I have like, in fact, one regarding the time frame and the effort. So what is the time frame you have in your mind for this entire exercise? And you mentioned, I think 12 squads if I If you remember, how big is the team? So how many people you have inside to make this happen? Maybe the first question for the how many quarters? I think we. Yeah, we said we we will finish it by early 2025. So we have now uh, the third quarter is really focused on building those business applications and reusable modules. Uh, and then in the fourth quarter we'll be mainly testing.

So we expect that the go live will be early 2025. We started one. When did you start? When did you start? We started this year I think. Yeah. So I think in general you can say like around a year that we are working on this. Yeah. Yeah.

And the size of the squads, it depends a bit, but I think they are approximately 6 to 8 engineers in it. And then also business because we work in a business model. Uh times 12. Yeah. Great. Thank you very. Much. Thank you.