PegaWorld iNspire 2023: App Modernization: Path to Greater Value of Your Pega Applications

Would you like to take advantage of the latest advancements in Pega technology? Adapt quickly to changing user and customer demands? Improve operations for faster, more stable enhancements and quicker outcomes? Operate on modern, scalable infrastructure? Learn about EY’s Pega application modernization framework and approach to ensure you are in the best position to quickly adopt Pega’s latest features, in an application designed to scale and adapt to the future.

Transcript:

- Welcome, I'm Suzanne Clayton, I'm the senior director at Pega for the EY Global Relationship. So, I'm gonna introduce the folks who are gonna be presenting to you today, and kick off the session. So, this is the App Modernization session, and our guest speakers are gonna make a case for application modernization with an overview of a tested approach, methodology and tool set to drive maximum value for clients, looking to upgrade your Pega legacy applications. I think everybody listened to all the Pega executives talking about how important it is if you wanna leverage all the Gen AI capabilities, to make sure, you know, you modernize your applications, then you can start using all this really fantastic AI that's becoming available. So, let me introduce our speakers. So, we have Mitch Kenfield today, who is a Principal in EY's technology consulting practice, and leader of the firm's Digital Platforms group. He has over 22 years experience helping clients drive business transformation through digital technologies from customer employee experiences, to complex business and workflow automation. Mitch is from the fabulous state of North Carolina, which is where I'm also from. So, welcome, Mitch. And we have Anupam Vachaspati, and he is from Dallas, he's a Managing Director in EY's Digital and Emerging Technologies Pega practice. He is focused on helping financial services clients realize value through digital transformation. In earlier roles, he led DPA adoption and application development at top U.S. banks and technology firms. So, I just want to say one thing before I step off. We are gonna do Q&A at the end, so there'll be plenty of time, so as they're talking, think about your questions, and then when they're done, we'll kind of have an open Q&A session.

- Awesome.

- Thanks.

- Thanks, Suzanne. All right, well, welcome, everyone. Let me make sure I'm on. Yep. Good. So, first of all, highlight the instructions on here from Menti, I'm sure most of you probably used this, but we wanted to try to find a way to gather some interaction and reaction as as we go through. And don't worry, there are no questions about the quality of the speakers during this, that's after, so. But seriously, there's a few points that, kind of in the flow, and we'll use that to kind of tailor our responses in a little bit. So, Anupam and I are happy to be with you today. The first question, if you saw that with Menti, I can go back real quick, so, "Why are you interested in app modernization? Why'd you show up today?" So, again, just to make sure, Menti.com, and there's the number, I'll pause for a second. 6874 3706, if you can remember that. If you're logged on and getting pictures taken, good. Looks like everybody has at least gotten that. So you see some of the answers that are coming in, okay, so let's start on a couple of these. One thing we'll talk about, as Suzanne entered the conversation is, we're gonna have two flavors, if that makes sense. Some of this is taking your current Pega implementation's architecture and modernizing it as needed. Another we'll talk about is the broader space of low-code platforms, and is there an opportunity to bring some of that onto the Pega platform while you modernize as well, so we'll touch on that as well. But so you see some key topics here, Anupam, I don't know if you wanna call out any of these, you see upgrade, performance, latest features, another common one. Anything to point out there, Anupam?

- [Anupam] So, I think... Are you able to hear me all right? Okay so, I think a number of these themes resonate well with us, and you'll see them in the talk track as well. Having run Pega at scale for many years, you know, I have firsthand experience with the kind of complexities that you get into when you are looking at upgrades, maybe just a tolerance upgrade approach, versus looking at new platform features capabilities, and see how you can sort of leverage them, right? So, a lot of good tags are coming in, and as we get through our conversation today, you'll see we will hit a number of those features.

- Perfect. Okay, so if we step in, we'll start showing, you know, walking through. And there's a couple of them on here that I think really will tie into this first message a bit. So, we're gonna start a little bit, kind of 30,000 feet, if you will, and give you a perspective of what we're seeing across what I would call "platforms." So think application configuration, low code, no-code-ish type platforms, some broad themes we're seeing. First of all, as I would imagine most of you expect, they're very top-of-mind in our clients. When business needs and use cases come to them, I would argue that these are becoming the first place they come to, right? There's legacy, large scale kind of software capabilities, like ERPs, and systems of record, and HCMs, and those kind of things, and they clearly have their purpose. And then all the way over here there's like, custom engineering, and so on. Well, I would say this space here is definitely taking off, and it's becoming kind of the first, "Can I do it here?" Because, to these other points, now I have opportunities for agility, I have opportunities for scale, you know, those kind of things. And for those of you in the room that, you know, are developers and love the technical aspect, we actually do not see, and see the opposite of this kind of displacement of low code. So, you see a little thing on the right here, I think it is a citizen development, we're seeing, actually, it's the opposite. A big trend where our development community is it has more work to do than they can frankly handle, and then some of that work becomes how do they enable or support distributed development organizations as the scale of development goes around. And I think even with the sessions yesterday, and the keynote around, you know, Gen AI, and code generation and stuff, that's not gonna slow things down, I think it's even gonna make our need for strong developers even more, because now it'll be setting standards, and validating that code generation is the right way to do it in other things. So, that's all on the positive side. But on the challenging side, if I were to say we just met with 10 client organizations, seven or eight of 'em probably have this challenge of sprawl and tech debt. And they have it within each platform usually, and I would argue that they have it across platforms. So if you take Pega, and then you take a number of other platforms that they have, most of your organizations probably have more than one, and most of your organizations, I would argue, would say, "You know what? We like the technology, we like the capabilities, but are we really getting the true value? Are we using the latest capabilities? You know, frankly, in some sense, am I getting what I paid for it? Can I deploy fast enough? Like how do I make sure I stay on top?" So that number three is super important. And then finally, this concept of how do we make sure these are business-led, process first? When we did that last Menti, it was interesting, a lot of the things that kind of bubbled up were a little more upgrade, latest features. I would say what we're seeing is drive these by the process side first, and do the upgrade and support of those business capabilities, and they're a lot, you know, easier is not the right word, simpler to justify and push. So the picture on the right is just some of the kind of key considerations. We won't talk through those. I will highlight real specifically, just to kind of touch on one, that idea of emerging technology, meaning how do we make sure we're taking advantage of the latest capabilities of the platform? As I mentioned before, I think if you line up a number of organizations, many would say we can't take advantage of some of the latest advances because of where we're at, because of how we implemented, and so on. So, there's a little bit on this slide, I just wanted to kind of say, here's what we see as a common portfolio, or challenges in the overall application portfolio. So, what does that mean? Again, not just Pega, looking across your application space in your organizations, some things that we typically see in our organizations, that maybe you could kind of consider as kind of the drivers for change, the case to do something. And many of these you mentioned, I would just real quick highlight, first of all in that quote, that concept of tech debt is real. And it's hard to see a little bit with the spotlights, but I saw some head nods earlier. In most of our large clients, the complexities of what they have, and the difficulties of changing that become a barrier to doing new things. And not just getting the latest feature, but even a barrier to new use cases, and new workload, if you will, on the platform. And as we just heard from yesterday, and in this morning's keynote, the ability to do things faster, and take advantage, and be on scale with our business is super important. So that tech debt thing is a real factor and issue. The only one I'll highlight in the left side specifically, we talked about sprawl, but on the governance and architecture side, we're gonna touch on that a little bit, I would just say we have a lot of our clients, or our organizations we work with, that have a good intent on the governance side, I would say it that way, but maybe their governance is a little more focused on, did they check the right boxes in a process, versus, "Why am I doing this? How did I structure my organization?" And some of those kind of things. Maybe an easy example is even the concept of a COE. In a lot of organizations, a COE kind of becomes a center of technical skills that are ready to do something when asked. I'm being a bit facetious there, simplistic, I recognize that, as opposed to maybe a center of true excellence, or even enablement, so how do we take this capability and bring it to our business? Are we proactive about demand? Are we prototyping and doing hackathons to understand use case? Are we bringing them the latest capabilities and those kind of things? So even that little bit of a mindset shift, so, any ones on here, Anupam, you'd highlight.

- Well, I think the COE point is actually very, very important, because the focus of a COE is not just doing things right, it's also doing the right things, and also looking ahead, and looking at new platform capabilities and features that you wanna bring into your stack to be able to leverage them, and being able to lay out that roadmap for the road ahead.

- And, you know, to add that final one on that one, I think that also applies different skill sets, different kind of structures of the COE, and so on, which we'll touch on. And all that kind of starts to lend towards this, how do we stay modern, how do we stay current, if you will. Okay, so you'll see some key success factors that that just kind of switched to. We'll talk a lot about these later on as we go, so I won't touch on these too much, with maybe the exception of calling out that number four on there, with this kind of, how do we have a proactive approach? And so what I mean by that is, back to that governance and architecture, an ongoing look at, hey, here are the platforms we use, here's how we're using them. They have some swim lanes, I understand this platform has some great capabilities here, so that's where I'm applying it. I understand how this one connects, 'cause, as we all know, these are ecosystems of connected technologies, right? Whether it's a core BPM or workflow technology, a system of record underneath connected to an experience. How does all that flow? Just I would, as we go through this, encourage a real proactive and forward-looking thought of those. Unfortunately, sometimes it starts that way, and then it becomes, "Oh yeah, we have this tech over here that we configure, maintain, and you know, we have no more requirements for it," if that resonates a little bit. Okay, so as we flow through, there's obviously some small things in here, and I know you all have access to these things later on, but I'll just highlight, we think there are four principles as we start to move into the modernization. And then, as we move into those conversations, we'll give examples of these principles, and we'll start to turn the conversation very specifically to Pega, okay? So, the first thing I would say is, first thing, literally number one, is taking this process-first approach, okay? So, truly thinking about, hey, what are the capabilities, the use cases, the processes that our organizations are doing, and how do we then apply modernization to that? And what I mean by that, it's probably a bit obvious, but just switching that from saying, "Hey, we have a technology, are we on the latest version? Do we need to upgrade?" Well, I would argue, I don't know if we need to upgrade, that should be based on a process kind of structure. Is there a capability in there that is driving that next level of process stuff? To take yesterday's conversation, does the Pega release '23 give you something that now is advancing that process? Okay, now you may want to skip an upgrade, you may want to do that project to recover from where you used to be, those kind of concepts. So, number two on here, this is super important, especially as we talk about large scale modernization needs, if you will, broadening the value drivers. You know, we can't make these all just based on, "What is the cost before, what is the cost after?" Clearly, especially in today's economy, that's an important factor, and probably bubbling up to the top factor. But additional considerations, like, are we driving a new experience, right? Additional considerations about, if we do this, does it enable us to have more use cases and more channels, right? So think about extending the value drivers from, "Oh, we need to modernize, 'cause it might reduce our costs." Well, it should at least have one other factor, I would argue, in that value drivers. And you'll see later, we'll be glad to share this with you, all the details of some of those categories. Third one, holistic solution approach. What we mean by that is thinking from the beginning of the end. And what the details of that actual framework show is from the beginning of a, "Hey, here's where the use case starts," to the end. And those little colored icons are all the different things that happen, like the UX, you know, maybe there's OCR, maybe there's automation here, maybe it connects, you know, there's the core workflow, all those aspects of it. Let's think big, not just what lives in one platform. Maybe we modernize a platform, and we're also modernizing a kind of connective tissue on the other side to take that process-first view. And then finally, we talked a little bit about operating model, the things that need to go in that. Okay, so again, four big areas that we would say those are your principles. Now we'll start to turn a little bit more to the Pega-specific aspects of that.

- Absolutely. Thanks, Mitch. So, let's look at this from a Pega lens, right? You want to establish a good set of guiding principles to guide your application modernization initiative, and you wanna start off with some good questions. This is by no means an exhaustive list, but this is just a sample of the areas you want to look into. You want to understand what you are actually running in your stack, which applications are no longer relevant. And a lot of times, with technology sprawl, as applications are built out in the lines of business, you may not always have good tabs on that, right? How efficient is your use in harvest strategy for that matter? And this is where a COE comes in handy, again, I think we brought out the COE topic early on, this merits its own session altogether. How do you drive reuse through the enterprise? How do you harvest assets that are built within different projects, bring them into your reuse layers, and drive consistency, drive a higher, you know, agility and a lower time to market, et cetera. Do you have redundant applications? Very often, where we have applications getting developed in lines of business, you could have related needs for which you set up similar applications, and all of a sudden, you're finding your case volumes are very high, and you're doing very similar things, but in 10 different ways, right? Are you really leveraging the latest capabilities and advancements that are coming with the platform? And a lot of times you may not be able to do that, just by virtue of how the portfolio has been managed over time. If you've just been doing basic tolerance upgrades, you might want to ake advantage of the latest capabilities, but you're not there, right? And then, finally, when you take a portfolio look at it, you might find that there are non-Pega adjacent areas that might make sense to bring onto your platform, right, to get added advantages of automation. And by the same token, you might find that you built out certain point applications in Pega that may no longer make sense, because at some point in time, it made sense to automate a process outside of a core system, but now the core system is caught up, right? So, again, as you think through this, it's important to set up these principles so you have the right roadmap laid out, you have prioritization around this. Thanks, Mitch. Let's look at the next. So, why should you do this, right? So the obvious benefits, the evident benefits are reduction in complexity, optimization of your operating costs, and improvement of your risk profile, right? All of those are great reasons why you should do this. But then there are some other reasons as well, finding out gaps in your business and technology capabilities. You built an application, it's been a year or two years, but you find that the business has moved on, there are manual work around stacked onto that application, and you don't really have a good idea of how the application is being used in the field, right? The ability to drive higher business agility. And once you have a baseline, providing a much better decision framework to your business stakeholders as they're looking at future use cases, and how they want to advance their portfolio forward, right? So all of these items are key benefits that can help you drive towards the business case. What we've seen is that, outside of code automation efficiencies, you can derive almost 10 to 25% additional efficiency gain through your modernization initiatives. Now again, numbers vary, it'll depend on what you're running in your stack, what kind of complexity you have, how much legacy you're dealing with, but there is certainly a very strong business case to sort of modernize.

- And, Anupam, one thing I would lastly highlight on this one is that number five. I think it frankly doesn't get enough justice, that once we have things, quote, "modernized," right, we feel like we're in a good spot, now we're agile, we can do things with more scale, we're faster. And, and I would argue probably the most common complaint against application teams is that structure. "It's too slow." "We have too many requirements." "When when can we get this?" "When's the backlog?" It's just kind of a constant frustration, and you can't just throw more, and more, and more, people at it, right? And so, okay, well, if we can do things better and faster, if we're more modern, then that's a key aspect.

- Absolutely. So, this journey is very interesting, it's not without its roadblocks and pitfalls and not to sort of drain this entire slide, but I think one I'll pick up on, and Mitch I'll put you on the spot to speak to another one, is an understated view of your technology stack. Without doing ample discovery, without understanding what you're running today, a lot of times you find that you start off with this vision and strategy of modernizing your applications, but very soon you're in the swamp of applications, and you know, child applications that you never knew existed, right? So it makes a lot of sense to take some time initially to do your due diligence, to get a handle on what are you actually running in your stack, have a realistic view of what it takes, and then go ask for your budgets, funding, and everything else, so you're not having nasty surprises, where things come up and now you're thrown off track. Mitch, anything else?

- Yeah, I would highlight the last one, maybe we'll bookend it, this concept of, you know, I would challenge all of us, as leaders and technology architects, to kind of look left and right, if that makes sense. You know, it's very easy for us to know our space, but understanding the adjacent spaces, and maybe even a competing space, helps us make these decisions better. It helps us say, "Well, okay, now I understand why we have that workload, that use case in Pega, and I'm gonna fight for that." Or to your point, "Well, maybe that thing has been advanced in that other core system. Okay, let's talk about that." So, having that perspective I think is key. It breaks down a lot of complexity, and frankly, you know, just clogs, if you will, in our organizations. Okay, so another Menti we have on here, to give you all some time to input some answers, what are the biggest obstacles you face for modernization? Let's see how things are coming in.

- [Anupam] Some very interesting trends coming out here. Skills, bandwidth alignment. Cost justification, that's a great one.

- [Mitch] Yep.

- [Anupam] We'll talk about that.

- [Mitch] I was expecting cost to jump up a little. So, now they're getting... But it's interesting that skills still is staying strongest.

- Higher priority projects. That's a good one. Yeah, things coming in sideways.

- Okay. One thing I would say that's interesting about these as we kind of move forward, to me, that yellow one, the lack of a clear platform strategy, it almost influences, makes the other ones harder, if that makes sense. So, it can be underlying a little bit, and kind of symptomatic to the other ones. So if we jump forward, what we're gonna do now is dive again a little bit more into how would you look at this? And again, we'll tie this specifically onto the Pega side.

- So our EY approach to app modernization is actually backed up by battle-tested assets when it comes to methodology, when it comes to process, and even technical assets. And we'll give you a glimpse of one of those technology assets that we have. Essentially, it's a four-step process where you start off with asset identification. And this is where you are looking at your business capability model, you're looking at applications aligned to value streams, you're looking at your baseline, doing discovery, looking at your baseline of what your application taxonomy actually looks like, right? And with that foundation, then you get to application profiling. And application profiling is essentially all about the risk profile of the applications, the availability, the recovery objectives, and all of those operational, and, you know, maintenance objectives that you have, right, and how much traffic these applications are taking, how critical they are. And then coming up with, basically, a view of how those applications map to your business functions, right? This is the point at which you also look at modeling the total cost of ownership, right? Which a lot of times is hidden, because you don't really see the full, it's like an iceberg, right, 1/10th is what you see, right? And with that, you actually get to application disposition. And this is where our approach is slightly different. In traditional portfolio management sort of initiatives, you have a buy-sell-hold sort of model, right? What we do is, and you'll see that, you know, we have a much more nuanced view of it with Pega Lens, and with a tool that we have, QATScan, that we'll talk about shortly, right, that gives you a much more nuanced view of how do you want to sort of tackle modernization of your applications, right? And this is where you're coming up with your target application taxonomy. And then finally, when you get to your business strategy, you now have all of the inputs for your business case, your roadmap, a prioritized list of applications, how you wanna move them forward, and most importantly, governance. Because without governance, everything falls apart, right? So, let's move forward.

- Anupam, real quick on your last statement, I think it's really key, you mentioned portfolio management, and sometimes there can be a gap between kind of the application portfolio look and the details of, okay, how am I dealing with my Pega platform from an ongoing, you know, management, optimization, modernization. But it can almost be a gap in that, and a lot of what you're talking about is connecting those together.

- Absolutely. Absolutely. Yeah. So some of the aspects that are often left by the wayside, because a lot of these initiatives very often are driven by technology, right? It's change management, it's operational model adjustment, if needed, and most importantly, a design council that is, again, driven by your COE. So, you'll see COE all over this, right? You want sort of that central governing body that is driving this as an initiative, as a portfolio across your lines of business, across your applications, because there'll be different application teams potentially supporting these different applications. So if you do not have that central body that is laying out the roadmap, that is tracking execution, that is tracking, you know, the risks and everything else, it's very easy for things to fall apart. Change management is another very, very interesting area, and, Mitch, maybe you wanna talk about that a little bit?

- Yeah, so a couple things on the change side, clearly is there's the change on the customer, the user impact, those kind of things. But I'll actually start by talking about the change on the technology organization itself. Because, as you described it, Anupam, it's complex in the sense that, like I mentioned, we have multiple technologies, multiple platforms, and so if we're gonna modernize, optimize, move things around, how does it flow? And so making sure that the organization understands why we're doing this internally, making sure that we're setting up structures, I'll give you a specific example. I have a large "consumer client" that is taking its COEs by the platform, including a Pega COE, and they're putting in place something over top of it that is across-platform, kind of looking across, letting the organization know, "Here's our top three, here's how we're investing in them. Let's go." And really managing that interaction to the customers groups, so that instead of having five other, you know, parts of the organization, now it's one collective team, and they're looking at maximizing where they have those investments. And I would say on the Pega side for them, it's a huge win, because now the Pega COE, as it stands, really has a whole space to go into, and they have almost like a charter, if that makes sense, to bring the platform to the next level. So that concept of organizational change is both the impact of the modernization, but how do you justify it, how do you bring it about? Because, unfortunately, even some of the terms to a business person can sound like, "Well, I'm gonna pay for a lot of tech stuff so that it's just current tech, right?" It doesn't sound really... Okay, but now bring it to me in a different type of conversation, it can make it be a lot more impactful.

- Absolutely. Absolutely. And with that, I think we come to our next poll. This is great guys, I love the engagement we have in the room. I know you're all very passionate about it, and that's reflected in our Menti poll, so thanks a lot for engaging with us.

- So, how would you describe Pega-specific application strategy? Let's see, the numbers should start coming in in a second. There we go. So, about half aggressively modernize it.

- [Anupam] That's great to hear, you're all on your journey already. I think especially with some of the product announcements we've had with PegaWorld, it makes a lot of sense to be ready for that, right? So, yeah, that's great to know.

- [Mitch] Interesting. Okay, so then we have "Have not started," or "Don't have one," and so maybe we'll give some ideas in this next topic for that, and then regularly adding, the same. So I think what we see often now is, okay, so, this conceptually, or directionally, if that's a better way to say it, makes sense. What are some capabilities to help us decide, to make good decisions and so on? So we started a little bit kind of broad and high-level, now let's get into some real Pega-specific, how do we make good decisions on what to do?

- Absolutely. And for for good decisions, you need good data, right? So we have a tool, a scanning tool called QATScan, and we have Pega Guardrails that do sort of a static rule set analysis to come up with alerts along different dimensions. There are several other tools out there that build on top of Guardrails' warnings as well, right? Now, where our QATScan tool is different is outside of those basic sort of hygiene, I would call them, checks. It also checks for design patterns. Things like data virtualization for example, right? Are you using data pages or not? Or things like, where are your rules in your application class structure? Do you have base classes mixed with work classes? And so on, and so forth, right? So, almost 45 to 50 additional checks have been built into this tool to help you land on a much more informed view of how are your applications running, and what do you need to do, recommendations as well. So, with that, let's take a look at it, and you'll see some screenshots, and we'll have our architects at our booth, so feel free to come and stop by, and we can have deeper conversations as well. So, essentially, it looks at any application across six dimensions: performance, functionality, security, maintenance, usability, and data integrity. And with all of the knowledge IP rules that we've captured, it'll come out with a score along these dimensions that will help you land on, and that will back up basically what our recommendation is. And a couple slides back, I talked about application disposition, right? So, we go beyond the buy-sell-hold, we look at six different dispositions that are coming out of the tool. Now, lift and shift is a bad word, but not necessarily. If you have applications that are doing what they're supposed to do, and just need to be kept up with the latest versions of Pega, it's a perfectly fine disposition to go through. Because it's all of a matter of, where do you want to put your money for maximum returns, right? But then there are other applications that you might want to refactor, because maybe there are deprecated rule sets out there, or deprecated functionality. For maintenance, and for scale, you might wanna do that, right? Similarly, there are other applications that might need re-architecting, right? Again, performance, scale, as you put your applications out in the field, usage grows, your transaction volumes grow, right? So you might come to a point where you might find that certain architecture choices are no longer keeping up, right? And then rebuilding is an obvious one, you might have an older Pega application that just takes too much effort to sort of move forward. You might just want to rebuild it in Pega and do it faster, better, and not have to worry about the whole upgrade effort, right? And finally, you have replacing and retiring. So these are interesting dispositions, right? You might find that you had two very similar applications, let's say you had a credit card application, and a mortgage application, or an auto loan application that are very similar in what they do, right? But then one is probably not used as much, and has a lot of problems, a lot of headaches, you might want to offboard that, and move your traffic onto a common application, right? And retire. So this is the point where we're talking about, you probably built a Pega application a point in time, it solved a certain gap, it's no longer valid, but if you don't have visibility into it, you're still spending time, money, effort, in the care and feed, and keeping up with all of the overhead that comes with it, right? So those are all things that, you know, the whole QATScan analysis helps us land on and guide you in the right direction, right?

- So, Anupam, before we jump into an example, one thing I would highlight on this one that I really appreciate personally is, I love the way we can talk about things, and start to bring them up to manage an expectation on the business side. 'Cause I think sometimes the challenge with app modernization is, again, what the words mean to the business owner of it, and it can seem like, well, that should just be easy, right? That should be quick. And so it's like the easiest example on here is, if I'm a business owner, and I think I want to pay for something that's a lift and shift, but what I really am looking for you to do is re-architect and rebuild that thing so that it's completely brand new, right? So, okay, wait a minute, we need to talk about that.

- [Anupam] Exactly.

- Because, based on this, we think this is a lift and shift, and that's okay, 'cause all we need to do is get it onto the new technology, we might have some small changes, and now we can go. Versus okay, time out, like, you may have a budget for a lift and shift, but to get to where you're going, this is a big deal, let's talk about what that means and why, based on those other value areas, this is bigger than the cost side of it. So, yeah, the cost is, "Eh," but look what we're driving in experience, look at this new product area that we're helping you get into, and now it's a meaningful thing. And to me, that part of the conversation is super impactful.

- That's a very interesting point, Mitch, 'cause it's not a one-and-done. A lot of times, you might do a lift and shift, and then do a refactor as well, right?

- 100%.

- So, again, there are many ways this can go down, it's a matter of where your business priorities are, where are you gonna get maximum return for the investment that you're making, right? So, how does it work, right? So, simple four-step process, you know, we establish, we mobilize it with client teams, and our own EY teams, right, getting access to the applications. And so keep one thing in mind, right, this is one part of the four-step process we talked about. When you come to application disposition is where, you know, typically we run this over three weeks, you pick up one of your reasonable complexity applications to get a good handle on how complicated your modernization path is going to be. And then you can take that, and extrapolate, and build that into your overall strategy and roadmap. Right? So, the way it works is that, you know, once you've mobilized it, we have access to the applications you're running, we have an LSA who will basically, you know, execute the scan, and then look at the results, and then go and look at the documentation and the rule sets for the underlying applications. 'Cause a lot of times, you know, raw output is what you get from the tool, but then it takes an LBA and an LSA sitting with a business, sitting with your architects, to understand the usage of that application, the future roadmap for that application to come out with actually the right outcomes for you. Right? And then, you know, in the report out, and let's maybe get to the next slide, Mitch, the three key outcomes that come out of this are an architecture and design assessment, a view of system health, right, and then finally, what are your insights for next steps? And again, this is different from just a core Guardrail score, right? It's also what you do with it. Yes, I have a Guardrail score of 30, right, I can get it up to 95, and there are many ways to do that. I think, in this room we all know, there are ways to get a Guardrail score up, but that's not the point. The point is to get your application quality and health up. Right? So, with that, I will probably come to the last slide. This is actually a sample output from the tool, it'll assign a score for all of those six dimensions, and give you sort of this spider web chart that looks actually, frankly very, very cool, right? It looks like it's almost like a radar, but that tells you what your opportunity and gaps are, and that directly sort of feeds into how you size your modernization effort, right, and how you use that as a baseline for sizing similar applications that are probably integrating to similar systems, or are in similar process areas, so you can tell. So, with that, you know, that's the content we had, and I know we've been sort of engaging really well in this session, so we'll look forward to some questions. Mitch, any closing comments?

- Yeah, the last thing I would say on that topic, and you all can add some questions here, we've got some mics, so we've got a good 10 minutes left to do questions, whatever, on top of your mind, if you will. But the last thing I would add to that previous conversation was, I think the key aspect of that information, if there is, right, is how can we bridge the gap? How can we bring information forward to our business side to say, "Here's why we need this modernization." And in some cases, it could be completely technical. It could be because our ranking in security is extremely low, our ranking in, you know, scalability is extremely low, and we have got to fix this. In some cases, it might be all about functionality, and okay, there's another option here. And so I think that that aspect of, how do I bring information, is super important. Okay, so we've got about 10 minutes, we can put questions on here, we can pass a mic around. Anybody have any thoughts, questions, reactions?

- Yes, please.

- Yeah.

- [Suzanne] Why don't you come up? 'Cause actually, with the bright lights, it's hard for them to see. So I figured if people wanna come up, I'll just hand it over.

- We can see you now. There's this point back there where we can't see.

- [Gogh] No worries, thanks. Thanks for the presentation, really helpful insights. I'm Gogh from ING Bank Netherlands, and my question is more on the, how do you see this approach in an on-prem situation versus a Pega Cloud situation?

- Yes, so the approach works for both on-prem as well as cloud, it's actually more geared towards clients running applications on-prem. Obviously, when we mobilize this, we'll have to get your permission to run our tool, because we need access to your applications. But then all of the steps, the way they been outlined here, work perfectly well for an on-prem situation as well.

- And then -

- On the cloud, you have, sort of, sorry.

- No, go ahead.

- On the cloud, you have more data points, because you have potentially, you know, if it is Pega Cloud, you have Pega, a PDC running there, and so you have a much better view of what you're running, versus on-prem, you may not always have that.

- Yeah, and I would say like, one level up, the on-prem versus, you know, cloud conversation brings in different decision points, brings in, okay what does it mean from a cost of ownership, what does it mean from all these other factors, right, that collectively go into it as well.

- [Gogh] Yeah, and especially also with the capabilities that are available on cloud versus what is not available on-prem, I think the outcomes can really differ in that sense. But thanks. Yeah, cool.

- Yeah, absolutely. Great.

- We can answer the next question.

- [Ramakan] Hello. First of all, very nice presentation. It's Ramakan Dansiti. There's two questions. The tool that you talk about here, QATScan, that is specific to the Pega applications, kind of now do the evaluation. Are any other legacy applications if you want to do the core analysis application, you know, health check, is that also applicable?

- So, it is for Pega application 7x and 8x. We have other tools though when you look at overall application modernization that cover other technologies too. We'd more than happy to talk about it.

- Yeah, it's a good question. And I would submit, for our organizations, if each of you has like 2, 3, 4, 5, sometimes there's more, but hopefully not too many more, but kind of core platforms and software technologies, I would submit that something like this that's specific to each of them should be a regular part of that capability. And so, yes, we have other ones, but this one is very specific to Pega.

- [Ramakan] Yeah, and second question is that, like suppose if you have a legacy application being used in the organization, right? So, when we are looking about kind of now, the platforming, how much balance we have to put like, you know, sometime we can go far, and sometime we have to basically go balance it out, you know, let's do little bit, you know, uplift, and then gradual, kind of in the progression.

- Absolutely. So, I think the question is, when you're running a lot of legacy applications, how far out do you go, right?

- [Ramakan] Yeah.

- How do you balance what you need to do? And that's where we talked about the six dispositions. That is arrived at in a very collaborative way, so, yes, the tool has an output, that's why we have an LBA and LSA that are sitting down with your business stakeholders to exactly answer those kinds of questions, right? Because, you know, time, money, budget, they're finite things, right?

- [Ramakan] Yeah.

- And that's why you have a roadmap. And that's why it's not a one-and-done. Like you might start at a certain point, and end at a different point depending on what your budgetary realities are.

- And, Anupam, to your point, I think that's another reason why it's not a one-time thing.

- Right.

- It's, "Hey, here's what we ran, here's what we can do this year, let's keep moving." This is a constant focus of what we're doing.

- [Ramakan] That's correct. Thank you.

- And question over here?

- [Suzanne] Yeah.

- [Ronak] Hi, this is Ronak, from Bank of America. So, question regarding the app migration, which we were talking about. I mean, again, it seems like we are spending more time in doing app migration than the actual implementation, because Pega is coming up with this minor version every year for some of our applications, the NY helped us out for the migration and all, and now we are in the same time that, you know, now we can do migration again. So how can we come out of this migration terminology, and you know, it's like it's incremental change, which we have to adapt, you know, every year, or every other year. I think I'm just trying to understand your perspective, that, you know, what does EY think about it?

- Sure. Yeah.

- So, a couple ways of looking at it. On-prem, the answer for on-prem is very different from answer on the cloud, right? So let's go with on-prem, 'cause you said Bank of America, right? So I think you want to catch up with at least a major version, and then you can get into this cadence where you can get into your periodic patch updates, and, you know, you have a clear upgrade path. But a lot of times, let's say you are one or more major versions behind, that is the legacy that we're talking about, that you take a larger effort to bring up to sort of a par. Right? 'Cause once you are at a major version, then it's easier to do incremental updates.

- Yeah, I would just add, broadly, I think there's also a difference between an upgrade strategy that we need to have ongoing, how do we deal with this, how do we manage upgrades into our regular backlog?

- [Ronak] That's right. We are spending more time in doing the upgrades.

- 100%. And so we would, across multiple, and Pega-specific, but in other areas as well, usually we have some recommendations, that you don't need every upgrade, maybe you skip one, you state why, those kind of things. But that's also very different than, okay, for various reasons, we got so, quote, "out of whack," or we're so overly configured, or whatever the factors are, it's time for a modernization type effort. So, but unfortunately, if we don't have a good upgrade strategy, then we ultimately, we often result in the latter, right, where we get so far behind, now it's a big deal.

- So I should probably count the number of times, I'm gonna say COE here. But that's when your COE should assess with the new minor version upgrade, what are the features that are coming? Do you need to really use them or not? And then make a call on how and when you upgrade.

- Yeah, yeah.

- Any other questions?

- [Louis] Yeah, I have a question. My name is Louis. And I'm a Pega LSA. We are looking at the modernization and simplification strategy for our legacy application. Can you hear me?

- Yeah, we can hear you.

- [Suzanne] Yeah, we hear you.

- [Louis] All right. So, one of the things you explained here in the process, right, application migration strategy, lift and shift, right, refactor, all sort of things. But I did not see any slide where it shows what is the current architecture, and what is the future architecture. How do you align with those things? For example, you migrate from on-prem to cloud, right? On-prem you have a lot of capabilities, right, you are building applications that you can integrate from database to database, or an MQ integration. But I have not seen in your slide where, okay, how would we leverage on the cloud, what are the capabilities like MQ, replace MQ with SQS capability, or API integration. But I have not seen any slide, can you elaborate on that?

- So, there was a slide where we showed those four circles. Right? So the last circle was actually our migration strategy circle, and that is where a lot of those items come out in terms of your target state architecture, target taxonomy for your applications. And that's where you start looking at, are you going to upgrade and then move to the cloud, or are you cloud-ready, where you're looking at more of a containerization play, and how you move your applications to the cloud, and you know, handle your integrations and the rest. So, that's the step where you define what that overall architecture strategy is. Does that answer your question?

- [Louis] Yeah, it does. But there's some scenarios, I can explain you a business problem here. Let's say, imagine, we have all separate applications, right? It has its own servers, database, and everything is separate.

- Right.

- [Louis] When you try to modernize, per the Pega recommendation, modernize, right, you move multiple applications into a single stack where you have to make sure all the rule sets, right, there's no conflict, right?

- Right.

- [Louis] For example, your old layer rule set, you cannot migrate everything into a single stack. So you have to have some refactoring inside, on your prem, on-prem modernization, like a remediation, code remediation that has to be done. But I didn't see any explanation of how we would do it.

- Yeah so, let me speak to that, I don't think we have a slide necessarily covering that.

- [Suzanne] Yeah.

- When you are looking at moving from on-prem to cloud, you want to do an out of place upgrade, and at least have a clean sort of package that can then move to the cloud, right? So it's a two-step that you want to do, and once you identify which applications you wanna move, which workloads you wanna move to the cloud, you wanna set up a separate on-prem instance out of place, on the latest versions, move your applications there, resolve your conflicts, then move a clean package up to the cloud.

- So, that might be good. Maybe you guys, if you wanna come see us.

- Come to the booth, we have our LSAs and PSAs there, and more than happy to have a deeper conversation. That's what you would do with that.

- Any last questions? I think we've got time for maybe one more.

- [Suzanne] Anybody else have any other questions?

- Okay, well, thanks everyone for coming, and like I said, please stop by, and we'll be glad chat with you.

- Thank you, thank you.