PegaWorld iNspire 2023: Strategy and lessons learned enabling low code citizen development at scale

This session focuses on empowering non-technical individuals to become citizen developers and leverage low-code development platforms.

We will cover an approach to establishing a citizen developer program at scale. We will share tips, tricks, traps, examples, and ideas along the way.

Transcript:

- Thank you all for coming. First of all, let me just say that, you know, I felt like I was back in the Zoom age, where, can anybody hear me? You know, we're still on mute. And now we had to unmute. But I'm delighted to see everybody in person here today. My name is Fritz Von Bulow, and I'm a client technology officer working for Pega. So what does that mean? I work with Don on CTO things, but I also work directly with all of our clients, some of our largest clients, on their most pressing technology problems. And so our talk today is really about, what does it mean to enable a citizen development program at scale, and what are some of the tips, traps, ideas, and lessons learned? And so we're going to go through some of that material. I will say to you that as we do this, you'll see that we sort of have some lists. I'm certainly not going to talk about everything on here. However, what I would encourage you to do is sort of think about this. When I was a customer, I always used to think about things like this. What was the thing I missed? What was the thing I should have done, and if only? So that's sort of the genesis of this presentation and the sorts of things we want to talk about today. So first off, what is citizen development? Well, lots of definitions. I did not ask GPT, but I polled my peers. I polled our clients. And so the key here is it is non-technical users who are developing applications on their own. They may have come from a non-development background. They may have come from building a Tableau dashboard. Those people, we want to enable them to build their own applications. And why would we want to do that? Well, a couple of reasons. Well, first of all, because if I can bring IT and business together, I can go faster and I can unlock new value, and I can get to the things that people want to automate, which might never, ever make the IT backlog in formal development. The way Pega works in this is pretty key, right? We give you that governed low-code. We give you the ability from a Pega perspective to control the enthusiasm, and we get that at speed. One of the things that we've seen, and we'll talk about some of the case studies at the end of this presentation, but what we're seeing are people building applications really, really fast. We're not talking months to deliver. We're talking four weeks from idea to production for a small thing. And that's a remarkable achievement, and it's something we should all be excited about because it gives us a new way to work together. The other thing that we're seeing, and I think that's important too, is that it gives us, for those of us that have large Pega practices already in our firms, it gives us the ability to scale out. I can have one or two really good Pega developers, work with lots of citizen developers and accelerate an entire program, and we're going to give you a use case and an example of that as well. So these are some of the things we're thinking about as we build out citizen development. So what are some of the recipes for that? Well, first thing, if you went to business school, you're always told to have a mission statement, and I'm going to say this, right, the sample mission statement here is one we tested with a couple of clients, and it's this, let's create exponential value. Let's not reach for little things, let's reach for the big things, and do that, and do that by innovation as well as process transformation. So those things kind of combined to be something everybody can gravitate towards. A lot of times when you think of a mission statement, if you're going to start a low-code or citizen developer practice, it's something that is really your selling vehicle to the people that care and that probably have the money that we're after to actually fund our program. So that's important. The other thing we have to think about is what's on the right-hand side here, which is I need to have a platform. Now I will tell you this, when I think of citizen development, it's not just Pega as the platform. We'll show you that in a moment. But it's how I use it and what I do with it, which means the workflows and things that I build need to be adaptable, intelligent. I've often thought of this as that if we looked at any process, we should think about how to instrument it, how to automate it, and how to make it intelligent. If I do those three things, even for little things, I'm going to achieve greatness in terms of how I deliver value to the business. The other thing I think that sometimes people miss is we do sort of the first thing really well. We do that adaptable, intelligent workflow really well. We tend not to think about what happens with that citizen developer application after I deliver it. What should happen then? One of the things that we have said and tested with a bunch of our clients is this, your job is never done. So if you build it only that first time, you're probably not getting the full value because that second or third application from a citizen developer is going to be even better because they will have learned new skills, new methods, and will have probably gotten even more ideas for how to automate just by using it. And then finally, community. I think one of the things that we often want to make sure happen here is that there is a vibrant community. That can take place in two ways. It can take place at the Pega community on Pega.com, or it can be a community that you build internally. It's important to think of both. But if you do not have a community, you will never scale because you're going to run out of Pega experts faster than the community will grow, and then you're going to be in trouble. So small tip, make sure you invest on this up front. Okay, so we thought about our mission statement. As a CTO, you know, I couldn't not have at least a marchitecture slide. And so here, what I wanted to share with you is this. So Pega, obviously the center of the universe, but there are so many other things that you need to think about when you build out a low-code and citizen development practice, these are things that I would almost consider pre-work. Before you launch the first citizen application, have you thought about your data pipelines, how they're going to be automated? Have you thought about what reporting is going to mean? Yeah, we have great reporting inside the platform. If you looked at what we're doing in Pega 23, there's a lot. But what I also want to do is make sure that I know how an enterprise reporting system might need to interact. I have to consider AI. A lot of firms have their own AI practices. They may have their own machine learning models that we want to get to. There's probably an existing robotics landscape. How do I bring that into the ecosystem and the fold? How do I bring microservices in, external and internal data points that are served through a microservice interface? And finally, I might want to think about how my systems of record will talk to these citizen applications. I would say an important thing here, especially at startup, is that the systems of record, because they are probably sort of the molten core of the firm, especially in a bank-grade thing, is something you want to use as your reference application, not something you commit a change to. So think about that. Okay, so we talked about technology. Next, stopping here, stopping point, as we go through sort of our journey to build this out. I need to do something around governance. Now, governance here you'll see is sort of a three-tier model. Here I have my executive sponsors. I often think of those as the board of directors, the people we report to as we run our program to make sure that they are getting value and that they actually know how we're performing at the lower level as we run the program. I have also suggested, and I think we can be more successful in getting things funded if the executive sponsors understand what we're doing, so key point there. The steering committee. Okay, so here, combination of business IT teams coming together to figure out how we organize. When there, from a governance perspective, this is where the rules of the road are set. What kind of data types are we going to allow, what processes are we going to allow, which organizations should go first? It isn't necessarily the case that I want everybody to jump on this right away. Again, I want to control that enthusiasm, and underneath that, as an execution model, I want to make sure that I actually have somebody whose role it is to be the community manager, somebody who will take the time to build the community from day one. At the same time, I need to make sure that my engineering support is solid. So I need technology teams to work out. And from a Pega perspective, what that really means is I need a team that can do professional development and build those first reuse layers which will be locked in for all of my citizen developers. So that's the key and most essential thing they're going to do is work on reuse first, and of course building this out as a service so that the community knows what's there and so that they can leverage it. And finally, enablement. So one of the things we see, and I think that's also important to recognize, is that the community is not the same as enablement. That's how teams work together. Enablement is the dedicated practice to getting people up to speed quickly, not just the first time, but the second and the third and the fourth time. And this is really a journey as well. And we'll get into a little bit about how that model might look. So if I've organized, I've got my sort of governance, and I would say here, you know, this is a very simple model. If we do this for a real enterprise, there are a lot more stakeholders. There may be, especially in a bank, for example, I might see risk controls, business controls. I might see the audit teams asking hard questions. They may ask, "Well, why exactly is this in the cloud?" And we, by the way, would recommend that if you can do this from scratch, build out your low-code and citizen development track in the cloud, you're going to gain so much flexibility and speed. Okay, so I've done that. Let's talk a little bit about some of the other essential steps here. So one of the things I think, and we've talked about most of this already, but you know, starting up a citizen development program, you really got to think about the services first, right? So from a technology landscape, do I have the reuse? Have I integrated with the corporate directory? Have I found a way? Because here, what's interesting to me is that those first applications that people build are typically something like this. We're going to gather some documents, we're going to have somebody read them, then we're going to send off an approval chain around those documents, and I'm going to end my process. So if I looked at that in App Studio, I might have six or seven steps and stages. Nothing complicated. However, one of the things that often comes in there, which would be a good first thing to do is make sure your reuse layer has things like email send built in automatically. You don't want everybody to struggle with that. You want to make sure that it's easy for them to add people. Because even though we would say, "Well, there's work queues if you're an expert in Pega," there's other ways for people to assign work. The simple workflows tend to be person-oriented for first, because that's what that little work group thinks about. That's a good example, sort of reuse. And those are some of the essentials. The other thing, I think that you should be careful who you choose first. So picking the friendly audience as we start up the Center of Excellence and then think about how you're going to build up that awareness and the education components. And then I think the other thing that we, I think, have seen now, having seen a few of these programs go through, is the importance of getting a formal intake process set up up front. The first day you open the doors, there's going to be a couple hundred people, "I'd like to build an app." Well, some of these apps might not be the best apps to build. And so we want to make sure that we have that intake process. And if you remember from the landscape before, some problems in some citizen-developed applications might not even be workflow. They just may be a highly complicated reporting request, but we should still gather them, route them to the right people and the right teams to deliver them, but know which one it was. The second benefit of the robust intake process upfront is I can start to capture the metrics so that over time I can get to a proper understanding of ROI. And that's another sort of essential thing. We'll talk a little bit about score cards in a moment and sort of Fritz's recommendations there. And then as we do that, we're going to establish the community, and you'll see here I talk about lightweight scorecards in that startup phase. I would say that the last thing you want to do is measure to the millimeter exactly how much ROI and how much value and how much time something is saved upfront because you won't know. And the first ones, what's important is to build success and enthusiasm, much more so than every single one being weighed and tested. As I scale out, I'm going to build on success stories. The thing that is so interesting to me is that success stories and the community that supports and understands what it is citizen developers can achieve is by far the fastest way to grow the program. You should set an ambition not to have 10 or 15 citizen developers, you want hundreds. And to get critical mass is going to mean the community understands and appreciates it, not that we're always telling them what to do. So we talked about that. So hundreds of applications would be a good ambition. 500 plus citizen developers. And something to understand here, that if I enabled 500 teams or 500 people in teams to build new apps with low-code, some of them may never actually completely activate, but they will have an appreciation and can start to draw even simple workflows, even if they hand them off. So it's a huge value just to doing that because now I've gotten a commonplace for IT and the business to work together. Increasing complexity, I think, we'll talk about that and we'll get to consistent metrics and monitoring. But those are things I do after I've started up. If I do it too early, that's all people are going to be focused on. All right, scorecard. So let's talk a little bit about that. Two things here. So application success, it's important, I think early on to think about time to value as the most important metric. How fast is this application being built? You're almost in a race. If the first application takes you six months in citizen developer land to get active, that's a problem. So you need to be strict and find a way to accelerate that time to value. Over time, you're going to think about return on investment. Now that could come in a variety of flavors. It could be time saving. So I've reduced the manual effort, say for example, for an application that does a simple HR task such as offboarding contractors, maybe that set of steps is well understood, but it's done in Excel, it's done in email, and perhaps that can be cut in half or more if I were doing it with a Pega workflow. So that sort of thing is what you're looking for and being able to declare that even if it were for a small number of people. The other thing there is looking at risk. So a lot of other low-code applications, especially in banking, these citizen development ones, are really built around managing a risk. I'll give you an example of one of those that achieved not necessarily a time savings, but a business control. And that's just as important as whether or not I saved time. And then from a community perspective, I really want to think about are people enabled, are they active? Are we seeing experts developing in the community, helping others so that we in the center of this thing, running the local program, aren't the only ones providing answers? And testing that and kind of going back through that over time is really important as we go forward. So if we're doing all that, another recommendation I would have, and this is certainly again borne out by understanding what we do, is this. Think of everything you do for a citizen development program to be centered around that developer. It isn't centered around IT, or governance, or risk, or control, or audit. Those are special functions. They probably should be developing in low-code. But what we want to do is focus on what exactly that developer journey looks like. So up front, I want to make sure I'm generating interest. I want to make sure that the first introduction that they get to a low-code program is great. And the way you might do that is put together some workshops, get them hands-on early. Once I've done that, I really need to shift gears and consider how are the people that I took through that interesting introduction stage and get them into an activation. I want them to build something for real. I want them to perhaps use design thinking. I want them to think about the data they're going to gather. I'm not telling you to create a complete process re-engineering stage here. What I'm telling you is to do enough so that people start to build. And once they're building, we want to make sure that that particular stage is really simple and clear. I want to give them on-demand technique and support. That could come through mentors, it could come through peer assistants, it could come through how-to videos. In fact, you'll see if you, we'll talk about this on the enablement pages here. We've done a bunch of things recently from a Pega perspective to make that easier. In fact, we have a new magic trick we'll talk briefly about as well. Then there's that first application. I want to focus on value. I want to focus on the fact it got tested and deployed. And a word on testing here. For a citizen-developed application, I'm not doing rigorous CI/CD testing, unit testing, integration testing. I don't need an automated test suite to do this. The focus from a test pyramid perspective is really on user acceptance. They're the ones who built it. You own it, you test it, make sure that it works. And of course from a Center of Excellence in the middle perspective, we're making sure that the platform itself is robust. So that first application, as it goes into production, we're going to do a quality check on it to make sure that it doesn't violate any surprises. But if I've built this whole thing in App Studio, chances are good it's going to work. Then we get to that second application. I'm going to increase my confidence as a citizen developer, and that's also because I've gotten more independence. I've learned the hard lessons up front. A little while ago I did an interview of about two dozen citizen developers to ask them how their journey was going. And what was interesting to me is that the first one wasn't necessarily four weeks from idea to production, it was longer, because they had to go through that first initial learning. They really had to get underneath the covers in Pega and kind of work on it. They needed more assistance, so it just went a little slower. Those then, and I asked them, "Well, so are you ready for your second application?" And the answer was yes, because I learned so much in the first one. But you know, we had to break that glass ceiling and kind of get through that particular set of challenges, and then we've got to that confidence stage. From there you're off and running. You know, that might be the same application iterated or it might be a new one entirely. And they're mostly self sufficient, certainly an ambition, but it's worth worthwhile getting there. Along the way, you will also see, and especially in startup mode, that the questions that the citizen developers ask may be, how do I integrate to X? And that's a great source of inspiration for the core team to figure out what should we add to our reuse layer that we didn't think about upfront. So that's really important to do that. And finally, at that off and running stage, we're looking to recruit mentors so that we can scale the program. Okay, done that. I'm going to give you a couple double clicks here on, and these are actual agendas that we've run for our clients on what we mean by a low-code workshop. So basically this is that introduction. We're recruiting. We might do these every couple of weeks, and this is a two-hour session that's instructor-led. We might, expense budget permitting, we might do road shows, we might do those sorts of things. But the key is we want to get 30, 40 people together thinking about what it means to learn how to build a low-code application. From that perspective, we are then giving them ideas on what it means. It's an App Studio experience and I can't emphasize that enough. We didn't really talk about it before, but there's a really important business rule here, and that is this. If you're an App Studio, if you're a citizen developer, you should be in App Studio and App Studio only. If you need to go into Dev Studio, and those of you who have used both will see this, what that means is we're about to create a complicated problem. So the right way and the right technique to deal with that here is at that point we need to get the professional developer involved, look at what it is they're trying to do. Parallel cascading workflow lists doesn't exist in App Studio, but it could, right? And it might be specific to the institution or the firm. And so stitching that in and then exposing it as a tile in App Studio is the recommended technique. So just think about every time you hear something from a citizen developer. Is this a reuse thing or is it just they stubbed their toe? At the end of it, we've got those participants, we've got perhaps a mix of pro developers in there as well to guide them along. But we're expecting that nobody there has ever built any application before, and we're lucky if they used Excel. Then and only then, maybe a little later, a couple of quarters later, we may run a Pegathon. And this is the second thing that is sort of the capstone. And this is a little different from that first round of enablement. Here, we're going to take an intense look at a specific business problem, run it over two days, and we're going to combine citizen developers with seasoned developers as their coaches. And so that's another way for us to quickly accelerate applications through the pipeline. And of course, we're going to get also then a second model. And this is something that we found, and I'll share the example with you in a moment. But where that model actually inspired teams to create what we call fusion team, where there would be a permanent professional developer attached for the missions. And that is another sort of approach to do this. But it is certainly possible, and we see this with some of our firms, that they just are often running just citizen developers. And you know, the pro-developers are there as consultants more than anything else. And finally, I can't emphasize enough that throughout this, you have to make sure that you're discovering those reusable components. So that's sort of the Pegathon. You know, there could be selfies, there could be lots of reasons and things that happen here. Ongoing support. So sort of, this is, again, I was thinking about this, this presentation is sort of a list of lists, right? I'm going to add, just tell you to do this. I didn't have the URL when I wrote this, but the Pega Study Buddy is a large language model trained on every piece of documentation in Pega. And if you look at the screenshot here, it's a little blurry, sort of, kind of. I asked it, "How do I create a parallel approval flow in App Studio?" And back came the steps. Fritz, you should do these seven things, and you will have created parallel approval in App Studio. And so that's on-demand. And that in my research and talking to all the citizen developers, what they really wanted was to never talk to a human being to write their app. They wanted to write it themselves. They didn't want to have to call anybody, they didn't have to wait. And so consequently, things like Study Buddy, I think is probably really a breakthrough component on that. We've also recently on Pega.com, in the Pega Low-Code Community Forum, created 20 some videos which are again, visual cues to how to do a specific thing, like the parallel approval workflow. And again, those are on-demand and we've specifically tuned those kinds of things to make sure that you could stay and do this in App Studio, which is a lot more fun than if you had to sort of go find a pro-developer who was busy or on a vacation, all those things. Another thing that we've seen here, especially for ongoing support, is at some point, and this can be community-led, there's an expert walkthrough. And so one of the things we're also seeing in sort of an every two-week cycle on communities is that the citizen developers demo to each other what they're building. And so that's a great way to get people to talk and think about what else could I be doing and how else might I initially innovate. So we've talked about support. You know, the other thing that we have to think about here, and this is again an evolution, right? We're really focused on that governed citizen development team. But what we're also seeing is that some teams start that way and then they graduate to a fusion team where they start to add citizen developers, and with professional developers, and start building out teams to do much, much bigger projects. That's not sort of the enterprise level that we know and love. You know, it could be exception handling for Swift or something up there in the blue area, but what we're talking about are new applications that are built from scratch. The other thing we're seeing in the fusion team space, subject of a completely presentation, maybe next year, is the idea of reusable mini applications that could be chained together to build a bigger thing. And so that's something we're evolving. Not ready to talk about that yet, but we're excited to share when we do get those results, maybe sort of half time, we'll throw that out there too. On the backend. Recently I was asked a couple questions. Well, so Fritz, this is great. We're running in Pega Cloud, and I'm going to give you three lines here. Red is the line of failure. And what we're seeing here is that as our low-code team, the core team is operating and running. That red line is really about the complexity of the applications that were built in the low-code environment and that they were all straying from a standard. How does that happen? Well, because I didn't stay in App Studio, I let people off the core mission and all of a sudden I've got these highly complicated applications and I can't sustain that as a core team. So my job within the operations team is to flatten that curve and get to green, so that in a single instance of Pega, I could have 150, 200, 300 applications, and I can manage them as a fleet. If I can do that successfully, what's going to happen is I can also start thinking about a continuous Pega. What I mean by that is that as I build my applications, they're staying in App Studio. Got a pretty good guardrail score for the most part. When Pega 23 comes out, I can take it almost immediately, because those applications are robust enough and built in a way so that I can continue to operate them and not spend all my time worrying about which application needed to upgrade, or I can't get to Pega 23 or Pega 24 because this one app is stuck with a weird thing they did in the wrong way. And so that's sort of the message here. And so my recommendation is you got to figure out how to get to green. And these are sort of some of the forcing factors, and really it's about the complexity of the app. And as I shared with some folks the other day, as we sort of reviewed the findings here, is that the other thing to keep you on green is that eventually you may need to think about how to graduate an application out of sort of the shared instance to be its own thing and have its own life cycle. You know, the topic that sort of the exam question was, "So, Fritz, how big can this application get?" Well, there's no real problem with scale. We're in Pega Cloud. We could do a million cases a day if that was what was called for. But if I have an application that does a million cases a day, probably it's not citizen-developed. And second of all, it's probably enterprise scale, and I'm going to need to accommodate that in a different manner. And so that probably means it moves out. We give them their own space, we congratulate them, we've graduated them out. In fact, some folks have said to me that they consider their citizen developer program an incubation area for innovation. And so it's a place for us to build things quickly, discover which things really are meaningful, and then scale them out to the whole enterprise once I prove them in one or two places. That's a perfectly great reason to have a citizen development program. Okay, two kind of case studies. So the first one, let me put it this way, so reputational risk in a bank is all about whether or not I should do business with this entity, and if I did, is that good or bad? And that's a judgment call. If you remember from the presentations this morning, you know the AI might be 95% correct, and the doctors at 85. These are not life-or-death situations, but reputational risk is important because it's about confidence in the institution that you're banking with. So in this situation here, most of the, in fact, all of the workflow for this was phone calls, emails, chats, and a series of documents that were passed around, and say, "Did you think this is good enough?" And what ended up happening is my friends in internal audit came along and said to them, "Well, you can't tell me who actually decided who should do business with this individual or this entity." And so what we did is we created a very, very simple citizen-developed application to simply do the intake. We didn't say to ourselves, "Well, we're going to do 12 registries, we're going to have an automatic sonar ping to the AP News feed." We didn't to that extent. What we simply wanted to do, and we did this in about four weeks, is get to a point where I could get to traceability. Who actually looked at this and why? And so that's a tremendous value just there, because I've organized that process, it's now auditable. There's no question of how we got to that decision. And that's a risk that we've taken away and taken off the board in terms of this particular institution's issues. So if you looked at what might be next, of course we have to say there should be Gen AI. But what we're thinking about here is specifically Gen AI for document extraction and fact extraction at scale. And then the second thing we're pondering is, is there automatic data acquisition we could do once we have the entity name or the individual? But even just that simple workflow took away the core risk and may never go any further, but back to, what's the next iteration, so. Not really a time savings, but fast, fast, fast. The people who did this, they had done one app before this. It wasn't nearly as complicated or as tricky, and it wasn't, shall we say, as politically charged as something like this might be. But everybody could agree that if we put this in a workflow, that was probably better than email and Folk CRM. Second one, and this is a little bit more of a scale out. And so here, and this is another benefit of a citizen development program. Right, so here the problem is this. I'm a mortgage processor, and I have a lot of back office support through N number of swivel chair systems. So you could do this in one of two ways. This is the citizen development path, where the business is in charge of their destiny in terms of how this application or suite of automation gets done. And so what we've done here is enable business users in App Studio to start to draw their processes. Those processes are then augmented by professional developers. In this particular case, the first application was built. It showed them a couple things. And this is what I think is remarkable about this particular story, is that when they did the first one, they realized how fast they could go and how in control the business could be. And as a result of that, they've now realized that they're going to take all 15 meta-processes in back-end mortgage servicing and chunk them up and do a couple at a time. And over the next two years, they will have built citizen applications for all of these things that tie multiple systems together, and they will have done it primarily themselves. They will have done that, by the way, in Pega Cloud, which is not a bad thing. So they've also gotten the speed advantage of moving things quickly over time. And they're not worried about infrastructure, they're worried about integrations, and they are able to quickly test the workflows with the people who actually use them. So those are a couple of examples of what this means. And eventually we wandered the halls of the booths. We're pondering, can we, if you run enough cases through this kind of solution, start to think about using process AI as a way to create AI learning models, to intercept things up front. So the potential is there. And I mean, that sort of isn't necessarily exclusive to citizen development, but the number of cases and the simplicity of it is probably something that we could build a pretty good model from. So there you go. Citizen development journey in 40 minutes. So that leaves us approximately ten minutes. I am your moderator. I am your answer person. So if you have questions, please go ahead and ask them. And as a former consultant, it's always, well, it depends, but we'll try for straight answers first.

- [Audience Member] Yeah, I guess I challenge you to not answer with it depends, because if you take citizen development at scale, you get to a few hundred applications very quickly. How do you keep any sense of overview, and do you actually need to?

- So, yeah, so there's a couple of really good questions there. So I think you asked, first of all, how do I measure value? And so I think there, I think that's gonna be about what I did in my intake application, and then whether or not I can instrument it, I will tell you that it's, you know, I could do log exploration. We're gonna conduct a science experiment with one of our teams, and we're actually going to think about using process mining to start to tap into that. And we can do that because we're on the cloud in this particular client's case. So that's the first way we're going to think about measuring value. I think the second thing that's really important here is, what is the lifespan of a citizen-developed application? Like, when should I retire it? And we don't really have a good answer to that yet. I think it's early days. Does that help?

- [Audience Member] Yeah, I'm at the same stage where a few loose ends just like move to the next citizen-developed app because it's easier. But the old ones still is around.

- Yeah, I know. They could sort of perish in the sands of time, right?

- [Audience Member] Yeah, but they don't perish because somebody needs to delete it.

- Yeah, exactly.

- [Audience Member] They don't really feel responsible of creating it as well. So do you have kind of like, do you accompany them also in decommissioning there?

- So, yeah, so we haven't really had a decommissioning event, at least any of the teams that I've worked with. I don't think that, again, most teams that I've worked with have done this for about a year and a half. I think you're going to get to a decommissioning question in years three and four, possibly. I think you're going to see two things with decommissioning. The first is I built an app, say I built an app and I did sort of one of these four-week or six-week miracles. And it was for a very specific purpose. I used this app to track, should we say, court-ordered remediations. Well, when the court orders are done, I don't need this app anymore. I could probably archive it. So I could probably understand that in my onboarding. So we know that by 2024, the court order is done. I don't need that anymore. I'm going to need it for historical purposes. But the users will go to zero. And then the second thing I think is, you know, again, if we monitor this, especially with things like Process AI, we'll quickly understand which ones are trending to zero. And I think that that point, as I've done, not with Pega, but with other sort of citizen-developed application fleets, is because you should think about this as a fleet. It's an important thing. If we focus on every single one of these, we just go completely nuts. You have to track, and this is probably done in the onboarding application, who the owner is, and what is the refresh to decide whether or not to continue this thing? Because otherwise you've got this cloud expense that sort of never stops, right? What do you mean? So you're saying change.

- [Audience Member] Somebody owns the application, but then he goes out, and it still has hundreds of users. And that's great for citizen development apps, and the next person doesn't feel as responsible as we would like to.

- Yeah, okay. I see what you're saying, right. Yeah, so that, right, so that is really a governance question. Which is, you know, who exactly is going to represent that application? My recommendation is this. You've got to start by maintaining a robust catalog of what's been developed. And then if somebody says, "Well, this was my bright idea," but I've left, bye, so I'm no longer, quote, responsible." At that point I think a hard test has to be made. And that's really a governance function more than anything else. Technically, I think it's about that robust catalog, and, do we actually know who cares? I do think also if something becomes mission critical, it might be time to sort of move that into more of an IT space than strictly citizen-developed. So the way I think about this, this is sort of the shallow end of the complexity. So if I, and as I said on my curve slide, if I have one of those that becomes a troubling child, I really need to think about graduating and making sure it's properly funded. Something to think about is most citizen development programs, the individual citizen developers don't exactly have an IT budget. That's actually why they did this. And so at that point we probably have to have a different conversation. Good questions, though. Excellent questions. In fact, we're going to add that. No, thank you. That's great. Other questions. Did we have fun over here?

- [Audience Member] Hi. I'm just curious as you start to scale up and have many, let's say, smaller applications. At my company we have 26 very large applications and people spend their entire day in one. Is there best practices or could you comment on swiveling between, like let's say I wanted multiple applications up at the same time for these smaller ones. Is that something that you see often?

- Yeah, you know, so I think that's a yes. Okay, so I think what we see, you know, a lot of these citizen-developed applications, they're there to do one specific thing, you know, subcontract offboarding, or reputational risk management. Well, if I'm a risk manager, that's not exactly 100% of my day, but it's the place I go to do that thing. And so I think there is probably a, what you're pointing out is that I've got enterprise applications which didn't fit the need. Reputational risk management was never there, for example. And so, you know, financial risk management might have been, right? And so, yes, you're going to have these applications open. I think the question that then comes up, and we're seeing this in the mortgage example, is as they've created sort of for a specific function a collection of these things, they're surfing those through their actual existing private portal. So it just becomes another tile in a series of functions so that it's easier to access. And you don't actually keep that thing open all day. I mean, reputational risk management is something that is so infrequent. It's not infrequent, but it's not thousands of cases a day. It's one. But we did it, not for efficiency, but for the purpose of making sure that we didn't have a bad thing happen. Does that help? So you see what I'm saying?

- [Audience Member] Yeah, I do.

- I think you graduate them to a portal, you've got to think about how to tile them. And that would be sort of my recommendation of what you need to do to, otherwise you're going to have unorganized chaos. About 100 things. We might have other examples of that too, but I think it's early. A lot of firms I don't think have gotten that. I think the 60 enterprise applications, everybody kind of gets that, right? They could be Pega or not. So, excellent question. Other questions, over here.

- [Audience Member] Hello. So especially when we want to scale up the citizen development, like where they are trying to build up multiple smaller applications, it is easy to manage. But what happens is like more often the teams will change and the work has to be transitioned from one application to the other application. And people want to have access to multiple applications based upon on their roles changes, right?

- Right.

- [Audience Member] So like what are some of the recommendations if you try to have smaller set of applications with more work types so that work can be transferred and completed because the life cycle is more, rather than trying to have smaller applications? So how do we manage the balance between having too many applications? Because if I want to transfer an item from one department to the other department, if it's in the same application, it is easy to move to a different queue versus trying to create a case in a different application.

- Yeah, so I think there's a couple things there, right? So the first is sort of what's the reach and range of a specific citizen application? And so, here is some work that got done, and at the end of that process, the process didn't actually end. It actually meant the next department had to do their thing. I think you have sort of two choices there. You either start to think about, and again, I think what you see, especially with the citizen app, is it starts with one department, but they have friends, if you will. They have the next people down the street, and it's more likely that they'll recruit and expand the core application than build the second one. That's, again, a governance question. That's why in the intake process, you can actually, once you've done 30, 40, 50, 60, and they're live, you'll have a pretty good idea, right, of which things are covered. And so when the 61st application goes through, you can then ask the question, "Okay, well, so, should this really be added to this one? Should you guys team together?" Remember, these are people who don't have an IT background. But that's why you need that governance layer. And that's why intake is so important, because otherwise, you know, if I just say yes to everything, I'm gonna get a mess. So that would be, I think it's about the intake first, and then if over time, you wanted to sort of put together and merge two applications, I mean, that's certainly doable as well. But now you're in sort of professional developer land, and who knows what happened, right? I often think of these applications as sort of little containerized things that do one or two things and they do them well and they met the need at the time. Back to the question on also, when do we retire that thing and make it better? And that one of two things is going to happen. That iteration two, MLP-2, may be an expansion horizontally into the adjacent work state, workplaces, or work items. Remember, also, if I think of big Pega applications, enterprise-wide, I'm going to get into much more robust case management. The things we're talking about here are things that never qualified for enterprise application deployment. So great question. Thank you.

- [Audience Member] I won't just take much of your time, but just trying to extend on whatever the statement you said before, like where we have big enterprise applications. So, and we do have users who want to maybe work on something smaller. So is there a way you recommend to maybe decompose some of them from the enterprise and get them into low-code and see there can be seamless integration between that? That's something that's feasible or recommended, or you say it's not?

- So that's actually, that's a loaded question. So there are actually two questions, I think, in your, in sort of the problem statement. The first is if I have an enterprise application and it's large, and it may serve many, many people, but this one team only wants to use one part. I think I would hesitate to say that you should write a low-code application to get around that. I think what we have seen people do, and this is sort of the mortgage example, is they will look at combining across both Pega and non-Pega systems to create a comprehensive view. I think that would be my recommendation. I would have to have a deep pause before I said, "Oh, let's write five more apps." More likely, different talk, come back next year. We are doing work on what it means to take a large Pega application, an enterprise-class application, 6000, 7000 custom rule sets, and decomposing that into smaller blocks so that I can manage them in parallel. That is ongoing work. So, like I said, come back next year. We'll talk about that. That's something we're thinking about deeply, because we know that in today's world, the big ship doesn't move as fast as the little ones. So, great question. I think we are like, okay, I have a very important announcement. I am between you and Alan's chess match. So if there are no more questions, thank you so much for coming today. We'll see you next year, and have a great afternoon.

Tags