PegaWorld iNspire 2023: Achmea's High Five Mega Modernization Drive

Discover how Achmea's IT team used its “High five” principles to utilize the best of Pega, enabling faster transformation of its back end:

1. Range: Migrating Pega applications and Pega generic components from on-prem to Azure Cloud, thereby enabling wider access and availability to multiple business units.

2. Recent: Upgrading Pega applications to the latest version to maintain currency.

3. Resourceful: Adapting to containerization in order to facilitate faster, more efficient, and more cost effective methods to accelerate adoption.

4. Reliable

5. Reusable

Transcript:

- I am Peter. I'm Peter la Croix. I work at Achmea. I'm the manager of all our Standard Platforms and Integration. And Pega Systems is one of our most important platforms. Roderick, Sandeep will introduce them when it's data. What you see here is our fact sheet, our company sheet. I checked it. You heard the lady from Citibank yesterday. They were founded in 1812. We were two days before her. I convinced, I checked it so we win. And we were founded more than 200 years ago in the north of Netherlands in a little village where eight farmers got together in a townhouse, and they had a discussion amongst each other. How do we help each other if one of us get hurt? If something happens to the farm, if something happens to the livestock, how do we do that? How do we help each other? And they decided to save a little money every month just to take care of each other. That's how Achmea started. And now you can see we have evolved to that. We are a company, still a company that is built by and for its customers. At this moment we employ an evolving arsenal of financial services to meet the requirements of our users, but still a company built and by its customers for and by its customers. We have a purpose. And the purpose goes back to 1812, that purpose says sustainable living together, sustainable living together. And at this time of age that means that Achmea addresses major social issues on several areas like living, housing, income, pensions. And we do that in a way that creates a sustainable value for our customers. We are still owned by our customers, our employees, the company and the society as a whole. And our business teams, our IT teams form the core of that digital ecosystem. Well, Peter, you seem like a nice guy. You're standing there. Achmea seems like a nice company. What's your point? I'm getting to that. One and a half years ago, our business owners came to me and said, the platform is not up to power anymore. We can't meet the business expectations anymore. We are getting too slow. We are lacking in speed. Right after that, our own teams came to me and they said to me, "Peter, we can't contribute to the purpose anymore." And at Achmea we fully comply everybody to sustainable living together. If we run into hard times, we all say, remember when we were farmers 200 years ago, we stood up for each other and we took care of each other. And that the Pega platform two years ago was not suitable for sustainable living together. The teams just couldn't contribute anymore. We are almost at the end of the journey. Sandeep and Roderick will explain it to you. And that's not an I had a dream journey. It's an actual journey. We'll be finished in three weeks times and they have worked enormously hard. Why our purpose is so important to us. I will show you in this movie, and then my colleagues will take over and explain to you what they have done for the last couple of years.

- The heartbeat's really strong. Let's have a look at the other side.

- [Narrator 1] Yesterday the system was hacked and now all our files are encrypted.

- There's baby one. There's baby two, and there's baby three. Now you can enjoy your pension. You can sleep in, you can do whatever you want.

- They're all gone. We can't get into them.

- I was just passing by. The impact was massive. We can't fix this. Our only option is to pay the ransom. Noelle's Rehabilitation will be in small steps.

- [Narrator 2] So we've made provision for you to start your rehabilitation as soon as you leave the hospital.

- [Narrator 3] Yeah, we're gonna scale up to large fire. I need an extra fire engine.

- We will make sure all this matches and we'll repair everything.

- We have all the files back, and we'll be up and running in no time.

- Thank you, Peter, for handing the floor to me. I have some job applications over here. This movie must have convinced you what the company we are, but the movie really says it all. By the way, my name is Roderick van de Kant, I'm manager of the Pega Platform. Peter is responsible for all platforms within Achmea. I'm just responsible for Pega. So lesser responsibility for me. Sorry, the movie really says it very well. Of course, we are an insurance company, so when there's a claim, we pay money, but it's not really about paying money, it's about helping the customer. We want them to start a restaurant again. We want them to go into rehabilitation to get better again. So from IT perspective, we try to do the same to our internal business. What I would like to do is to explain to you the journey that we did within Achmea and of course together with Pega with regard to the Pega platform. So before 2011, we have some divisions within Achmea, health, life and pension, property and casualty for example. Before 2011, these divisions were allowed to have their own IT. They were allowed to have their own decision making process. They have their own money streams. Around 2009, 10, et cetera, something like that, we learned that it was better to have some uniform architecture, to have some uniform one standardized platforms. And we needed a platform that could help us with regard in workflow requirements and some integration requirements. So in 2011, we contracted Pega. In the years after that, Achmea likes to do everything by themselves. So we did not have a external partner help us with the Pega developers. We trained our own personnel. We had them certified. We trained our architects in what the Pega platform could do. And that resulted in our first application in 2014, when for the financial division, there was an application that went live that converted all national bank account numbers into international bank account numbers. Netherlands is in Europe. Europe of course consists of many countries, and each country had their own national bank account numbering system. And this application converted that into European or into international ones. This application was a success, luckily, and in 2015, we had two more divisions, health and life and pension also with applications going into production. By the way, they're still in production to date. So now for about eight, nine years, we have those applications still running in production. We also learned by then that having applications across three divisions that are some commonalities with regard to requirements, for example, authentication and authorization. So back then, in 2015, we also developed our first generic components that handled these authorization requirements for us. By the time we ended up in 2018, Pega was really a buzzword within the company. Everyone or at least it seemed like that wanted to be part of the Pega journey within the company. Everything had to be solved by Pega and all architects came to us, hey, we need to be part of this journey and this success. So in 2018, we already had 40 business applications in production. We had 21 generic components by then built for example, not only authorization and authentication as I just mentioned, but also for sending emails for retry and archiving for example. 2018 also marked the year where we allowed our decentralized divisions to have their own Pega teams. Up until this year, the Pega developer squad within Achmea was all centralized within Achmea IT, and by then it was allowed for the decentralized divisions to have their own Pega teams, which is enormous for them. Then in 2019, we started using marketing, sales automation, CDH. And if you remember the fact sheet from Peter's part of the presentation, we have 10 million customers, and in 2019, all of them are going through one of the Pega applications that we have. In order to achieve this, we also scaled up. Up until now, we had everything on one cluster on-premise 7.3, and we scaled up to five clusters, still 7.3, but at least we had five clusters. Now, there's a saying in Dutch, you're only allowed to leave the room once you can fluently say this. It translates something like the other side of the metal or the other side of the coin in English, because Pega was very successful within the company. Everyone was happy with the applications, with the success, with the advantages of the platform. Oh, I don't have my... I wanted to show to you every shiny metal also has the other side. So imagine what I'm doing right now. One of them is technical debt. We started with Pega on version 5.5, and because we wanted to help the business as much as possible with the fastest and newest, latest versions of the Pega platform, sometimes we forgot to get rid of the old stuff that direct us. So sometimes we even have applications that were more or less don't tell copies from 5.5 to 6.1 to 7.3. We didn't do anything to the application itself with regard to technical debt. Same goes more or less for the latest technological advancements. The ideas of Pega, of course, with regard to low-code or no-code are with every version different with every version, they get more implemented directly into the platform. If we stick to the old versions of Pega, we cannot benefit from all these advancements. Those were inside our application, inside the company. But also if you look at the customer trends, for example, our marketing department, they wanted to start more with omnichannel support, increased personalization, et cetera. We were simply not able to help them. And if you think back to the video that really hampered us. So if you summarize the issues that we were having not helping the business, there are five. Delivery to production. We did everything manually. We tested manually, we migrated manually. We had the discussions with stakeholders, whether it was allowed or not to go into production in actual meetings, teams during Covid, actual physical before Covid. So we were slow. The performance was slow, not only within the application, so from screen to screen within the Pega application, but also database calls. If you have 40 plus applications on one cluster, all going to the same database, well, there was room for improvement to put it like that. The business features, I mean we are still on premise during the migration going to cloud in the newest version. But in 7.3, the business features, of course, are totally different than what the latest version of Pega has. And the business asks us for it for this latest, newest business features. They're not invented hair syndrome. With having these five divisions, all with their own Pega workforce, the right hand doesn't know what the left hand is doing, and if they do, they tell us, no, no, no, we are from the health department. We know what our health business wants. We'll do it again because this does not specifically help our business. So the not invented hair syndrome is also one of the factors that impetus with regard to reusability. And all this combined led to the fact that we are not future proof. We are on an old version, on-premise, poor performance and everything. Again, if you think of how we want to help the business to continue, we were not future proof. So once we decided that we needed to make a radical decision and really started to migrate and to modernize everything that we had, we set up a steering committee across all the visions that would help us escalate if necessary, but also to align on all the same business objectives and purposes. We had to deep dive together with Pega because we wanted to go to the clouds. We wanted to go to the latest version immediately and how to do that, what to do first, do we do it together? So Pega was always involved in our definition of the roadmap. One thing that was always very clear is that the end date was set in stone in the 1st of July. So in three weeks from now, we have to be finished with everything and we will be finished with everything. At least that's what I tell Peter. We also needed help because we have our own internal workforce all certified. They're all very good people, but we needed help. One is because we needed strategical partner that could help us with doing this modernization that has done it before because we did not, otherwise, we would not end up in this situation. And secondly, we don't have enough people actually qualified to do this job with all these applications and all these divisions. So we needed a partner we founded in HCL Tech that could help us with the skillset with regard to knowledge and number of resources. So once this was all there, we set up a program and started working. And now I would like to give Sandeep the floor to actually explain to you how our modernization drive look like.

- Thank you. Thank you, Roderick. Good morning everyone. Thank you for being here. Really nice weather, but I will try not to delay your lunch. I'm Sandeep Katukuri. I'm from HCL Tech. I'm a solutions architect over there. When we started our journey and took over the challenge at Achmea, indeed there was a lot of weight because of the technical debt, which was dragging us down. And the target state was ever going forward because of the consumer trends and also the technology trends. At this moment, the only answer or the only resolution for this is modernization. Everyone over here may be a decade ago, we are all moving from manual processes to automated processes, from Excel sheet to Pega, mainframe to Pega or something like that, right? So we call it digitalization, digitization, name it. During that entire phase, we left something in the cracks. And that is dragging you down and the answer. And when it drags you down too much, the applications or the technology ecosystem is no more relevant or maybe, let's call it redundant and we solve it with modernization. In a nutshell, modernization can be many things. It can be everything and anything. So it is always important to find out our own principles to have a fit for purpose modernization. So in this case, we had these high five principles for our mega modernization drive at Achmea. First, as we already saw, we had 70 applications, 50 business, 20 others, so 70 applications. We had to provide this range. All of these applications. Achmea uses this Pega apps for eight brands in Netherlands across five divisions, 10 million customers. So they have to be reliable, they have to be fast, they have to be performant. So being resourceful, being reliable it's a no brainer over there. Being fast nowadays is very key. So for the business owners or the business products, if you're not fast, we are not good. So one way to do that is to of course, adopt DevOps. But the other way is also to increase the reusability so that the lead time is very, very less. And of course, we also want to be recent. We want to go for the latest technology, do not have the gaps anymore and always be recent and relevant. For that we started with adoption of cloud and containers, giving that range, identify that right infrastructure, which was the first step, completely adapt to DevOps, not only in terms of technology, but also the mindset. Security so we needed latest integration patterns, latest security patterns and a complete revamp in that area. As I mentioned, there are a lot of pensions coming in, a lot of claims getting processed. And also there's a bank transactions which are coming in. So we had to do this. Omnichannel, we wanted to give a complete experience, the same experience across all channels for the customer. It might be an external distribution channel, but internal website or a desktop or a mobile, we want to do that. AI, it's more of a personalization over here to find out what is right for the customer and more fit for purpose identification of the software. Again, being recent. Being recent, very much. So at the end of the day, what we did is we created this modernization, let's say washing machine. Every application goes through this journey, comes out as a modernized white application. What we did after our deep dive sessions, or the due diligence is that we created a 30 point or a generic framework on which every application at Achmea can go through and call themselves as a modernized application. So I do not have the entire tango here, but I have a simplified versions for you. We had this pre-migration. So at this moment of time, we had a current state, a target state. So we have to analyze how far is each application from the target state. We use few key principles, data, security, integration, architecture, and the application itself. So we built some in-house tools, which can automatically detect our, for example, dead code or legacy code, which is no more needed. What are the patching which we have to do between the security standards at this current moment and the actual security standards. Upgradeability, what are difficult challenges which we can face and also to adapt cloud? So we did these tools. They automatically run through all these applications. They find it. We did a complete intake on that. And of course there is a planning and estimation for each application. So next what we did is we took this application. So first the infrastructure is provisioned, then the application is taken on 7.3, we remove the dead code or the complete legacy code. At this moment we have a leanest and meanest code, but remember still in the older version of Pega. We put through the upgrade of Pega, and then we created also the internal ESA four, we call it as enterprise security architecture. We comply to that according to that and latest integration patents as well. As part of that, we move from legacy MQ to latest Kafka, for example. And we went for non-standard security standards to, for example, 2 way SSL and all that. Of course, we plan, we had to do a lot of data migration when we had 50 applications. Trust me it's not easy. We did a lift and shift, we created the data again, we did whatnot. And then few applications, like Roderick was mentioning, they were existing since nine years. So we also archived and everything. Whatever we had to do, we did that. Last but not least, CICD or the DevOps is completely needed. We started adapting to Pega deployment manager and every application is already finished or undergoing the automation journey. And we did this in the iterative manner in all environments. After these two steps are finished, we called our applications as modernized applications. But remember the key is these are now in the latest and greatest versions with all the current cutting edge technology, et cetera. But what we learned from before is that if we do not evolve, the latest and greatest will always become redundant again. So for that, what we did is we had processes within ourselves. End of the day, the evolution or the adaption had to be injected into the DNA, had to beinjected into the lifecycle management. For example, when we started this journey, we were in 8.4 or the target was 8.4 of Pega version, and we are already in 8.7, and few weeks we are already in 8.8. Maybe while going back, we will also bang our heads on how to use Gen AI. We also had this goes on for the entire ecosystem, not only just Pega, our infra, our database and everything. Moreover, a complete process, a strict process of governance. For example, we have design authority, which keeps a gatekeeper role on the reusability and everything at Achmea. So this stops us falling to the same trap again. Always being relevant is the main key for this entire revolution. Let's see what we did so far, or we will get so far. In few weeks from now, we will support our existing divisions, life and pension, health, Schade & Inkomen, generic and Achmea Pension Services With the 70 applications, both business and technology. It's quite a bit range. It's amazing how they perform right now. As I said before, we have a robust process to be more relevant and always recent. Resourceful so with the adaption of containers and cloud. So now all the applications or all the divisions have their own segment. We have 15 place hosting segments. And more importantly, we also adapted to sales automation. For example, we also adapted to Pega Robotics and case management. All of these servers demand different, all of these applications demand different kind of infra. So we templatize there. So if you wanted a journey, it's a click of a button and then you have it over there and you can start building your applications. But we'll get there. Completely reliable and fast. One of our first application, which is a policy origination from an external channel. The results are amazing. So the entire origination journey is reduced. The time for that has been reduced by 50%. And the reason all the APIs have been tremendously performing well, I know for a fact that there are APIs which used to respond in two seconds. Now they're doing under one second. Everyone's happy, even the distribution channel is happy, the colleagues are happy, the customers are happy, really fast, really fast. Reusability, let me put in in a different way. If a new division at Achmea wants to onboard their Pega journey, one click of a button, you have infra from being resourceful. Another click of the button, you have the complete CICD pipeline, which can deploy all the 20 plus reusable applications. So for a fact, if an application can use all the 20, 60 to 70% of the application is ready. And all you have to do is identify business flow, build this business flow and click the button of deployment again. So this is what we have achieved. That boosts the speed a lot. In fact after this we are even going to transform into low code and then do whatever. So at this moment of the time, it's completely reducing the lead time to change and boosting the fast speed to production. With this, I would like to take one opportunity to thank our teams back home who are doing this tremendous job. It's amazing success rate. And after that I would like to invite my colleagues on stage if you have any questions. Thank you.

- Do you have any questions, please?

- [Participant 1] Am I audible? So there are two schools of thoughts. When your application becomes old, what generally happens is, should I build it from scratch or should I upgrade it? My question is what was the factor which decided that, okay, let's not build it from scratch or rather I would put it in this way. Let's migrate, let's upgrade and then do the fixes or what's the idea behind that? So which school of thoughts you want?

- Yeah, sure, go ahead.

- So that is not true. We have some cases where we did rebuild. So it all depends on what is the... this is the outcome of the pre-migration step which we did. So if it is too far from the current state, yeah, we did only for one application or two applications. If it is too far, rebuilding made more sense and then we did that.

- [Participant 1] Okay.

- But for others it was not that.

- [Participant 1] Okay.

- [Participant 2] Very insightful presentation. So you talked about the number of end Achmea customers that have been positively impacted by Pega. I think it was 10 million, but I'm assuming those 10 million end customers don't directly interact with the Pega applications. Could you characterize the user population, the Achmea employee base that actually interact directly with Pega? How many of them? And then secondarily, what are the channels by which they interact with the Pega application? Is it web only or do you have multiple form factors by which Pega employees interact with... I'm sorry, Achmea employees interact with Pega?

- So you have to remind me once more with the other part of the question. But we have Pega application that really act as an integration layer. So as Sandeep just explained, for example, we have a bank in the Netherlands that sells our insurance products. For example, car, you just enter a license plate and the type of insurance you want, that's it. It gets sent to us. Pega will collect all the car data, all the customer data, all everything that is needed for our backend system to calculate the premium, get the response back and send it back to the portal of the bank. It's also via website or either an app. So that's both possible. So everyone who has an insurance from this brand of Achmea will use this website or this app and it will go through the Pega integration layer. But we also have a lot of workflow applications. So the question was about the number of users, right? For those, I think the biggest one is HIP with about three to 400 users. So those are actual users sitting at the laptop, desktop, whatever using the Pega application. But there was another part of your question. What was it, sorry?

- [Participant 2] The channels by which they will give the data to Pega, is it web only or do you have a mobile to do that?

- No, we don't do mobile yet, I believe. I believe .

- No, we don't do mobile.

- We don't do mobile. I'll refer to him. We don't do mobile. Does that answer your question?

- [Participant 2] Yes.

- Thank you for it.

- [Participant 3] Okay, first question on the build and deploy phase when you're modernizing the application, are you essentially just taking the existing functionality and recasting it to say Pega 8? Or are you also taking advantage of the new functionalities and the new versions and adding new functionality to the application? Like how do you set the cutoff point for that?

- The second one actually.

- [Participant 3] Yeah.

- But the answer is a little bit in the gray area. For example, we moved to Kafka, we moved to better batch processing capabilities. We moved to better integration capabilities. But at the same time as an evolution iteration we do for adoption of the DX API or constellation at a later part. It's a day two transaction for us.

- [Participant 3] Exactly otherwise then-

- So there was a careful planning which was done on that.

- [Participant 3] Cool. And if I understand correctly, you guys are moving to the cloud, but self-hosted, correct? Not to the Pega cloud?

- No, correct.

- [Participant 3] What was your biggest challenge in getting that to work? The externalized microservices or just finding out the right sort of pod and cluster design or?

- The first thing that pops to my mind, I think is the combination because we also use OpenShift is to have those containers and the Pega platform and Azure run at the same time. I think it is in that configuration or setup of those three layered platforms. I think it wasn't that that took us the most time to understand how that works. Yeah, cool.

- For the challenges, we are also adapting to or creating a template for example, CDH applications. Not the same as case management.

- [Participant 3] Okay, so you come-

- That was one of the biggest challenges.

- [Participant 3] This type of application requires this layout of pods and application, those and whatnot.

- Exactly.

- [Participant 3] Okay, I'm gonna steal that idea too. And one last question, sorry. You're talking about doing upgrades much more frequently, I guess probably not as often as Pega Cloud does. How are you balancing that with the need to do regression testing versus new development? Are you finding any issues with that with your COE teams?

- No, not yet. When we started this entire program, Pega 8.5 was out so we started with 8.5, but we did everything manually as I explained. And one of the things, not only technically, but also in a state of mind, we said to them, you have to automate everything. This train will run and you have to hop on, otherwise you will well get loose. Something like that. So everyone has to start, everyone started with test automation and once you have that the upgrades were seamless. Well, at least so far near too seamless. Nothing to to be compared with what we had before we started this entire program. So now we are on 8.74, looking into 8.8 or wait for Infinity 23 perhaps, let's see. But I don't even think the business know that we have upgraded in this year and a half to all these different versions.

- [Participant 3] Cool. Further questions by the board.

- Thank you.

- [Participant 3] I don't wanna hug your time too much.

- [Participant 4] Thank you for the presentation. Very well, a very nice story. I had a question regarding the drivers for modernization. I saw stuff around technical debt. I saw stuff around end of life. Usually the teams that pay for it are the business. I'd like to understand if you had done any feasibility analysis and options analysis, for example, stay there, move to Pega Cloud, containerize it, and move it. And if there any financial benefits you'd achieve. Because that's the big question. I see a lot of questions here. It's coming back to most of the organization are at a decision point. I'd love to get your insights as to how you convince the business and how you got them to the other line. Because nobody wants to shell out the money while everybody wants to go to the cloud because they're still waiting to see the financial benefits of it.

- We improved the financial state of our applications, but for now the HCL Tech team does most of essential development and our decentralized teams only have to think about functional adjustments to the applications. When we entered the technical debt in a more or less end of end of support situation, we are centralized IT company. We have a one IT vision, one IT strategy, one IT enterprise environment. That's what we all need to comply to. So lifecycle management is mandatory bias and we need to make it as easy for our customers as we can. And you are right when you say they are quite annoyed when they spend too much time lifecycle management and they see other opportunities to solve it, but they don't have the freedom to do that. We have one central IT system and I need to apply to that to comply to that. Financially we are doing better than on-premise environment.

- [Participant 4] Thanks.

- And with regard to the cloud, it is not only with the paper platform, we move to the cloud because it is a one IT architectural decision. All our platforms have to go to the cloud. And they all have to go to the same cloud. So it was a decision taken once within the company.

- We have decided that in two years times we have no on-premise data center anymore. We are in a heavily data center migration. We are going all into that.

- [Participant 4] It's interesting you mentioned you moved to OCP, right? OpenShift, right? As compared to a public cloud. That's why I was wondering the questions around there.

- Yeah, the more Microsoft, we are going to talk own private cloud. What is native in that environment will be working on that cloud and all the rest are working on OpenShift because the Dutch regulator requires us not to be dependent on one cloud only if there happens something, we need to be able to move to another cloud. And that's where OpenShift came in because the containers helps us move over Cloud supplies over.

- [Participant 4] Thank you so much.

- And look at clock, we need to.

- We have five minutes. It's counting down.

- [Participant 5] So it's really, I'm impressed with your migration and everything. It's really great approach. And I saw one of the slide, you mentioned containerization, right? I'm trying to understand how containerization help for Pega application.

- We hosted our applications in the containers.

- [Participant 5] Was it helpful in any ways?

- Yes, as I mentioned, so we have another future near to future roadmap. So we kick off a pod whenever we need extra memory power or infra power, we kick off a pod. The pod is the container itself for us, right? So let's think in that way. So tomorrow if we want to save more money, and then we say that for application A, the nighttime, there are no users which work on there. So we can reduce those in the Pega language, the pods which are dedicated to web user. We are working on that roadmap. So to get more money or save more money from this. So it helps there. That is one. And when we are on peak stages or peak traffic, auto scaling abilities, which is also on short roadmap, if that is enabled, then we will also scale without loss in any performance. So those are two things where we are strongly looking at.

- [Participant 5] Okay, so the scale up and scale down, is it easy to do or how difficult is it the container?

- The templates at this moment, the current situation is a click of a button.

- [Participant 5] One click of a button.

- Is a click of a button.

- [Participant 5] Ah, okay.

- But in the future state or the target state, which we want, this is the day two transaction of the infra journey where we don't want to click a button also. It just happens. We are getting there. Autoscaling, yeah, we are getting there.

- [Participant 5] Okay, that's good. And my second question is, in one of the slide you mentioned like removing dead code, right?

- Yeah.

- [Participant 5] Like what is your approach, what was your approach to remove the dead code and did you follow any patterns to identify the dead code?

- Yeah, we created an in-house tool, which identifies dead code for each application. Of course it was not easy, but over a period of time we evolved and we created almost 90% correct tool or even 100% that gives us a list of rules, for example, which are not used or legacy implementation, et cetera. It all depends on how you're configuring that tool. And that was run through all the applications.

- [Participant 5] Okay, I got you.

- It is for sale the tool. I was just gonna ask.

- Both.

- I'll take a commission anyway, so.

- [Participant 5] I think I'm good, thank you.

- Thank you.

- Thank you.

- [Participant 6] So what are the major challenges you have faced moving from on-prem to cloud and especially making it as a containerization? So do you experience any major challenges or it's straightforward with Pega being on OpenShift?

- I'll take. So as I mentioned previously, the challenge is to identify the right, for example, memory or right configurations for each type of application before that one step back, identifying the right tooling for this also. So why only OpenShift? Why only this? And after that, how can we scale up to the demands of, for example, the CDH applications or sales automation applications or completely Pega Robotics, right? So it's way different from all this. So the challenge was identifying a configuration or a tech stack, which is reusable across for all this, which is generic to all this. That was the biggest challenge. And of course the adaption of containers to Pega. There will be some challenges, but not big as the other one.

- [Participant 6] There are no challenges deploying Pega as a containers at all, or?

- It's the one time problem to solve. There were challenges, but as I mentioned, the biggest challenges was to identify a generic structure for all the demands which we have.

- [Participant 6] And that's it from me, thank you.

- Thank you.

- [Participant 7] So what were the skills required for these projects, right? Whole modernization apart from the regular Pega skillset, did you have any other skill sets in this modernization journey?

- Let me put in that way. I think we do, for example, modernization is not only Pega, right? It's enabling the entire usability of Pega. So Pega is an unsaid skill, so let's keep this side adapting to DevOps. That's a big milestone by itself, right? So Achmea adapted to, for example, safe agile in the way of working. At the same time deployment manager and using repositories from Azure and test automation, et cetera like that. So both process and the technology added skills were required in this project in this entire journey.

- Yeah, took a lot of discussions or meetings to put it in a positive way. At first everything was done manually. So the ops guy said, yeah, this application is fine enough and it is allowed to migrate to production. Same for the business application owners. Now we wanted everything to be automated. So we ask them what is the explicit knowledge that we should check the application upon, so it can automatically detect whether it's okay and go to production. Of course then you get in some area where implicit knowledge and experience somehow has to be explicitly written down for us to understand how the system should react to certain circumstances of the application. So it really also required a change of thinking and being able to be flexible because we were taking work away from some people because it would now be automated. So I think that the person itself also needs to be very flexible and understand the end goal. So we took a lot of meetings to understanding, explaining to them what this was about. It was not only a technical migration, but we also explained to them, we will help you, you will get work faster done. So you can focus on the important things. Not only check some Excel checklist and then say proof, now the system can do this. So you can focus on important or fun work for you to do.