PegaWorld iNspire 2023: Enterprise low code in a modular landscape. How Rabobank builds for the future with Pega.

The technical landscape of Rabobank is changing at a high pace. To keep up with customer and employee demand for cutting-edge applications that help achieve their goals, Rabobank developed a componentized architecture and organizational structure to create speed, autonomy, and agility at scale. In this breakout, they will describe not only their concept for modular enterprise reuse but also their philosophy behind it. Rabobank will also detail what they see working and how Pega software is supporting their fast-paced architecture and organizational design.

Transcript:

- Good morning, everybody, and welcome to today's session on "Enterprise Low Code in the Modular Landscape,: How Rabobank Builds for the Future with Pega." Before we get started today, wanted to do a quick introduction of myself and our two presenters. My name is Paul Barnes. I'm a Senior Director of Business Excellence for Intelligent Automation at Pega. I've been here for about 12 years, spent 10 years in our consulting group, and two years ago left that to join our product strategy team. And I'm really passionate about enterprise reuse and modular modern enterprise reuse, which is why we have the Rabobank team here today. So joining me, we have Ralph, who is the tech lead from Rabobank, and Vincent the business architect. Before we hand the baton over them to have them talk to you about their particular approach with Pega, I wanted to start out by talking a little bit about modular modern enterprise reuse with Pega and what that looks like. So launching into this here, let's see if this works. So Pega is being used differently today, and that change is being accelerated by many factors like low-code tooling, generative AI, which you all heard about earlier today, and always trending towards more agile applications and more agile application development. Pega's low-code platform is for a power decision and workflow automation is the leading platform for driving this type of development across low code continuum from citizen development configuration happening for lower complexity, lower criticality applications up to fusion teams, which are blends of business and IT resources, creating applications for their lines of business all the way up to enterprise grade applications typically built by professional Pega developers. And enterprise reuse is one of the key variables that's accelerating and enabling low-code development across this continuum. So what are the guiding principles for Pega reuse? Essentially, modern enterprise reuse focuses on breaking down the monolithic enterprise reuse layers and frameworks that many of you are probably very familiar with, you've seen implemented over the years. And simply put, the ideas that we want to build more reusable enterprise building blocks within Dev Studio and assemble those blocks into workflow applications in App Studio. And the five principles for modern enterprise reuse are shown here on the left hand side here. First, we want them to be interoperable, so leveraging these building blocks both across authoring experiences between Dev Studio and App Studio, but also across applications where these building blocks are being consumed. Secondly, we wanna focus on updateability. So being able to move in or move out building blocks and functionality within your application stack without having to necessarily regression test the entire application. The third is that we want these building blocks to be configurable. So, creating them in such a way that they are extensible or configurable by the consuming applications for the particular purpose that they're being consumed in the application. The fourth is that we want them to be modular. So again, moving away from the monolithic architecture and moving more towards modular smaller building blocks that really promote agility across the enterprise. And then lastly, having a governance model. A Pega COE is a great way to help manage that, but certainly there are many ways to approach Pega COE or any type of federated governance as well. The idea being that you need to have some type of authority that's responsible for designing, deploying, maintaining, and then monitoring the use of these building blocks across your enterprise. So a quick example of what this might look like, and the team here is gonna go into much more detail in their specific implementation, but on the tops you see here "Change address," "Complex service requests" representing what a case flow might look like. The case flows themselves are built on these individual building blocks. So these building blocks are essentially built on applications. They typically don't contain case types within them, but they do encapsulate functionality that performs specific things, often focused on a business object or a some type of integration to a system or some type of common utility that can be used across various applications. And then underneath that or encapsulated within each of these modules you can see that there are multiple rule types that are built up together for that. So starting with the data layer, creating rules, data pages, connectors to standardize the view, update data object to perform some type of discrete action. And then the next layer up, creating self-contained flows typically saved in WorkDash that perform, create, update processes or delete actions. And within them, they handle errors and retries so that they are removing complexity from consumers of these smart shapes or this functionality. And then of course all those things are packaged up again into this built on application that we see here across the blue line. There's a lot more detail that we go into. We're actually publishing training on Pega Academy about this. There is a new course out there called Modular Enterprise Reuse Foundation, which I encourage all of you to go out and take a look at. It's a two hour course and it's suitable for business architects, system architects, delivery leaders to get an understanding of what these concepts mean and how you can apply them. We also get into some details around specific features within App Studio and Dev Studio that you might not be leveraging very much today in your application build, so please take a look at that. So what do we get with this new modern modular principle? The benefits are listed here. So one is that we're building with a modular mindset. So we're really trying to drive flexibility and drive that flexibility across applications. One of our tier one financial services clients reported that they saved over 16,000 development hours using these reusable processes in this model. The second is that we are publishing prescriptive guidance on what it means to encapsulate and extend capabilities within these modules. And delivering in this manner also drives continuous delivery and autonomy of distributed teams, overall increasing delivery velocity and lowering total cost of ownership. And one of our clients that's here at PegaWorld this year, digital as a service multinational client achieved four times faster time to market leveraging this particular approach. And then lastly, thinking about your resource pool and Pega resources that you know can sometimes be hard to come by, we really want to democratize the idea of enterprise low-code development across your organization, but we wanna do it in a safe and controlled manner. So following this approach allows you to point your professional high-end Pega developers at building reusable enterprise building blocks within Dev Studio, but doing it in such a way that they can be exposed with an App Studio, enabling process developers, system architects, business architects, et cetera, to pull them together into workflows. And we can see here at the bottom that there was a recent report published by Forrester that indicated a 50% reduction in technical resources in building enterprise applications. And what's great about that is that it means that you can increase the amount of throughput that you have. So we expect the ecosystem to continue to grow. Demand for those technical resources will always be there. But this is really removing the bottleneck and opening it up so that we can go even faster with application development and get you the value that you need. With that, it's never too late to improve your reuse practices. I realize that a lot of you in the room here probably have a number of applications already in production. So we have some tips around how you can start to take your modular architecture and modernize it incrementally through this approach. First, take a look at isolated functionality focused on what I said before, business objects, integrations, some common utilities, make sure that they're wrapped in their own rule set, and those that are are great candidates for moving into a modular built on approach. Once you've got them, then you can look at parameterizing them into the smart shapes, which again are one of the concepts that are talked about in the foundations course that I mentioned earlier. If you're working on a new application, you should right out of the gate consider what you can put into its own module. So the guiding principles around self containment, flexibility, configuration. Build that from the start. And you can use out of the box refactoring tools to look at what you might have within your existing stack in order to pull that into that layer. And then the last couple bullet points here, we really urge you to stop building in some of the older ways with Pega, which essentially is doing the work in Dev Studio and Process Modeler, and move more towards building them within App Studio and leveraging the case designer. A lot of these capabilities around modular enterprise reuse and democratization while still achieving that enterprise complexity and scale is focused in in those two areas, so please take a look at that. And remember, use Dev Studio to build these reusable enterprise blocks and App Studio to assemble them. And then I already put a plug in for our new mission and badge on Pega Academy, "Modular Enterprise Reuse Foundation." So with that, I'd like to hand it over to Ralph here to talk about the architecture.

- Thank you very much. Let's put on the correct slide. So my name's Ralph. I'm from Rabobank, and together with Vincent we're going to tell you a bit more about our story. I'm going to do a short introduction, Vincent is going to tell you a bit more about the technical details of our componentized architecture, and then I'm going to tell you also something about how we did that, how we organized that a bit. But before we start, I actually also need your help because I want to know also a bit who is who and I see a lot of Dutch faces around. And you all saw the presentation of Finnbar this morning about Rabobank. But maybe with the show of hands, before coming to the keynote of Finnbar this morning, who already knew Rabobank? Oh, that's nice. Keep 'em up, keep the hands up. Who of those people are outside of the Netherlands? Living outside of the Netherlands? That's significantly less. Okay. No, really good. But thanks for that. It's always good to see is that Rabobank at least is well known. And for the people who didn't know Rabobank yet, well Finnbar already gave a bit of a insight in that. But also- Oh sorry, wrong button. I'm going to tell you a very short story about Rabobank. So the Rabobank has, like Finnbar stated, 9 million customers, 9.6 million customers. And you see a graph there where most of the customers here in orange, those are our Dutch customers. And that's exactly why I asked the question, because most of our customers are Dutch. And within the Netherlands is we are an all finance bank, but the smaller piece just outside there, I'm going to show a couple of graphs also in the later slides, but that's really from, yeah, outside of the Netherlands where we aren't that big. We do have a specialty there is we focus on food and agri. That's also why you saw the machinery in Finnbar's pictures also. A bit of an insight also is we are a cooperative bank and we have a mission, and I'm not going to explain the entire slide, but I think what always is nice to state is that we have a mission which is called Growing a Better World Together. And that sounds like a big task, and it is, growing a better world together, but the way that we tackle that is we are trying to leave this world in a better place than which we found it. And if we try to do that every day, every week, every month, every year, then we are looking back now already and we're really seeing some impact. And that's also why we have these detailed strategies, which are good. If you have some questions later on that, that's also totally fine to do that. And we're mostly in the food and agri sector, is to prove that. Now, coming back to our international customers. So you see here a picture where most of the customers are actually organized in the Americas, so Northern and South America, and a lot in Australia. And the thing that really catches also always my eye is that even within Australia, for a originally Dutch bank, is we have a lot of farmers, more than 12,000 farmers which we help out also with financial products. So that really is a good thing to do. But also some history together with Pega, because we are a Dutch bank and we definitely also have a strong relationship also with Pega and the products that they do. Again, I'm not going to in detail explain everything, but there are basically two major milestones that we knew as Rabobank, and the first one is 2013 and the second one is 2018. So we started in 2000 with Smart Investigate, which was still on Pega five, I believe. I wasn't connected to that, but those are the stories that I've heard at least. But in 2013 is with business lending, we started a product where we wanted to digitize not only our landscape, but also the processes for our customers. So we wanted to sell products also via online channels. And in this case for business lending, also business products there. So that was a real tough endeavor also for us, but we definitely managed that and that's now been, yeah, going on for 10 years. So you can imagine, that's a pretty substantial amount of features that we created for our customers. Be it self-service, be it in online sales, or helping our employees even make a better sale or do something better for the customer. Then in very quick order, also collections, our DLL friends with vendor finance, KYC, I see a lot of colleagues here also for that, and also Rabobank Australia/New Zealand started working with Pega. But then coming up to the 2018 part, 2018 was a big year for the Rabobank, and that's now already five years ago. And if you paid attention also at Finnbar's presentation, he was also talking about five years of CDH, right? So in 2018 is we started with Pega Cloud. So we were one of the earlier adopters, and for us also there was a strategic choice is to put everything in the cloud at that moment in time. So before that, in 2013 basically, everything was still on-prem. And the way that we transitioned, or actually we didn't transition, is we kept everything that was on-prem, we kept that on-prem and we started Greenfield in the cloud. So basically not taking over all of the legacy is that we already, or legacy, that we created with the on-premise systems. So we had a dual strategy is to move all of the business lending and all the applications connected separately to the cloud towards our Pega Cloud strategy. Our story is, at least for the second part, is mostly regarding the Pega Cloud part, just so you know if you have any questions. And with that, I would like to hand over the word to Vincent about some architecture.

- Yes, thank you Ralph. Hi, everybody. As Ralph said, yeah, five years ago we started with Pega Cloud, but we started out with this. We had a lot of monolithic applications. They had front-end logic all combined running on the on-prem systems. We had a very complex integration monolith also involved, and all these systems were not properly connected on a customer level. So we as architects had a vision on how we should decouple this. And we started with the technology layer, which is what Ralph pointed out, we started with Pega Cloud. At Rabobank, we have a cloud first strategy, so we don't bring everything to Pega Cloud only, but we also utilize Azure and AWS and other clouds. And this is the technology layer so that we could decommission all our on-prem applications we have and hardware we have running. But then the hard part came, and that was bringing over the functionalities. In the old situation, we had multiple workflow management applications, and we had some custom build stuff and we actually used Siebel for some workflow. Not recommended. So what we wanted to do is instead of having the monoliths, we wanted to have separate, dedicated, we call them banking services 'cause we're bank but normally you would call them business services, who have a very distinct function and can be reused in multiple applications for processes. For instance, the onboarding new client, we made that such in a modular way that we can use that in multiple customer journeys. The same for the acceptance sign services, that's the application which handles capturing the signature of our clients, adding the digital signature of the Rabobank, and then finalizing the contract. And then we also started to use Pega to orchestrate our customer journeys. In the old situation, we would bounce from application to application, and we still have places in the bank where that actually happens, but with the orchestration of Pega, we were able to connect all those steps and provide one customer journey. Well, all the orange parts are Pega. The question was, "Okay, we have all this in Pega, did we actually create a new monolith?" And luckily we did not, because we really focused on how we integrated and treated all these business services. So to start again on the bottom layer, how did we integrate the Pega Cloud in our landscape? Well, obviously we had to connect it to our, which we call one identity, our authorization and application. We had connected to our Kafka event bus to make sure we can stream all the events, and we connected to our Splunk to monitor our operation and our security. The interesting part became on the banking services level. So, the yellow arrows are API connections and this means that we have, for instance, onboarding new clients as a service running on Pega, but also customer recognition. So they're both on Pega Cloud, but if they want to talk to each other they go via open internet via gateway, and the gateway is outside of Pega Cloud. So one Pega application talks to the other Pega application via an open internet connection with an API gateway in between. This enables us that if you want to maybe remove something from Pega, we can simply remove it and add another system there, and all dependent systems only have to change their endpoints. We did the same thing for the orchestrated journeys. If they utilize services, then they connect via the API gateway to the underlying business services underneath. In that sense, also we can have really decoupled our customer journeys with the underlying business services. And there's one special integration I want to highlight, this is to the top one. At Rabobank we have our own design system called Sensors. Our UX people think we have the best design system and want everything to be picture perfect. Luckily, Pega offered a DX API. So the developers defined the screen definitions there and we created something we call the DX Interpreter, and it translates Pega screen definitions to our front-end design system. It basically means that if the UX decides, and they do this like every year or every few years, they change their design system, then we only have to modify this one single component and none of the underlying underneath components are affected. So, we were able to really decouple our architecture and we avoided creating a new monolith on Pega. It poses some of the challenges in also how we set up Pega Cloud. So obviously we have the Pega Cloud platform, and I guess most of you also have multiple stacks running, I think we have four or five stacks running at the moment. For simplification, I only show two in the slides here. And you see, for instance, customer journey Y, it utilizes business service A and business service B. Of it wants to call them, it goes via the open internet via the API gateways. In that sense, all the applications run independently of each other. But as Paul introduced, explained, we have the components and we also use the reusable components. I'm going to blow up the slide a bit. I'll try to explain. So on the left side, you see stack A, reusable component party, for instance, because the customer journey X and Y both need to interact with our CRM system. So that component is pushed to our shared repository, and then each application can pull that component into its own stack. But if for instance business service B needs a slight modification on that component, then we create a new version there and the new version then is pulled by business service B without affecting the other ones. But we do have strict guidelines on that. So we don't want to end up like we did in the past with eight or nine versions of the service, so we try to limit that to only one or two. So if there's a new version of a component, all other applications have to update as soon as possible. This enables us to make sure that everybody is running on the latest version. But the nice thing about this is that the develop for customer journey X are really independent of all other applications we are running on Pega. So this is from architecture a really nice setup, but it does pose some challenges in how we do the confidence for this part. And that is for Ralph to tell.

- Yes, thank you very much again. Yeah, so talking about components, the thing here is that you can have a very great architectural overview or vision on how to do stuff, but it must also come together in really your organization, right? So you basically need also a strategy in components. And in this slide is the first three items or the first three bullets are basically very closely connected. So I'll tell you something about it. So the component strategy that we have at Rabobank basically all ends up also with autonomous teams and with quality. Well, how does it do that? Well, with autonomous teams is we basically make a squad or a team end-to-end responsible for a complete journey. So it can be in any domain which uses Pega Cloud. So we have KYC, we have digital customer processes, a lot of domains where we share our platform in, but a squad will be responsible end-to-end for the entire journey. Well, we do also have components. So if a journey team or a squad would run into a component which is already created, they just leverage that component, right? If it isn't created, they will create it and they will own it. And that really is where we don't need a separate component team or a big center of excellence to own components or to change it. Basically, teams own components. And they also make sure is that quality is up to par, but something more about quality also later, how we try to steer that in a sense. So what you will see with that ownership across the entire journey is that the teams also can make a fair bit of impact, and they can also have, and need to have, a lot of interactions with different squads also to make sure that the journey is up to par. And we really believe is that is also part of our, and that's the final point, the engineering culture, because our engineering culture also crosses a lot of domains. So any domain that uses our Pega technology basically can make their own decisions, right? As you've all seen a siloed organization. Well, Rabobank is basically also a bit siloed in domains or what we call tribes in our agile structure. But there's one thing or a key thing, and that's also partly on the next slide, but our engineering culture really is a place where we would place tech as a central pillar, and Pega is one of these technologies which we place as a central pillar. So we would inspire squads on a journey and on a result, right? On an outcome, basically. But also is we can inspire, and that's something that we've seen in the five years that we are using Pega Cloud, is we can inspire them also on technology. So using the latest and the greatest. We upgrade to new the latest version twice a year, and that takes us one and a half, two weeks for all of our stacks to be upgraded basically. So making that our engineering culture and also a great place to work for our engineers in Rabobank. But coming back also to a bit in how we steer quality, and a main part of that is in our Guild structure. Well, I think most of the people are or have been or have been working in an agile organization, right? And agile usually also uses something like Guilds, or they can pop up, right? One of the key things in the Guild is you need to want to be there. Nobody's forcing you to be in a Guild basically. Well, what we see here, and this is a bit of a diagram and it takes some explanation, is on the bottom part is in the different colors is I represented a number of tribes or domains which use our Pega Cloud where you have areas and squads which are in those domains, and all of these squads are joined together on the top in, for instance, our monthly Pega chapter. And what we do there is we basically take all of the Pega engineers and share all of the informations that we have regarding upgrades, new components, new features, new journeys, new anything basically, or challenges in which we run into in the past, right? So basically that's the one stop shop for all of our domains, and that's also tech as a central pillar in your organization, right? Is where everybody can join in. They don't have to, but it's definitely, we see a lot of people doing that automatically. People start sharing information. Far better is you also get presentations regarding your journeys and also all of the other Guilds. So the testing monitoring DX Guild are also presenting there. What is the Guild doing? What are we up to? What are we going to do? Do you want to join our Guild? All of these type of things, that's basically all handled in the monthly Pega chapter meeting there. So that's basically our structure. One of the important points is what we see and what we have seen in the past, because anybody who has ever been in a Guild or has been working with a Guild might know is that a Guild basically has a flowing motion in activity, because it all comes up with ideas and a person to drive it, right? So if there isn't an idea, then basically, it's nice that people share what they're doing but then still you're not progressing, right? And that's actually the purpose of a Guild, is to not just share, but also to learn from each other. And that basically is what we're then also monthly doing in the Guild or in the chapter meeting, but that's really also where we have the drivers, which are key in our Guilds. And that's not a separate role, that's just somebody who put up their hands and stated, "Hey, I think I can make impact on this." And basically that impact is also giving our engineers a stage, right? So a stage to basically share what they know, share what they can do, have some great ideas, take along the entire organization, and also, yeah, make sure is that for Rabobank is we do the best things there. The final part or the final Guild that we have, that's the overarching LSA Guild. I'm going to explain a bit in my next slide because that's a bit of a handful. So I shown you already or I told you already about our different tribes, and those different tribes is they all have very different purposes. So it could be KYC digital customer processes. So it could be a process which is for a customer or just for an internal employee basically, but they have in common is that they all use the same components. So for instance, all of the components which reside towards our system of records for customer data for instance, everybody uses that, that's not different. So we totally share that across all of those domains. And that's basically also what Vincent just stated, is we're trying or we're not creating double components there. So not every tribe would own their own component or own version of that component, right? That's already cutting out a lot of slack on that level. But as you see here, I dropped three tribes just for the picture, there are a couple of more, but every tribe would have a number of areas and each area has its own purpose, and within each area there is a number of squads. So that's basically how it scales there in organization. Each of those areas would have at least one LSA, but in most areas is there are a number of LSAs there. But what we try to do there is, within the overarching Guild is we take all of those LSAs and we basically put them in a Guild and basically not steering it by one architect or one person who is deciding everything for all of the LSAs, but they decide together. So really is a group of people, and like I stated, it's a Guild, right? You need to want to be there basically. And what you see is we steer, and this is where the quality component from my first slide comes in again, is they basically steer quality together. So it's not being policed by design authority or an architect or whatever, basically. They design whatever is in the box of Pega has the correct design principles, developer guidelines, all of the quality attributes, right? Is they get to decide on those things. And to give you a bit of numbers on scale is what we are doing. So in in total at the moment we have four domains, which we call tribes , where nine areas, 40 squads, and 320 engineers are working in that model on our Pega Cloud. That's not our on-prem system. If we would count those, that will be far more, but that's basically on cloud what we're doing. And that leads us also to a bit of outcomes, what we have. So one of the key things is that model is very scalable. So if a tribe would, or a new tribe would also start using Pega on the Pega Cloud, they basically just can join in. It's basically a plug and play type of situation where you can just add a tribe, add an LSA. Also, a bit of resiliency. So you can imagine, right? With the war on talent, et cetera, is people also tend to switch jobs or find a different challenge, whatever, is if we take out one of these persons, one of these LSAs in a Guild, right? Or in the Guild, that's not a big problem because you still have a large group which has a lot of common sense altogether. So it basically is a very redundant system. Well, it will become a bit wobbly if five or six people leave at the same time, but what's the chance of that, right? So that really is one of the key features also for us to use this model. It's resilient for us. And also it's giving people a lot of opportunities, is to, like I say, or like I said, is walk up on a stage, right? If you drive a Guild, if you drive a feature, own a journey, basically, that's something that you can really also put some personal effort in basically. Next item or takeaway or outcome is something regarding collaboration. So if you would reuse a number of components regarding or cross domain basically, cross drive, right? You would create a lot of dependencies. Well, what what we see is that also that dependency because it's very transparent, is that we don't want double features or double components basically. There's a need for collaboration, and we see that the need for collaboration basically from the start gives our squads and also our areas and our tribes also a sense to start working together early. And this is really one of the key things. If you start working together early and it's transparent, then nine times outta 10 it isn't a problem that you have a dependency, right? Because you're in contact, you know the people, you know how it works, you can ask questions, most of the times people have some documentation regarding a component, so that really starts to add up to certain items. Then another big point is, and like I stressed this already, is the quality of each of these components. Because every squad can determine their own quality, right? Because they're owning the journey. If they're creating a component, they own the components, so they can also decide a bit on, "Are we doing this fast or are we doing this good," right? Everybody has made or has been in that position, is that you would need to make a choice like that, right? If you want it fast or want it good. So what you really see, and that's also, again, if for instance the LSA Guild or the overarching LSA Guild would see a component which is maybe lacking a bit of quality, et cetera, is you would get some feedback from your peers. And what we also see is that that feedback is far better to get that from your peers than get that from either management or design authority or yeah, I dunno, from somebody who's policing basically that component. So you would really see is that people also again are motivated or intrinsically motivated to really build for quality from that part. So it really helps out in not being or not having that much technical depth in your system. And last but not least, and that's really one of the business outcomes also is speed. So with the components, and like Vincent stated, right, is in that layer cake approach. If you would have the first couple of layers already set up for a squad and you just need to focus on connecting all of the components, or just mixing and matching what you want and maybe connecting a different system and create your workflow on top of that, great. That really creates speed. And that would add up to a couple of these numbers which we also put on there for reference purposes. And with that is, I don't want to take up any more of your time, and maybe also open up the floor for some questions. So thank you very much already. The mic not working? Ah.

- [Amit] If I could just ask if that's all right.

- Yep.

- Oh, there we go.

- Yep. Okay, thank you. Hi, Amit Sarkar, I'm a manager of Center of Excellence Programs at Navy Federal Credit Union. So we've also built a Center of Excellence and a Citizen Development Program that's working across the enterprise. I'm very interested in the governance of your Guild structure. We are starting to see the emergence of the LSAs within the business, and the structure you described I'm presuming is largely development or technical folks based. Can you have that model operating within the business as well, and can you have lines of business owning components? I would imagine on the application level, maybe you can. But that would require a level of technical competence that I wonder how that would work in the Guild structure.

- Yeah. Yeah, well, a couple of things. Firstly, within the squads that own the component, right? Or own a component or journey is also businesses represented as a product owner, and together as they own the product and they make the choices on what to do. So business is of course already involved in these kind of things, and also in the decisions that you make. In the Guild structure itself, we didn't see that yet, but yeah, it could happen. Why not?

- Would your leadership be open to that? Is that something that you imagine that both IT and business jointly owning is feasible? Or do you see- It sounds like you've taken this concept farther than we have as yet, and I'm very curious about do you see on your roadmaps that happening in the next, let's say, year or so?

- Honestly, I don't think so. Yeah, but yeah, never say never, right? But at the moment, I see that mostly it's IT people who run the Guild and who are present in the Guild and take on those results towards a squad where then business is involved, et cetera, et cetera. So yeah. That's amazing.

- Wonderful. Thank you.

- Yeah, thanks.

- Okay. Hello, my name is Mark. Ralph, I really love this model and I think for everybody would be a big pleasure to work in this decentralized way, but I was wondering, seeing that the responsibility is moving to Guilds and peers, how does management respond to losing a bit of control in that sense? Or how did you manage that they did not see it as a problem?

- Yeah. Well, it basically also is an agile transformation of management, right? So I think that is the core of the answer. It definitely is a bit of a shift, let's state it like that. But yeah, mostly also management really loves it. And the reason why they love it, because you have people who steer quality within the box that is Pega, which for management, at least for me and also for my colleagues, is nine times outta 10 a black box. So you don't know the internals, right? So you need to trust it, and then you put your trust in a group instead of to one architect, for instance, who can also have an off day, right? So yeah.

- Yeah, okay, so it's also about taking time and seeing results?

- Except for Vincent. Okay. Thank you.

- Thank you. Thank you for the presentation. We're on our way in this direction, so it's exciting to see that you guys have found success in it. I'm wondering if you could share on the reusable component side how you catalog that information, maybe a little bit more about how you document that. And it's a significant team that you have there, is there a way to actually look at the information and find the source of it?

- Yeah, so that's also the responsibility of the LSA Guild is also to update that information. So the catalog basically of the components, versioning, all of these kind of things, right? So that all comes together there. And for us to give you an example, it's mostly on Confluence and Teams. So everybody can see it, everybody can open it, everybody can add on top of it. So yeah.

- I will-

- So we- Sorry, go ahead.

- One of the other things that, if you've been to the innovation center, you may have seen the enterprise reuse library that's being launched as part of Infinity '23. Definitely another great opportunity and place to go and register the reusable modulars or components and build those things, pull them into your application. This concept, this topic around modularity and enterprise reuse and really democratizing things throughout the low-code continuum is a key focus for Pega. So with this release and over the course of the next year, I think we're gonna be seeing more and more coming through to make the cataloging and management of reusable assets much easier to find, manage, build with, maintain, et cetera within new enterprise.

- All right. Thank you for the presentation. You mentioned that you don't have a platform team, which I find quite impressive. You can make it work, so that's good. I was wondering how do you make sure that the teams take their responsibility when there's an incident, for example, and that they collaborate well together, especially when it affects multiple teams?

- Yeah. Yeah, also good question. And this is more, again, on the agile transformation of your organization, right? It's putting responsibility as low in the organization as you can. So if a team would own a journey, they're also responsible for the uptime of the product, or if customers can't reach your sales application, for instance, then they need to, yeah, need to take action. And the key there is that we give the teams a purpose and we really share that responsibility also to them to try and make it as clear as possible what is expected of everybody as a group basically. And also as management, because that's not always easy, right? Because I also step into that pitfall sometimes, is when a problem occurs, I want to steer, right? So I want to take control and basically start solving the problem. And yeah, that's something also as management is that you need to learn to to, yeah, again, just push that towards a team. Ask a question instead of solve a problem for the team. So if you ask a question as a manager, okay, the application is done, great, what are you guys going to do now? And yeah, that might not all, or that might be a very difficult discussion at first, but you'll get the hang of that pretty quickly actually.

- Thanks.

- Yep.

- Thank you for the great presentation today, and it's amazing to see how you have gone on this journey. My question is more around how do you manage the run support of your applications? Does it reside within your business scores or does it reside within your scores, or do you have a separate setup for the run support of the applications?

- Yeah, good question, and that's a good point because I forgot to mention that. As Rabobank, we work DevOps. So if you build it, you run it. So a team is responsible just not for building the component but also for running it. So if problems arise, right? Or a feature needs to be added or revisited or whatever, then that's the responsibility of the team.

- Thank you. Just to follow up on that, run support would be more like saying, "This is a level one incident or change" and so on and so forth.

- Yeah.

- You have got that being managed by your own business unit teams?

- That's mostly also managed by the squad themselves.

- [Audience Member] Wow, okay. That's really a great way to manage it because that way you also reduce your BAU costs and transfer it to your businesses.

- Yep. Yeah, true.

- Thank you.

- Thanks.

- And I think we're over on time. I know that there's one gentleman stepping up to the mic. Do we need to wrap up, or can we take one more? One more? Okay.

- Hi. It's a nice presentation. I have seen a lot of technical stuff and architecture designs on this one. I have one question. So from the onboarding perspective, I see that you are doing onboarding of new customers, right? So are you building anything like a Guild structure for risk and controls within your agenda?

- Maybe. I don't really understand the question. Did we build a Guild structure for risk and control?

- So the thing is, you are onboarding customers, right?

- Yeah.

- [Audience Member] So you have your own Pega Cloud. So within the Pega Cloud, you have the Kafka streaming APIs, which are actually doing the transformation of all the data from one tribe on another tribe. And at the same time, you have the Splunk, which is doing the alert monitoring and other systems. So you will have your own data centralization at one place. Correct? So now with this onboarding, so today it can be an onboarding of new customers, tomorrow it can be a line increase or supporting of a giving premier accounts for the existing customers, like private clients, et cetera. So in order to do that, do you have some kind of the mesh system where you can handle the risk and controls across multiple products?

- Yeah, I'm not 100% sure if I understand your question. So let's say if you would add new functionality to the Pega Cloud, we would create a new business service for that, and for that business service we would have a template. You have to have your Splunk in control, where your security data is going, where your operational monitoring data is going, and all the testing you have to do to be compliant to all the regulations you have as a bank, because you have to push that. So basically there's an entire checklist you have to do before you actually can push something live. Pipelines have to be compliant and everything.

- [Audience Member] Yeah. That's the question, right? So why I am asking this is, for each and every product, from the customer experience perspective and customer onboarding perspective, you'll have different sets of risk and compliance, and also controls. So when you actually streamline those controls like in a horizontal line across your vertical products, then this will create other Guild structure so that you need not change any of your or onboard any other risk platforms, instead of holding everything at one place.

- Oh, yeah, so they start the same, but we add another functionality to that. Yeah. That's correct.