PegaWorld iNspire 2024: Revolutionizing Workflow Automation: The Impact Of Pega GenAI™ In Pega Infinity By Capgemini

It’s a pivotal moment in business operations. Enterprises are being forced to become more efficient while the latest GenAI and automation tech is evolving fast. The good news is Pega moves even faster.

Dive into the findings of a new impact analysis conducted by Capgemini, revealing that Pega Infinity, bolstered by its cutting-edge AI capabilities, achieves a remarkable speed — 7.8 times quicker than the traditional development approach.

Be part of this insightful session to unpack the methodology of the study and understand the comparative performance of Pega and Java in crucial areas such as workflow automation, UX/UI development, among others.

Transcript:

- ♪ I won't ♪ ♪ I won't break ♪ ♪ Oh, oh ♪

- All right everybody, let's get rolling. Well, thank you for joining us for Revolutionizing Workflow Automation: The Impact of Pega GenAI In Pega Infinity by Capgemini. I think some things you might've heard about, GenAI and Pega Infinity. My name is Anthony Abdulla, a senior director of product marketing for Pegasystems. And more importantly, I'm joined here by Dinesh Karanam.

- Thank you.

- Business process and augmented service leader for North America, Financial Services at Capgemini. And Dinesh and team has done an amazing job diving into our Pega Infinity release, and all the productivity benefits across pretty much the entire software development lifecycle. So Dinesh is gonna give-

- Thank you.

- a little context for the study. I'm gonna give a little bit more context and then we're gonna dive into the details of all the findings and all the goodness across things. So Dinesh, would you like to tell us about it?

- Thank you Anthony. Good afternoon everyone. Because it's a GenAI conference and also more focused on GenAI, I will talk about it. What is GenAI perspective from Cap? Before that, I'm from Capgemini. I manage the BPM practice for North America. Capgemini is a 360,000 people organization and we work across the globe, various countries, and very major complex implementations for almost every client you can see offered on the globe. Okay. With that, on the GenAI perspective, Capgemini's side, we were recognized as number one in the generative AI implementer. So we are proud of it and you can see most of the numbers what it is. We have 30,000 people who completely works in generative AI implementations and the people who knows most of these concepts. Okay? So these are the various things which we have it internally as part of the generative AI implementations. Internally, as part of the generative AI CoE, we build various templates and industry solutions where we can able to implement faster into the transformations. Related with Pega, when 23.1 was released, so we wanted to see... We did this study almost in 2014 with the older versions. So we took that particular study and also we wanted to see what is there in 23.1, specific to generative AI focus of it. And main focus is, another thing which we did was mainly focusing, thinking through what can be done or what features can improve the productivity of the developer. Rather than thinking about how we capture the requirements, those things. I will delve into the details of it. The process starts from the design to the implementation. That is what the study has been done. Okay? Then giving it to Anthony to talk about it, the next steps.

- Yeah, as mentioned, just wanna provide a little bit more context before we dive into the details. I think it should be no secret to many of us in the room that the demand for developers is increasing all the time. This stat from the U.S. Bureau of Labor Statistics is a bit staggering, but with many studies, the numbers kind of tell the same story, that the gap is growing, the proliferation of technologies is just making it that much more demanding for developers. And it just kind of brings to the point in terms of what enterprises could be doing in terms of, you know, gaining more revenue, innovating faster if they can focus on optimizing developers and developer productivity. There is a shining light here. There are platforms that are specialized in this and Pega is one of those platforms, and we look forward to just giving some details of how we are optimizing development in the long term in this complex landscape. And speaking of this complex landscape, we have a lot of developer tools out there. Java continues to be a leading developer framework that has been used for many, many years, and for good reason. It's very enterprise grade. It's been reliable. It's been stable. Do we have any Java developers in the room with us today? All right, got a couple. Do we have others that know what Java is? Others that drink Java or? it is the afternoon after all. But it's proliferated. I think Java, for many, it makes sense in terms of it was a write once, kind of deploy everywhere framework that's been used for many, many years. And it's got a great ecosystem, lots of frameworks and libraries. But with everything, you know, Java, especially at enterprise scale and custom Java development is complex and it can cause some headaches, and we'll detail some of those headaches now. Some of those include time and speed. Projects often drag. Long timelines. And it can be complicated with the amount of needs as we're going. Maintenance and support. Significant resources, especially at enterprise scale, can be needed to do these projects. Quality insurance and testing just requires more and more, more skilled workers to do more skilled projects. Plus the need for training, resource allocation, being able to continually innovate is another just factor in there. And we see that scaling challenges, especially at the enterprise scale, it can be cumbersome at times, especially with lots of things that we are talking about today, in terms of adding integrations and so on and so forth. That obviously opens up the risk of security and compliance issues as you're scaling. Having open frameworks, especially as we're proliferating today's bots and AI and GenAI and all the other connectivity issues that we may have, there's a lot of security risk that could be involved there. And finally, just innovation and upkeep. As you're going, you could be relying on legacy development teams to maintain things, and depending on their documentation, that might just cause you issues as you're progressing going forward. So there's just a lot to think about as you're doing custom development projects. They can work out great, but as you're doing end-to-end ones, there's a lot of risks to consider. But as we're considering those risks, let's talk about the potential of... Imagine if you had a platform that could unite development and optimize those. Oh, there we go. To accelerate development, optimize productivity, and really kinda streamline that process and that's very much what we're talking about today. I think you heard about Alan's talk about this this morning, and if you're no stranger to Pega, you're no stranger to our center-out mythology in terms of being able to, you know, connect all your data sources, connect all your channels, all your systems, have a unified intake to the platform, being able to connect all your integrations, and being able to streamline those into one center and make those changes from the center-out, which is what we talk about. And being able to reuse and scale at an enterprise-grade level. The Layer Cake, I'm sure you've heard of that if you're familiar with Pega, in terms of being able to customize for geographies and less risk as you're doing those complex scales as regulations and rules change and you need to specify your units of scale. And, of course, having a platform with real-time decisioning and automation built-in. That could be anything from our, you know, one-to-one CDH decisioning engine, which has been leading over the last few years; from anything to Process AI, which we'll touch about today in the keynotes; in terms of optimizing your workflow processes and just kinda optimizing how work gets done within your organization. And having that all with the foundation of enterprise, security, and governance. Some keywords you see there is App Factory. That's kind of our governance portal for low-code apps within the system to ensure that reusable components and applications can be reused by business users and developers. And Process Fabric, something that you can use to orchestrate all your apps across the enterprise and ensure that you have visibility. Managers can see how apps are being used, who's using the apps, where work is taking place. Employees have an understanding of what their next best work is. So having that consistency across the board. And of course, what we're gonna talk about today is the benefits of all these. All the things you just saw and how that's impacted the entire application development cycle. Dinesh is gonna get into why Pega is almost eight times faster than a custom development solution using Java. So with that, don't wanna spoil all the fantastic numbers you're gonna hear, but really gonna cover a large swath of the software development lifecycle, and hopefully this touches upon areas and overlaps areas that are of interest to you.

- So Perfect. Thank you, Anthony. So the first one, when we started this one to think through it, we wanted to pick a complex use case, not like taking a generic one and try to build the application and show what's the productivity. We picked up in the financial services on the banking side, the loan origination, which was a more complex and also more integrations. We also implemented like KYC, all those things, whoever knows the financial services side. So we picked up a complex use case after filtering some of the things, okay? Then the first thing, what is the object to offer? When we went through it, particular one, we wanted to see how the productivity changes from a custom application to using a Pega type of platforms, okay? Methodology perspective. Just to eliminate some of the variables, we also used Agile as well as the regular iterative methodology. So we did eight times the study to make sure we are getting the right numbers or what exactly the impact of it. It's not like one time done and you get the numbers and move on. Four times we did the Agile, and four times we used a iterative method to build those particular application, okay? The last one, you can see in the use case I already mentioned, loan origination is the one. This is the use case we picked up. And on the financial services side, anybody's familiar? You can see how many integrations this particular flow will have it. We had total almost 17 integration points within the application from start to end, and total number of screens are almost 23 screens, independent screens. And again, you will have some popups and all those things, ignoring those ones. The third one is again, we integrated the KYC, complete integration into the platform, okay? That means we did not use the KYC framework from Pega. We built that KYC framework to see how it can able to scale. If at all a Java application, somebody is trying to build an application in KYC, how much time it will take. So that's what we try to use it. So it's pure platform, used Pega Platform, entire application was built on top of it. There was no framework has been used from Pega and .NET, okay? So what did we do next? Let me... So all these things, when we started doing the study of it, Pega Blueprint was pretty new, so it was not even released. We started the study and at the end of the study, Pega Blueprint was released. So what we did even before, the requirements process gathering perspective, every organization will have their own way of gathering the requirements, either document or ALM or Jira, whatever the process is. So we wanted to avoid that. So what we did was we did not do any Pega implementation for the requirements gathering, okay? Requirements gathered specific to Java application on this one, both are same. So we did not took the element of requirements gathering. That means the Blueprint was not implemented for the study at the beginning, okay? I just wanted to make sure because everybody thinks about it after today's conference. So have you implemented the Blueprint and it'll import? So for this particular study, Blueprint was not implemented, okay? The second thing, all the rest of the things, whatever we have it in 24.1, using the Autopilot as well as automation of it, the GenAI Coach, each of those components, what is released in 24.1 was incorporated as part of the implementation. So that means that from the Knowledge Buddy, we incorporated with the document management system to pull the latest help information as well as the internet perspective to just check what other information we can able to collate. So Knowledge Buddy was in integrated, and also you can see the Autopilot, the testing perspective, automate, we use that feature as part of the implementation, except the Blueprint. All has been utilized in the overall study while we build the platform, okay? What did we do on the Java perspective? Exactly the same thing on the design, same whatever you remember, it's building the RUP models and everything, class, structures, everything we built on the Java side to compare apples to apples, okay? So that's under design side. When we get into the development, again, development side, we used an Eclipse tool, and Eclipse has a lot of plugins where you can able to use it, which is a free resource which available on the market. So Eclipse was a platform which is used as an IDE to build the application, along with the Tomcat as the server, okay? That is the same Tomcat server has been used here for the Pega Platform. So just to make sure the scalability perspective, both can able to scale for it, okay? so when we did the complete comparative study, building the application from start to end, all of this, you can see lot of numbers has been... We spent close to 3 1/2 month to build all this, eight cycles, validating every number, every screen, what we are doing. And the Constellation part of the implementation has been done using Constellation, but not the entire UI is used for the Constellation side. Okay? So that is again because if you use it on Java, we use React, React UI. Using the JSP in some places, and some places use the Servlets for it. Okay, that was on the Java perspective. Whereas on Pega side, we are completely using the Constellation wherever it is required, okay? Not like completely done in Constellation as is. So the biggest numbers where you can see here. Okay, the biggest improvement wherever you can able to find out here. When you build the application, when you take it from the design to the implementation of it, the complete model-driven components, whatever we can able to build in Pega, the same thing if you want to do it in Java, it takes a lot of time. Most of you guys, anybody has done in the custom development, you can see the same page I need to build, I need to build the Data Object, Database perspective. Then I need to build the services. All that architecture is a complete microservices architecture. The same APIs has been used even for Pega. The Java application, however they integrate with KYC invocation of the various data elements, the same APIs or the microservices are integrated with Pega, okay? So there is no separate API for Java. There is no separate API for Pega Platform. Both are exactly the same. Then when you get into the Pega perspective, when you take the current application, integrating the Swaggers into the Pega, you can see the complete data model is created as part of the GenAI now. As of today, what you have seen in current implementation. You can able to take a Swagger, import it into the service, the entire import is automatically done. Whereas when we did the study, the microservice was built separately, and as part of the overall development and integrated as part of the REST APIs, okay? Just to give you some of the pointers, just comparing apples to apples software, okay? Then the second one is the technology adoption perspective. When you take the entire application, how fast you can able to deploy this application. So from initiation to the end, whatever the screens, you have there. Now I'm going to make a change. I have an existing KYC application. Now there is a new rule comes in, what am I going to do with that? How I'm going to introduce that particular change on Java side as well as the Pega Platform? When you introduce a new change, think about it on Java, even though you have the complete CI/CD pipelines, everything is established, you made a change, you have to go through all those things again. The test cases, everything the same. Whereas on Pega Platform perspective, you have certain data elements that automatically creates the mapping. Wherever you can able to do the data object mapping to the services. All those things, we used all the latest features to improve, okay? And again, Java, it's same REST services. Comparing to that, there are three things on the integration complexities we introduced in it. The file imports. So most of the financial organizations, they still use the file imports and exports, Excel exports and Excel imports, all of this. So for certain data for the customers, we use the same feature here. Taking the entire list of customers, uploading it to the Excel through the utilities. On the same Pega perspective, you take that, use the data transformation, and transform that entire data and display the elements. Those are the two biggest things you can see, comparison of those two, okay?

- And just for some context for what's on the screen right now. For requirement analysis, the one productivity increase, what's the context there that you can see?

- So for the requirements, the reason I mentioned it's one, the reason is, again, we left it like the requirements are totally two different ways you can able to capture, even though Pega can capture in one way or regular applications. We don't want to get into the nitty-gritties of... Debate of, okay, I'm using ALM, I'm uploading this particular use case or a user story versus somebody else is capturing as a use case. So a lot of debate comes into that, so hence we completely left that particular requirements, not to estimate how much time it'll take each use case to be written. So we assumed use case is written in both the ways, it's same, okay? So the use case requirements, not captured at that point of time, okay? Whereas the integration requirements, wherever you have the services, everything, those were delivered as an integration architecture documents, okay? For both the applications because integration will not change whether it is Pega or Java, so it is same. Whereas the actual true requirements when you write it, the business requirements objectives are same whereas if you get into the implementation details, Pega expects a workflow is like your primary flow, secondary flow, and exceptional flows, like that. Whereas on Java perspective, you need to write all the rules, define each of those ones, okay? Hence we left the requirements as is. Any questions? So this is more deeper details into the each of the area in every application. These are all the various areas we go through it, right? The first one is actually the... Sorry, I'll just... I'll click through it first. Okay, so for each of the elements, wherever you can see it, taking it from the step one in every implementation, either it's custom development or Pega Platform development, everything from start to end, all these steps, whatever, was measured. At every step you can see various numbers. We have highlighted in blue, right? I don't wanna go through each number. So for every number has been measured, again as I said, eight times with two different methodologies, and I will talk about it what type of resources we deployed for this application to be done as a productive study, okay? So the first thing was while we started this one, the similar type of skill sets has been picked on the Java as well as on the Pega Platform. The experience perspective, you will have an LSA here or you will have a JDE architect there. So that kind of skillsets also, we matched it so that we can able to do the exact comparison for it, okay? These are all the various metrics which we'll go through all the adaptability from start to end of it, okay?

- I have to ask, were there any surprises on any of these areas for you in terms of Java versus Pega in the development process?

- The big surprise is the data mapping. So whenever you are doing the data mappings on custom development, you have to do the complete code-driven mappings. So you have to take a class and you have to import it and map each of those ones or write the code for it. Whereas on Pega perspective, you have seen even in the demos, you can able to drag and drop or map each of those ones. So that's one of the surprise area when we went through it, okay? The second surprise area I can say is the deployment. Almost in Pega Platform, nothing is called deployment, right? You can take a end product ZIP file, just drop it into the next environment. Whereas on Java you have to make sure everything has to be in the CI/CD pipelines, okay? That was the second. Always we have multiple hiccups. One class is missing in one place. Our version is different, so you have the same and the build will fail. So whereas on PEGA it's one JAR file... Sorry, one ZIP, upload it and... No, sorry, extract it, drop it into the next environment, you are done with it. Again in the microservices, we use the same CI/CD pipeline to push the code as well as to deploy it into the end environments. Okay? So again, for build perspective, how complex the application we pick it, you can see we took it two multi-languages. So one is in the Spanish and second one is in the English. Okay? So that was also introduced. So this is the entire flow of it. Again, Pega always pushes for the Layer Cake, right? You can see how complex the application was built. The entire Layer Cake has been built for... Scratched almost every layer of it. So two languages has been introduced. You can able to introduce a third one, but again, why more? Right? So just I'll click through this one. You'll see most of the data, how the overall Layer Cake is here. So this is for the overall loan origination, start to end of it. If you take that picture, you'll know it, everything, all steps and stages has been defined. Even you can try on the Blueprint today, it'll give you the exact... I won't say exact, maybe similar steps of it, okay?

- And then that total cost of ownership number taking consideration the reuse for future work workflows or was it?

- Correct. So that is where the second one was. After we build the application, we introduced multiple changes. As I mentioned, one is invoking this particular application through web. The second one is maybe somebody's having a mobile application and they want to access it. And now you introduce a change, how fast that particular change can reflect on both the sides. If it is on the same on Java, you have to do two different applications. iOS app or Android app or maybe just regular app or the RJS, right? So those are all the multiple things you can see how you can able to do that faster. That's where you'll get the TCO at the end of the day, okay? So the last one is, again, going through the AI-powered platform. This is the new norm after doing all of these things in 24.1. A new norm, we gave it like an AI-driven development. Because most of the components in Pega Platform is almost driven by AI components, either from the Blueprint or GenAI Coach or Knowledge Buddy. Everything is AI-driven. So we named it as like a AI-driven development. So anytime if you're hearing that, so it's like all the components from AI, each of the components are driving the development. So what are we getting here? The first one is accelerated development. Because the platform is so adaptable, you can able to see accelerating the complete development of it. You can able to speed up anytime you want to do the design or integration or introduce a change. The second one, enhancing quality. Because there are new AI components introduced in 24.1 as well as the existing in 23. Those things are automatically checking your quality of the implementation. You don't need to do if you... Any of the Java GUIs, you guys can think about it. We used to do all the code quality, right? Whether I have written capital letters versus small letters or camel case, all of that, okay? All those things you can drive it as a rules right now, and in Pega there is an AI tool which automatically checks it and tells you directly. When you're creating the rule, it will tell you, "Okay, hey, you are not following the standard." So okay, the next one again, I already spoke about it. Okay. So if you see each of the areas where you can able to go through it, like collaboration is another one. We have all the integrated tools where you can able to run through all the collaboration element, every place of it, right? Then the guided development. Okay. Anytime if you are building certain rules, you can define the components and the Pega Platform will tell you exactly whether you are following certain steps or not following certain steps, okay? If you used any Knowledge Buddy or even the automate, it will tell you the same thing. The Coach. Okay. So the final summary perspective, you can see the overall what we got, it's total numbers, whatever the numbers you have seen before from the requirements to the end, everything has been driven up to the minute level of details, from the screen development to the component development to the integration and then the data model. Everything has been documented in the system as well to go through all the details. Okay, so finally when you go through it, it is 7.8 times. We call it probably as a day's work in an hour, okay? So if you are building a custom application, if you are spending a day of effort, you can able to do it in an hour in Pega Platform, okay? So that's how all these components are integrated and how you can able to speed up each of the stage of it, okay? And before I go there, we had a 23.1 released white paper which was released in February, February end. And today we are releasing 24.1, which is an updated white paper and it will be done after this session. So you guys will see even 24.1, enter all the new features, what is done by Pega, introduced today, whatever you see in the innovation lab, we had an access to that platform almost three months back. So we used that one to deploy all of it. So for all the materials are available here, so if you want to scan it, you can see every document, whatever we are talking right now, and all those things are available at this barcode. Okay.

- All right.

- Okay, with that I don't want to take too much of time going through the numbers so we'll take more questions because there will be multiple questions will come up, so we kept 15 minutes for the questions. Any questions from anyone?

- [Audience Member 1] I'm sorry.

- [Moderator] So I have a handheld mic here 'cause I had a feeling that you might not come up to the stands. So there are two stands here for questions. Thank you, Dinesh and Anthony.

- This one.

- [Moderator] There are two stands here, but I'll have the handheld as well, so.

- All right. Appreciate it. First of all, thank you so much. So you compared two applications, right? Built both on Pega as well as Java. Have you also considered the licensing and all of that?

- Yes.

- When you put that into place, how does Pega fare in terms of, you know, building it on Pega versus Java?

- Yeah, that is how we estimated the total cost of ownership. So for Pega perspective, you need to have the licensing cost whereas on the Java side, you can use a free almost... I would say except the infrastructure, rest of the things you can able to use the open sources.

- [Audience Member 1] Right. Right.

- So that's how it was compared. Answer is yes.

- [Audience Member 1] Yeah, thank you.

- [Audience Member 2] I saw in couple of places where you have mentioned that security compliance, it was 30% faster. How exactly because the security compliance-related rules and everything, it requires a bit of customization even from a pickup perspective. You don't have ODB features for that. So can you just elaborate a bit on that?

- Some of the things actually were introduced in 24.1, when you build it in Java, even I'm just giving an example of HTTPS URL. If you want to publish that URL, it takes lot of time. You need to have a certificate, you need to do lot of things before you implement plus use the internal standards, what need to be implemented for custom side. And Pega Platform, the main URL is only the one you need to take care, right? So this is all internal or if you are putting in cloud, cloud-to-cloud communication or cloud-to-internal communication. Whereas on Java perspective, every server communication need to be defined and also need to be opened up the ports. Whereas here, server-to-server versus every URL by URL. That's the biggest comparison. One security feature I can say. The second one, LDAP integration, you are exactly right. Because Pega doesn't give you directly LDAP integration. So that one we kept it as both the sides we build the LDAP components. So those things are not... You can say it's a similar implementation of it.

- [Audience Member 2] Even from a business perspective...

- By this.

- [Audience Member 2] Yeah, even from a business perspective, the logic defined for these compliance-related validations, it's more customized. It's not something which Pega can provide from a technology perspective. So that was my question around, like, how are you saving this 30% percent?

- I mean, it's not much difference on it, but the biggest difference is I can say within the components perspective, what is there, it's all secured versus each component or each box, what you put it in the architecture of custom development need to be built as a secured one. Another one is the compliance, as you mentioned. Everything you are going through the case or the step is tracked within the product. You can see what step it is going on, who logged in, what was changed. The same thing, assume that you want to implement in custom, how much time it will take. Just one example, it's just a compliance of it, right? So those are the kind of things we considered as part of the development. Okay. Thank you.

- [Audience Member 3] So, oh. First, thank you very much for the-

- Welcome.

- [Audience Member 3] For a great study. I had a question. You mentioned on quite a few occasions that you did this eight times. What was the thinking behind this? Why did you do it? Was it a specific method you followed?

- The main reason for doing multiple times because we don't want to do it once and say, "Okay, the numbers are exactly the same." So when we compared it multiple times, if there is a variation, we picked it, like, if there is a variation of more than 5% of effort. If you are building a component first time and then you are building second time, there is 10 hours versus 15 hours, then we dig deeper into that. Why first time it took 10 hours versus second time is 15 hours, okay? And again, when we took the numbers, we took the lower numbers, not average, not higher number, because if I'm always taking the higher number, then there is no point of it doing the second time of it. So not averages, always a lower number has been taken to derive the numbers. If I took average or that then it will be nine plus. So we don't want to get into that. Any other questions?

- [Audience Member 4] So my question is from a happy path perspective, right? Probably the combined study that you did is accurate, but, you know, there could be some custom components sometimes in Pega that are not offered out of the box. And if you had to implement a, you know, custom component like that, borrowed from outside, which is not available out of the box, then the implementation of Pega could be more difficult there in open source, right? So did you include any of such factors, right? And try to reduce that, you know, the numbers that you gave Pega. Like, did you consider anything like that out of the happy path?

- Okay, that's the reason you saw KYC application. So the KYC is most of the times very complex and it doesn't come up with out of the box you can able to implement the features. Second thing, any Pega implementation, whatever I divert or my company says it, we always ask the teams to stay away from the customization. You may need to convince the business to see how much can be done. But by doing the customization, you are making more damage to the business itself. The second thing from the customization side, of course we have some of the components specific to the integrations, external integrations where we had to do the custom implementation. We did that even in Pega. Writing a Java script to your... If you are looking for that answer. We did the Java scripting as well within the Pega to handle certain things. We also reported back to Pega saying that, "Okay, that's not the right way to do it." But some other alternatives, maybe in 25.1 they'll come up with something. But answer your question, yes, we did the customization using JavaScript in some areas.

- [Audience Member 4] Thank you.

- Any other questions?

- One down the front here. Ooh, two down the front. Can I take the one on the right first?

- [Audience Member 5] During your study, did you consider the Java part of the study also could be using GenAI models for-

- Yeah.

- Because that's kind of very common now, and not just the Eclipse IDE platform.

- I was expecting this question, so. So we used the ChatGPT to generate certain code of it. That's what one of the scenarios what we did. You ask the same thing, whatever in Pega you can ask today, right? Generate an application for this. The same thing, you go into ChatGPT, you ask that question, and it'll give you a certain Java code. We took the Java code and it took a lot of time to figure it out what is written. It will give you multiple components you can able to give, "I need to have a Java loan origination application with Java integrated with something else." It will give you all the Java code. To understand what it has generated, it takes a lot of time. So that time has been considered to get through those component. How I'm going to take it? It spits out maybe a hundred classes. So what are those hundred classes? I can't take all those hundred and drop it into the different server. So that was also thought for it.

- [Audience Member 5] Thank you.

- And I think that goes to just Pega overall too because Pega takes in consideration years of, you know, case management and development and workflows over that.

- I have a question. You mentioned that you can do the development at 7.8 times faster than Java. I know I've seen this, all the statistics recently you published. You mentioned that you didn't use Blueprint. Was there any reason to exclude it? Because Blueprint basically enhances the capabilities, can generate automatically, but in reality would show better than 7.8 times, right?

- No, Blueprint was not used in this.

- [Audience Member 6] Is there any specific reason?

- The reason was when we completed the study, at end of the study before releasing, I would say maybe three or four days before Blueprint was released.

- Oh.

- For 24.1. That's reason number one. Reason number two, again, not to take the thunder from Pega. You can use Blueprint for a new application. You cannot use Blueprint for an existing application to implement. You can document all the processes, whatever you have it today. But by using a Blueprint application, I can't go and update an existing Pega application. Most of the Pega guys can able to recognize it. So that is the two reasons we don't want to say, when I'm introducing a change, am I going to use Blueprint or am I going to go into the Pega application and introduce a change? We thought the second approach is better than building the Blueprint and importing back.

- [Audience Member 6] Is it verified by any other agency or independent agencies that your findings are correct? If yes-

- So internally, the Pega standards was validated, and internal within Cap, we have a stringent process. We treat like there is an review processes goes through it. So not like outside of Capgemini, to answer your question.

- [Audience Member 6] Okay, you would definitely see your counterclaim from other competitors that, you know, their product is 15 times faster than-

- Definitely.

- So-

- Absolutely.

- [Audience Member 6] Okay, thank you.

- And I will give a shout out to the Blueprint roadmap because modifying existing applications is part of the roadmap, and Pega has changed a lot in that way, and they're taking feedback. So as you have feedback from Blueprint and even development APP Studio, they're coming out with new features in Blueprint on a weekly basis now. So it's not the Pega of years past in terms of release cycles. So your feedback is being incorporated quickly.

- You know, just to add to that. importing BPMN was initiated as part of the study, even though we were not using BPMN, that was one of the concept, thinking like assume that there is a competitor application built-in workflow, so how I can able to take that BPM and drop it into Pega. So this may be another channel we went through. Second one is the collaboration, even though that was in the roadmap, we were asking like, "Okay, we build the Blueprint, how am I going to share that Blueprint with somebody else in my team? Is my team member also need to rebuild the entire Blueprint or can they able to make the changes?" So, I mean, Blueprint is also evolving but again maybe in future, they can come back and they introduce a change for it. Sorry.

- [Audience Member 7] Right, kinda two questions here. The first one is, would you expect that 7.8 multiplier to extend to... I mean, is it specific to Java? If you did in Go or Node.js, would do you expect a similar multiplier? And secondly, how did the non-functionals compare? Things like load handling, performance latency, et cetera?

- Can you repeat your first question? Sorry.

- [Audience Member 7] The first part?

- Yeah.

- Yeah. Would you get that same 7.8X if you use something aside from Java? Say Node.js, Go, Rust, et cetera?

- I would say definitely difficult. But yeah, if I want to do it and to target this number, now I know the number, 7.8. Whatever I need to build it in Java, if you challenge to some very good Java developer, they may come close to it. But again, it's all again how you are going to execute it, right? Because I know the number now, so. I think you had a second question.

- [Audience Member 7] Second part is just around the resulting app, the performance latency, all the non-functionals, were they comparable between the custom and Pega generated?

- I mean, we didn't do the rigorous performance test but it's close to 15 concurrent users was tested multiple times and then we went up to 87 users. That was per Tomcat server. So that's where we stopped it on.

- [Moderator] I think we might have time for one more question. I think there was a gentleman over here I saw. Yes.

- [Audience Member 8] Sorry, I missed the initial part of the conversation, so what kind of application you used for this comparison?

- There's a loan origination application integrated with one.

- Okay, so all the business rules-

- Mm-hmm.

- [Audience Member 8] Be its workflow or the domain-related.

- Correct.

- [Audience Member 8] Were they declaratively coded in Java or it was done in the-

- For Java application, we built it as part of the business objects. And within the business objects, all the rules has been written as a Java code.

- [Audience Member 8] As a Java code rather than doing in declaratively?

- Correct, whereas on Pega-

- [Audience Member 8] So you haven't used any rule in general or anything? Any other rule engine? Okay.

- Because-

- They are all coded in Java.

- I think it goes back to his question, right?

- Yeah. Similar.

- If I know right now, can I use JRules to integrate with this? Your answer is yes. Can I able to use maybe third party, I'm just picking maybe Pega itself as a rules engine, integrate with Java? Of course the number will go up.

- [Audience Member 8] Yeah, I got it. Yeah, that's that-

- It completely-

- initial part I missed it.

- gave to the Java platform.

- [Audience Member 8] Wonderful. Thank you.

- [Moderator] Thank you, so I know we have to let you all get

- So I'm just-

- [Moderator] to other sessions, even though this was really exciting. I think we can take one more question 'cause he's very excited to ask it, but can I just say one more thing before you ask your question? Booth 22 is where Capgemini is, so if you wanna go to the booth, Dinesh will be at the booth. Anthony is also from Pega and he can help you with any questions after this session as well. So I just wanted to make sure. I'll let you ask your question.

- And then on the GenAI front, the vision and roadmap panel tomorrow is gonna be filled with product leadership giving our future in GenAI. So if you're interested in that, I... You're good.

- Well first of all, thank you both for the insight of your assessment, but I have one question. Someone already asked for the licensing or not, but did you also consider the resource cost, like, to develop and also to maintain-

- Yeah.

- because the cost is obviously the... It's expensive when you consider Pega versus Java.

- Yeah, there is two things on that one. As I mentioned, the team perspective, am I not be able to say how many people are there. But again, generally, when we go for a project, we estimate Pega application and Java application. Capgemini does both. Custom as well as the Pega side. The same templates has been used for building the estimation on Java as well as on the Pega. That's the effort. So that means it's automatically the cost also, we derive it, okay. That is a cost perspective. So the answer is yes, but number of people, I don't remember it right now. It's close to... We had seven members to 20 members in the peak time of it to build the entire application.

- Thank you.

- Yeah. Okay. Any other questions? Thank you all. Thanks for coming here and pleased to come out.

- Oh, thank you. Thank you, Dinesh.

- Thank you.

- That was good. ♪ Oh ♪ ♪ I won't break ♪