PegaWorld iNspire 2024: Accelerating the ROI of Low Code Through Enterprise Reuse

Can you all hear me? Okay. Beautiful. My name is Paul Barnes. Uh, I've got, uh, Marko and Krish on here. We're going to do a quick introduction of ourselves, and then we'll get started. Again, I'm Paul, I've been with Pega about 13 years. I spent the first ten years as a practice lead in our comms practice. Verizon was one of my big customers.

Uh, a couple of years back, I got a little bored with what I was doing and moved over to our corporate strategy team focused on business excellence. And my core function at Pega is to look at how our clients are adopting our latest and greatest technology. Um, Constellation is one of the big areas of focus. I see Sean in the back room there. Um, enterprise reuse? Uh App Studio. Process AI Process Mining. All of these things are in the remit. We're here today to talk about modular enterprise reuse.

And we're going to be presenting some concepts around both Pega capabilities as well as approaches to maximize enterprise reuse. And these two gentlemen are going to be talking about practical know how and some client ROI examples that we achieved with it. So Krish and Marco. Yep. Marco Duizer I'm technical Solutions director in Pega six years working for Pega. Now the last two years basically working on the Lisbon project. Adopting Constellation is the first one and developing basically the modular approach and basically prototyping that. And that's also available now in our websites. Basically on the Academy.

Myself, Krishna, I'm working as a lead solution architect with Aaseya. I overall 14 years of experience developing Pega application. Last couple of years working with Marco. Building Constellation application for Leaseplan. Okay. All right. Let's get started. So for our agenda today, I want to talk a little about how best practices around reuse are evolving, particularly as we look at the advent of GenAI. We want to look a little bit at our enterprise reuse roadmap, and then we're going to hand it over to these two to talk about the basics of modular enterprise reuse, some design principles for building for enterprise reuse, and end up with some client ROI stories.

So jumping straight into it, you heard Alan talk about this on the stage yesterday. You know, we had a promise at the end of last year to double our, uh, our productivity, um, with our with our development resources. AI is certainly changing everything when we think about that. Um, so, you know, the big question here is how does enterprise reuse fit into that GenAI story? Um, so let's take a little bit of a second here to recast back on what we mean when we talk about modern enterprise reuse and in Pega. It's really about building our reusable blocks in Dev Studio and assembling them in App Studio in a way that drives interoperability between applications. Um, enables updatability of those modules so that they're not dependent on a full system update in order to get the latest and greatest functionality that you're rolling out. Configurability. So that you can, um, put the, uh, the power in the hands of the business users or business architect system architects that aren't necessarily at the SSA or SSA level and still drive rapid change agility into the platform.

Um, modular, because we want to move away from monolithic applications, move to more of that microservices architecture. Uh, and finally, a governed approach where you can have distributed, distributed teams across the organization, working in a fusion team model with blended resources between business and it, really collaborating together effectively between your dev studio authoring experience and your App Studio authoring experience. So when we talk about that 50%, I'm sorry that that two x productivity improvement for our development resources, it's really taking these three pillars of product capabilities around enterprise reuse, center out, business architecture or situational Layer Cake relevant records, which is a way to really surface those smart shapes and reusable elements into your authoring experience. And App Studio, as well as the governance capabilities that we have with App Factory to bring those things forward for for your citizen development and fusion team resources. The second pillar is our modular reuse design and build. So this is where we're we're taking historically monolithic applications and breaking them down into more functional components, more of a microservices model and enabling the build the blocks, assemble the blocks, um, approach through fusion teams. And lastly, you know, we've heard a lot about Blueprint and Pega GenAI in that certainly over the last ten weeks, you've seen a lot in terms of how you can speed up the design lifecycle. And that's going to be, you know, driving into the build life cycle as well through some of the Blueprint accelerators. One of the things that we're really excited about is being able to take the existing assets that you have within your architecture and map that into the Blueprint experience and make sure that when we, you know, we're building for modularity and enterprise reuse, that that is getting reflected in the assets you're bringing in through the Blueprint build experiences as well.

In a little bit about our roadmap on the left, you have all the foundational things that we that we have today. Situation in a Layer Cake class inheritance components marketplace. The relevant records. You can see two thirds of the way down there, things that have recently been added in Infinity 23, we brought forward the reuse library, so we were really able to start surfacing the things that we wanted fusion teams and citizen developers to be leveraging as part of their application builds. With the Blueprint Accelerator, we're diving even more into that. One of the challenges we've heard around really reaching the enterprise reuse vision with App Studio has to do with the branching capabilities within the studio. So with some of the more recent updates that have been made, as well as what we're having within 24.2, there's going to be a lot of work around branching and merging to make that even, you know, a better seamless experience between them. And then lastly, in the future, we've got our blueprint extractor studio interoperability and additional reuse library capabilities that are going to be rolled out that will just further amplify the opportunities for leveraging enterprise reuse and taking advantage of these modular entities that you have within the architecture. Um, that's it for my part of the presentation, I really just wanted to create a little bit of a hook for how GenAI and our roadmap fits into it all.

I'm going to hand it to these two guys, and then I'm going to come back at the end to talk a little bit about enablement and run into some Q&A with you all. All right. Thanks. Yep. Okay. Thanks, Paul. So let's get started. An important thing there is the first thing that I want to make sure that everybody gets is that skills that you need basically are changed over the years, right. If you if you compare it basically to the way we transport ourselves with horse and carriage really all days, then we went to the combustion engine.

Now a lot of countries see a lot of these Teslas running around. Right. So things have changed in the world, which means that before you needed like to be a blacksmith to handle these horse and carriage stuff. And if you get your combustion engine, you get your hands dirty, you fix the engine, you get your oil, oily hands and stuff like that. And but what you see now, if you fix a Tesla, they go in with a laptop, basically connected. And basically you're fixing it in a completely different way. If you compare it to Pega, it's basically similar things happened. We have there a PC five x. I don't know how many people work with five dot X here in the room.

We have some hardcore Pega developers, right? I had to I had to ask somebody for a screenshot because I didn't have it. I didn't work with it. I started with Pega seven x. But the interesting thing is also that Pega seven x what you see, not basically I think because it's so small, but we called it Design Studio at that moment, what we call dev studio. Now at that moment in time we call that design studio. So you were designing in a technical area and what you see now in Infinity 23, that's where we're designing, is graphical business driven. It needs to be in business language, and it is there to be used like a low code tool. So that's a really like a big shift, right?

And if I start hammering on my Tesla I'm not fixing it. Right. If I do an oil change on my electric engine it's also not going to work. So that's the same with your skills in Pega. If you're going to use your old skills in the new Pega, you're going to break it instead of fixing it. So that's really important if you move into the direction the modular approach using Constellation, basically all the things that we have, it's a different way of working. It's a different drive. So we want to explain that a little bit in the next coming slides. How was it for you to make that change?

Because you also work with. I was a blacksmith. You were a blacksmith. I used to be the black blacksmith. And then I had the spanner in my hand. Now I use only laptops. Yeah, I will fix only things with laptops in Leaseplan and all the customers. Yeah, exactly. And then it's like if you start hammering on that, Tesla didn't really work.

So that's what we had to learn. Also, a lot of stuff there where we're adopting the new versions. But this is really an important thing if you think about moving into Constellation modular approach, that your approach is really changing. So what also is changing that? What you see is that before we worked a lot on work driven development, like on the left hand side, you see that the SSA Basically, the senior systems architect is rowing the boat and everybody is basically shouting putting of web content to them like JIRA items and stuff like that, or word documents. And basically if we want to scale up our projects, we need a bunch of these SSA. So let's put up 20 of them in a project to speed up delivery. And that's not what we want to do. We want to collaborate, we want to work together.

And everybody needs to work instead of like giving work to another is like doing work that actually does something. So what you see now is that the LSA, the LDA and the UX are rowing the boat. They're actually working in Pega, in the App Studio or in dev studio that were needed. And the POA is on the top giving direction. That's where we want to go. That's where we want to head. And that's basically what we call their model driven development. And we really want to go into that direction. But if you want to go in that direction, not everything is possible out of the box with Pega.

So we need to do something there. So for that out of the box, I can build a house with Pega. It looks like a house, right? Nicely. All kind of stuff around it. That's possible. And especially around Covid, we use that a lot to quickly develop in a couple of days basically applications and put them live now because then everybody accepts it. Right. We have a couple of days.

We have a deadline. What's out of the box? We use it and everybody's happy with it. But also what you will see is that it's not always something that you want or you have some more time, you want to build more things, so you want a bigger house. I have at least even we want to have cars and you want to have different things basically that you want to do. So what you need to do is you need to have new building blocks. And once you have these building blocks, you can basically be creative and build whatever you want. You can create with your creativity, all kind of new new stuff. And that really helps if you start developing applications.

And we had it with the remarketing and the pricing app. Yes. So we have all the building blocks built already and then we have to build an application. So for that we did. With one week of design and eight weeks we were live with one SEC working on the project. Yeah. Thank you. And the good thing is that we compared it and it was two years in react. So they built two years in react and we said, okay, we can do it in eight weeks with one SSA.

They first didn't believe it until we really delivered after eight weeks of our application. But what we had is we had all these building blocks, so we just need to assemble them. We didn't need to create them. And that's where really the return on value is basically coming back to you. So if we get a little bit more into the hands on how you really do it, right. So what we need is a business architecture. And in the business architecture we're going to show you like the different layers that we have in an application. We don't want to stack everything at once. I see that mistake still a little bit happening is customer service is an application.

Let's stick everything in customer service or customer service is your interaction layer. Telephony. Email. Chat. These cases, they belong in customer service. That's where you're interacting. But you also have self-service where clients want to do it themselves. And underneath that we have the business application layer. That's where the actual processes are.

And you have normally product owners for for instance a sales process or fleet operations in that case that we took from Leaseplan here. And there you have responsibility from a product owner. They have their own roadmap and they create these business applications. Underneath that we have what we call the modules. And modules are connected to a system of record kind of elements or functionality that you can have examples that we have like a customer module with everything around customer get customer update customer, give me a list of contacts for a customer or create a new customer. All these kind of features are available there. And if I say available, I mean available for the App Studio. So a BA can basically use them themselves. You don't need to have a whole development team working on that, but also things like document creating documents or generating new documents, uploading it into your system of record or documents could also be one of your modules.

And underneath, of course, your enterprise layer, but a very thin one. Because if you change something in enterprise, all your applications are affected. But if you change something in a module, only the the applications using that module are affected. So in that way the impact of a change is smaller if you do it in that way. So if you go a little bit further and for instance for sales process, we need to run it in something like 32 countries. And also we have different labels that we need to run it on. So basically in this case your arrival in UK or Lisbon in the UK. So we needed a configuration slash innovation layer where you configure the behavior of your global process. So in the process we use our configuration sets functionality.

And in the top level you just configure how the global process needs to act. And in that way basically you can really quickly roll out. And I think we rolled out Sweden pretty quickly. Right? Yeah. Sweden, Belgium, Norway. So we went really fast. So we have all the building blocks like customer code, finance and all these modules built already. So whoever needs it, they will use it.

And then the global sales process applications, it's orchestrate all of them. And then the innovation layer or the configuration layer will just act only for that particular country. Like okay, do we need to execute this process or not. That's what it will actually decide. So that's how we did it in very few weeks for. Sweden was even, I think the faster one with a couple of weeks, right, with one SSA basically that we needed to configure it. So you don't need to rebuild it again. And it's really easy. And also for if you get issues, we had quite some issues with our friends from Salesforce.

Of course they were. They were changing without letting us know. And then basically they were already live and they said like, oh yeah, we changed something. But the good thing is like, how do you handle these kind of issues then? Yeah. So all the all the applications, It's not only sales process here, right. So we have 510 different applications using the customer accelerator or module let's say. So and then Salesforce changed something and everyone will stop working. Oh it's not working.

Yeah. Okay that's fine. So we'll go and fix it in the customer accelerator. One change and everyone will back up. Yeah. And that's really saving you a lot of time, right. So you have a single source of truth where we connect to that system, we fix it there, and basically everybody's up and running again, which saves you a lot of time because otherwise all the projects basically need to start fixing things. And they do it maybe in different ways. So this kind of setting up of your application is really flexible.

You can even have for labels within the same country where you say, here I want to be informal communication with my client, or I want to be formal in my communication. You can use that top layer for it. Or I want to try a new product with a certain set of people in my customer base. Then you can create an innovation layer saying, hey, okay, I changed a few things there and I bring it live for a specific target group. And basically in that way you can expand your functionality really fast. So this will really help you to be flexible to the future. So what's in these layers? Starting on the bottom a module. What do we put in a module.

So the important part the data model. So we agree upon a certain data model. And once we have that normally your enterprise data model the definition that you will handle within your organization is there. Of course when you have the data model you need to access that data. So the live data part your data pages are in there. And what we also have is what we call smart shape, which is basically a flow rule that we mark as relevant, which is in there, which basically brings functionality up. And I have an example of that later how we do that part. The integrations are there to the different system of records. Even for customer.

We can have different system of records depending on the client type or the product type. We can go to different endpoints that that's everything handled in your module. So your business don't need to worry about that part. And what we also have that's the the big benefit of, of Constellation is we create our views there, the reusable views, the for for your forms but also your partials for the read only data is basically in your modular layer. So once we have that we can go to our business applications there. We create our cases and we basically change the way we work in cases where before, if you look at it, what's happening in the case and in the application is there's a lot of rules there, a lot of things happening, especially on the on the flows there. There are data transforms, a lot of functionalities even hidden. And I call that normally like the spaghetti case types. If I pull something out and I want to change something at the end, at the front something falls down, right?

Because it's not working anymore. If I pull something in the middle, something else falls down. So that's something that you don't want. So what we do now is basically we build features in our modules and we orchestrate these features in your case type. So we say okay when do I need to do this feature is something that you do in your case time, and you orchestrate how you want to use these features. What moment? Which means that I can move them around and it's more like a ravioli, right? Everything is in there. Your sauce, your meat, your pasta.

You get everything once you have it, and you can move it around without worrying that everything falls down. And that's basically how we want to structure our case types. And that way we are more flexible, it's more business driven and easier. Also, for business user, the NBA is basically in the project to do their work. What we also create there is the form views. So we always say like every assignment that you have in a case is always created on a case level. So you need to have it on case because you do something for that case. Even if you reuse a view from the lower level, at that point you just say, okay, I'm going to reuse. So I have a view from a lower level and I'm going to use it there.

But you always create your view specific for that case. Why in the future maybe you want to add a field or you have a different condition on one. You want to show it. So the rules when I want to show it are on your case. And basically the do part is in your module. And then on the top level the configuration sets. That's where you can drive your functionality. So you start filling your config sets with all kind of features. Even decision tables can be created from there to decide when you need to do it in what country and run it from there.

Your localization. Translating your rules into the specific language or a language that you even want to do for your label is happening in your configuration layer, and your channels are basically also creating on that level. And that's basically how to set up a proper business architecture with the modular approach within Pega. So once you have that and you have your reusable structure, your architecture, the thing is, okay, how am I really going to do reuse? Because if you don't design for reuse, you're not going to do reuse, right? If you try to find it at the end, a technical reuse is not going to work. It needs to be already there from the beginning. So once you're designing, you need to design for reuse. So on the left hand side you have your requirements, needs or your goals.

Your flowcharts, your everything that you have from client side can be completely different things, right? And that's your starting point. And everywhere in every organization is different. That's pretty normal. But we want to structure it. And we want to get at the end to a case type. And that's what we're going to do with the design part. So we go from there into our high level design. And we use their feature maps for instance for it.

And just look at the feature. What are the business features that we need. What functionality do you need to have? Don't go into details because these sessions otherwise take for ages and you don't get any result because everybody is discussing about exceptions and details that you don't want to discuss. So just what are your business features? Run your Pega Blueprint. And don't say, okay, I run a Pega Blueprint and I'm done. But run them with different prompts, different even settings on on what country you're running or settings on what different industries am I running? And you get different results and use that to get inspiration of improving your design.

You put the result into App Studio and there you start detailing it for on purpose. We call it detailing because you're not translating anymore. That's the first step. You translate your requirements into a structure and then you start adding details to your structure, which means you can always step back to where you were. And then you don't have that translation issue that I wrote something down. I think this is what you're going to create. I get the result. I don't like it. Right.

That's basically the first setup. Once we have that, we're going to implement the the features. And you did also this part of this feature right. Yes. So the features being implemented in the module right as a reusable stuff. And then we the business architect, first time the system architect will create the APIs parameterize flow etc. and then hand it over to the BA to configure from App Studio. So it will be available for the from the App Studio for them to configure. So then won the SSA done with that and his job is done.

And it's business architect and PVO wherever they need they will just keep reusing it and then just change the parameter. Job done. And that's where you can see first time we have to do the user story refinement, build, test everything. And then the second time onwards, half of your job is already done. It's just basically configure it, test it, deploy job done. Yeah it makes it a lot easier, right? You start with your placeholder. Just an assignment show and tell. You tell what's going to happen.

And once you know that you really want it, then you start building it. Right. So that saves you a lot of time. If you basically acting in in this way. And then if we see that as an example, in this case, we also have one of the things that we reused from from Leaseplan. And I will I will quickly also go to the complete slide. So what's happening in this feature. Right. Because I'm, I'm then the BA role in this case we'll take the behavior.

I put it on my on my on my sheet, on my on my case type on the right hand side I configure basically the things that I need. So what where is my lead ID in this case. And what if what happens if it goes wrong. So my alternate states or I configure it here. Exactly. But what did you build basically there in Dev Studio to make this possible for me to use. Okay. So for this the we did the API build from App Studio and then the flow we built from the studio and then the exception handling flow. Right.

So this is built in the module, which means in case of an exception it will automatically if it is a business exception it automatically goes to the alternative stage. And then it waits for the business to take action on it. In case of technical exception, it will go to its service exception work basket and doing auto retries. And in case if it doesn't help, then it actually tell the support team how what you do. If there is something wrong, you need to look at it. All those things will be done in the module. So when the VA configure it, it's not only for one application, right? There are ten different applications using it and all of them using the taking the advantage of including the exception handling. It's kind of an autonomous process for them.

For them it's just plug and play. So they need this feature. They configure it from App Studio and it's done. And that's why we maintain the consistency across other applications across the organization. Yeah. And it's error handling also. So it's all error free. So that's good that everybody can use basically the power of a systems architect, the knowledge that they have and the lsas to build this and BA can use it. And that's why we work with Dev Studio, build it in Dev Studio, use it in App Studio.

What I always say in the projects, I don't want somebody touching Dev Studio without doing something that I can later do. From App Studio I'm using Dev Studio to enable people in App Studio. That's the the paradigm shift basically that we are making here. So with all this, how do you get your return on investment? Right. So during the design. We design every feature once, which saves you a lot of time because you see a lot of discussions otherwise going on, right? How to get to that feature, what it does, and once you have it, you just plug it in. You don't need to discuss it anymore because it's working for you.

You need to validate it if it's working enough for you. Otherwise you need to extend it. You you focus on the important part of the business process. So you're focusing on really what you want to achieve instead of all these details and exceptions that you have. And where do we get the data from? What system of record? That's something that you don't want to do. And it's more efficient than basically in your design sessions. So we we have some examples basically that we can already get results in a three day workshop after three days.

Uh, basically during the workshop, the trainees build their own case type basically, and their own process for their project that they want to start and they can already show it basically. Then even on the left that you can go to the business and just in three days, but you're focusing on the right level. So during build it's only you only build the the new features. So you have to reuse what we said before. Like we can quickly build new applications. Build is easier because you have an atomic feature that you can test by itself. And I know we have some developers maybe in the room that you know that if you're testing a feature at the end of the case type, you're screwed because then everybody's working on the case type. You need to go to the end and test your feature. But if somebody else broke it, basically you cannot test your feature.

So you need to wait until they're done and fix everything you need test data basically to get all the way to the end and do it with these features. You can do it yourself. And basically with input and output your parameters, you can quickly test it. You make your unit test. That's also really important that you have your unit tested application. And then basically you can bring it live from there. So the QA is also simpler because features are reused. So the number of things that you need to test is basically going to reduce because the feature we know it's working. If you have 80% of reusable features, the 20% basically needs to be tested more.

And the 80% basically you already know that it's working. for maintenance. A new version of an integration can be implemented. What we said already with Salesforce. If they change some stuff. Salesforce ruin our system, then we do. We just fix it so they just change the version of the APIs. We need to use and there are situation where okay, so the first version of the API will support only certain feature, and the second version will actually support more feature in that case. Like that's when the configuration setting works there.

Right. So we just the build is in one place. You don't need to change everywhere. Change it in the module, have the config setting, have the right version that needs to take care of the needs. Everything is done, then it's already working for everyone, all the other application using. It. And that makes it a lot easier. So that's why we have a lot of return on investment on our maintenance part. That's why we saw overall we go faster time to market, which is really important right?

A lot of questions we get like, hey, can we be faster with Pega? Also, what I saw and I discussed it with during these workshops with POS, like MLP, thinking is different because before MLP like, hey, I want to take out a lot of stuff so that I can quickly go live, but if I have all these features, then I can apply these features without worrying. Right. So I have a rich first MLP. And that's really also changing because I teach them the product owner saying like, hey, we already have the communication. We can create documents, everything is available, so why not? Why wouldn't you put it in your first MLP? You can already start communicating with your client. It's already there.

It's ready to be used, so your MLP will get a lot more functionality than we normally did with the first MLP. Then if we calculate it a little bit more, what we see here is on the left hand side. What if we like an example that we do like we recalculate some stuff that it's anonymized, right. But in a situation that you have like 12 modules with in the middle, then next to it we have around 80 features and we have a new feature to get some vehicle details right. You need time for it. You need to design. You need to build, you need to test it, right? You need to create a view. Well, we do it with Constellation.

So we take 1 or 2 hours. We are done. We don't need to build sections anymore, but we have 20 or we have multiple application in this case for with around 20 case types. For instance, in there, in a traditional way we built in every application you build it, sometimes you reuse a little bit like an integration rule, but most of the work basically happens in different teams, different applications, and they even sometimes don't know from each other that they're doing the same thing. So you get a higher total number of hours that you need. If the next column you do it in a modular way, you just do it once and then you reuse it in the other ones, which basically you only need like 102 hours basically to do that. If you see it already in this example, you have like 306 hours, basically less that you have if you do it for this small example already in your organization. But if you take it a little bit bigger, then you say, okay. On average, for instance, we save about 102 hours per feature that we build, test and put into production.

Right? And if we have around 20 case types where we use around ten times the same feature, like getting customer details, send out communications, create documents, if that. On average, basically what we are using, then what you will see is that you have something like 73,000 hours saved in your enterprise building the same application. And that's a huge number. And we saw it also. We calculated also halfway during a modular approach what we saved. And it's really huge. And you see that it really can bring you a lot of value and can speed up delivery quite dramatically. So this is really like how you get your return on investment.

It's not just faster time to market, but it's also saving you a lot of money basically in your development cycle. So what our client and partners basically have to say on this, We want to show here a little movie that we created where we run a workshop, so we let it run. Yeah, we just finished our great Low-code Enterprise Development workshop here at the Rob. Alright. I really love to see the whole engagement of the both of the teams. We had the business and it basically together in one workshop, and what we also said is we want to work in a low code way and if you go low code, then of course Blueprint is there to help us, right? So how was it to experience Blueprint in our workshop to get your requirements as a Po more clear? Yeah, what we see with the business is that it's very hard for them to really identify what their needs are. And with the use of Blueprint in the last couple of days, we really saw that.

It gives you new insights on how you can approach stuff. So where we first of all, it's very complex. Blueprint really helps you with with getting a good solution in place and a design for it. So yeah, it's very valuable for for what we what we want to reach and what we want to accomplish. Yeah, I saw it like the first thinking, using Blueprint getting to the point. Right. But then we have a Blueprint and then it's up, of course, to you then to say, okay, we take the blueprint. How was it to use Blueprint and getting it further into your application structure? Yeah.

So as an LSA we are really exciting to see that we saw a blueprint and then we wanted to really quickly implement it. But at the beginning it was kind of unlearn stuff that you know and try to implement the right way, build modules around it, build a modular structure, use reusable things throughout Rabobank, which they can keep on using in other areas as well. You know, build those blocks, small Lego blocks, put it in your main application, then have the whole feature and then push it over to RPO back again for the development. You know, he can she can add some things more on top of that. So especially with Constellation right. We were using Constellation of course the latest technology on that. And then it was funny also to see during the workshop that even like the RPO, like, hey, I can start building my own case. Right? My first case type.

How was it to work with Constellation in App Studio? It is very easy to do, even for me, without any knowledge on on Pega whatsoever. I do have a lot of knowledge on the business side, but Pega for me was totally new and basically in a very small amount of time, I could already start building my own workflow and I can take that to the business to show them this is what it could be, which I think is very valuable in getting them on board on this change process and getting a workflow into place, which really will accelerate in the way that they work to take out all the manual effort that they have now and which can really speed up our processes. Yeah. Make your life easier, right? Of course, I'd also like to know all the members involved in the workshop, like from the Bas to the POS, the developers, the SS, SS, SS and you. So we it was a joint effort where we were not collaborating. At the end of the third day, we had an application almost working in the working and you know, it's ready for demo. So that was that was fabulous and awesome.

Yeah. So it was great workshop. And now keep going. And basically quickly develop new functionality. Right. That's that's definitely the goal. So if you also get excited around what we did here at robo, start with your business. Right. With your Po with your base and do it in the right way.

And you will very fast get your results and you will be as enthusiastic basically, as we saw here today. Yep. So it's good if our clients basically stay on their own request, basically create this kind of of videos stating basically what we did with the workshop. Now we need to go next. Yep. There we are. So then we already at robo. Maybe you can explain a little bit what the legs says here. Yeah.

So in Leaseplan we call it accelerator which is modules. So when we start Leaseplan and then so what legs feels it's much less work to the market, right? With Constellation and App Studio development, it's very short time to market, and maintainability is much simpler, and we can already see the return of investment with less governance and cost. Faster time to market, less development effort. Yeah. So what we see also some of the others. And we don't go through all of them because otherwise we don't have time for your questions. Right. But we go up to after the workshop that we get 50% cost in development time, going live in July next year.

Basically moving back to the end of this year, or we need to go live by the end of the year. But hey, we see now that we can go halfway July, we can go live. So we really see a cost cut there, basically up to 50% depending, of course, on what the topic is and how you're already doing it in these days. So we also have Aaseya here with Krishna, basically, where we can also use all the knowledge that they already get because we really closely work together with them. They did a lot of work for us and we couldn't have done it without your help. So for. You. Yes. So we at Aaseya.

So we did Constellation application along with Marco and the Pega team, with Leaseplan, with with the modular approach. And then we did a similar thing in Neom and for city management in Saudi Arabia. So there we find an interesting use case where the billing module so which was initially built for Marmara part of Marmara I would say. And then we thought it could be useful across other part of Marmara and then private entities across Saudi Arabia. So fortunately we did created it as a module which is being used across now. And OK we learned from Neom or Leaseplan everywhere. How are we? We cannot we cannot keep the knowledge only within us, right? We are sharing here similar way.

We do a lot of hackathon with a lot of lscs and across the company, and then we do a lot of trainings on the Constellation, modularity, etc. and all our new implementation we follow Constellation, modularity, modularization, etc.. Yeah. Thank you. So then back to you, Paul. Yeah. Am I on still? Okay, cool. So I'll fly through this so we can get some questions.

Um, you know, the first three missions that we have up here on Pega Academy are kind of the basics. So, you know, get in, make sure your teams have the business architect training, the low code app builder mission, and extended missions. The Constellation adoption mission is new this year. We have learned a lot through the last couple of years on, you know how we should focus our exercises in order to really enable the field and this modular reuse approach that we talked about really, you know, you can leverage it with both traditional and Constellation architecture, but you're really going to see the acceleration when you adopt it in a Constellation architecture. So take this training. It's only about 12 hours. We're asking and we're really, you know. Trying to focus on this as a key area for enablement in 2024 and 2025. The module Enterprise Reuse Foundation mission is just a few hours.

It goes through these concepts as you're rolling this out within your teams. It's a good primer to get them to understand what we mean by modularity, how we architect it from a business point of view, product owner point of view, and some of the capabilities between App Studio and App Studio to drive that. And then we just recently launched this document journey as part of our pega.com. So you can go in there and it walks you step by step how to apply this approach. And then lastly, our GenAI mission talks through how to leverage Blueprint. So all these things I recommend you taking. But if you're looking for a more guided experience to bring your teams through it, Marco and our consulting team and partners like Aaseya Have offerings around this. Within Pega consulting, we have this Low-code Enterprise Development workshop. It's a three day workshop to combine all these concepts together and get your first app version in three days, so you can really understand how you can put it to use.

Um, and with that. Yep. Before we we go to the questions, uh, now we have here two people in the room that I want to thank because this was not possible without two key players here. Lex, do you want to stand up and take you and Pankaj for helping and basically doing everything with us here? Thanks to these persons basically helping us out, having the vision and allowing us basically to set up Constellation as first one in such a big project. Uh, and also, uh, the way we, we collaborated together, that's really important to collaborate with clients and Pega. Right. And with our partners that we we have the same goal. We want to be successful.

Right. And that's what what we did there. We collaborated with Lex, we collaborated with Aaseya, with Pankaj. Basically, we made it work and that's why we can basically now share this experience and basically this way of working and how you can do low code enterprise development. So thanks guys for your support and help. Then if there are questions I don't know if there are, please go to the microphones because otherwise we don't have it. Also on the recordings that they they are doing. And we can basically get your questions. So if you have some questions about what we showed here, please go to the microphone and we will try to answer them for you.

Otherwise we save time here. No questions. It's all clear. That's good then. Okay. Good then. Thank you for your attention. And the recordings and the slides will be later also on the Pega website. So then you can even click on these links.

It's easier maybe to find them on the Academy. And then you can always use it basically as a reference later. Okay. Thank you very much. Thank you so much.