PegaWorld 2025: Re-imagining Tomorrow's Networks Today: Vodafone's AI-Powered Blueprint for Telecommunications Transformation

PegaWorld 2025: Re-imagining Tomorrow's Networks Today:

Right. Good morning everyone. Thank you very much for joining us here today. We're here to look at reimagining tomorrow's networks today with Vodafone's AI powered Blueprint. You've heard about blueprints in nearly in every sprint, which was brilliant. Um, I'm here with Ben Cuthbert, but I would like to say that Telco Industries is rapidly changing across the globe, whether it's an expectation of 350 billion revenue from the US, or over 470 million customers in Europe, the industry is moving. The economic situation is constantly fluctuating and telcos are having to adapt. As telcos adapt, they've got to increase greater efficiency, greater effectiveness. Whether that be also through mergers and acquisitions.

You've got Cox recently as well, but also Vodafone with 311 billion investment over the next ten years. I'm really happy to have a keynote speaker and award winner with Vodafone Ben Cuthbert, a guy who's got a meticulous eye for detail and precision. Ben, do you want to give a brief introduction? Sure. Good morning everyone. So, um, yeah, pleasure to be with you all. And, uh, hopefully you caught the the keynote earlier and you've got a bit of a background on what we've been up to and, uh, exploring with Blueprint and, uh, really transforming the way we sort of ideate and, start transforming our probably our legacy, actually. So, um, as you may have heard this morning. So I lead the Center of Excellence.

Our global network, center of excellence for, um, solutions around what we call business orchestration automation technologies in, in Vodafone. And, um, we we have a number of technologies in there, but the primary one that we deploy our processes and leverage our automation is usually across Pega. So it's really exciting to sort of be a part of PegaWorld and see what the latest and greatest is. And when I get back, the teams dreading it, because they'll be wondering, what have I brought back for us to, uh, embed and, and take forward now? But yeah, it's really exciting. And thanks. Brilliant. Thank you. So what we want to do today is dig in a little bit more from the high level view that you saw in the keynote.

So Ben, this is your second year and you were here last year and we were having a chat and you were explaining the keynote. You looked at Blueprint did I just want to let you looking back to where you were now. Did it live up to expectations and for the people that have been here one year, or when they see this on video, is it worth coming to a PegaWorld, you know, value in terms of value in person? Yeah. So I guess my initial perception of Blueprint and probably coming to PegaWorld was it was a bit more of a gimmick. I would have limited value from it. And to be honest, I wasn't really sure what I would be able to actually use that for. But then because of my nature and my team's nature, we started exploring really well. What actually can you do with this and how can you incorporate this?

And we've got a very much a design thinking methodology and approach and thought process around us. And very, very quickly we found that Blueprint was really helping us transform how we ideate with customers. So it helps facilitate a lot of the actual conversations that we're having, because a lot of the design sessions you have, you may walk out, usually with a slide or a picture or you know, something you've drawn or something like that. But actually with Blueprint, you can actually create something that you can then actually do something with straight away, which is totally amazing. And also the great thing about it is you can get feedback straight away from your customers, from the people that are there around the business and start to incorporate changes real time. Um, so it's really game changing from that perspective. Um, but in terms of, um, PegaWorld and are you getting value in these technologies? Uh, genuinely, it's probably the most value that I get through the year. And, um, you know, can't wait to hopefully, maybe come again.

And, um, already seeing some stuff in the presentations this morning, a genetic fabric and so on. Really, really excited to see what we can do with that and how we can leverage everything going forward. Fabulous. So I'd just like to dig into that a little bit more. You know, you've come away from PegaWorld last year. What's the what's the journey that you went on and it journeys are never simple. You don't just go from point A to point B, there are some challenges along the way. And obviously in a business that has done it one way, there is some resistance. How have you overcome that resistance to get to where you are today?

Sure. So I guess the journey started really with us in my immediate teams understanding, well, what is the capability in its entirety and how what's the limits of it and how should we think about it even before we could really position that to our stakeholders, customers and so on. So we spent quite a lot of time really ideating ourselves. Well, we don't just want to take something and just say, oh, go and use Blueprint because you know, that will have a limited amount of shelf life or appeal. And I want this to become something that's enduring, that becomes part of our way of life, our culture and so on. Um, so once we kind of, in the immediate team, started to ideate and come up with these new approaches, we then started to really seek out friendlies across the business people that we know trust have delivered for before, um, but equally are quite used to, um, legacy ways of working. And we spoke to Pega as well and said, um, could we potentially do a catalyst? Um, and to be honest, that was um, an interesting I've done a catalyst before, but without Blueprint. But with Blueprint, it was completely revolutionary.

So we managed to persuade um, our customers to, to do a catalyst with us. And we had a couple of days in your offices actually In in reading in UK, and we took one of the fiber deployment processes for networks and we came out of that while we went into that actually with the customers not particularly wanting to be there. It's probably fair to say, um, and, you know, to a degree just thought, you know, this is going to be kind of a waste of their time. Um, which, you know, I don't blame them. A lot of people come along with sales things. They get a gimmick and it turns to nothing. Um, but when they left, absolute advocates loved it. Couldn't believe that we'd created something that that actually could go forward off the back of the sessions. So we knew we were on to something, but we also knew that kind of two days felt a bit much.

So. And it wouldn't probably work in certain markets where, um, where we work in different countries and so on. So that's when we really expanded out and started to develop our Rudy structure, which is rapid understanding, design and innovation. And it's really a one day focus session where we take all the goodness from your catalyst and the Blueprint, but also we Vodafone ize it enough that people, um, uh, can buy into it and also really participate and leave there knowing that we've kicked off some of the key processes that are in Vodafone. We were going to deliver something together. We started working on business cases together, things like that. So, um, once we developed Rudy, it kind of really started to take off. The problem actually, we more had is scaling because, um, you need people to facilitate these kind of things so you could try and find more people to facilitate those kind of events. But also now it's kind of organically growing where people are sort of taking it upon themselves.

Oh, I'll just go and have a look on Blueprint. How would that solve that problem, that that business problem? Or we're going to have a look at this business challenge over here, and we'll just come up with loads of ideas, which led us then to the Citizen Developer program. We were like, well, you might as well develop some of this yourself because there's so much coming through. So that's when we started adding Blueprint to the app factory, which again has been really game changing. And then we did the no. No sprint without a sprint, which for us, um, even if you've got like a six month project, you know, it's huge. It's going to be hard. You've got lots of requirements and so on.

If you can talk to your customer about what this might be, what it looks like towards the end, or this might be how it feels. Getting feedback on have you actually got the right requirements quickly is way better than waiting until you've delivered something in a few months, or when you've got an MVP or whatever you, you know, um, you may as well get real time feedback and and see what see what they think. Um, and what we find is it's just removing a lot of the rework you probably saw in Simon's video in the keynote, um, you know, 30% less rework, for example. That's that's due to us being able to share early with customers, get the feedback in and then really only go forward with the stuff that's good. Um, so so for us, it's been revolutionary in terms of the challenges. I think we've still got, and we'll always have this element of people won't want to engage. It's a different way of working. Some people like the requirements approach where, you know, you kind of oh, here you go. This is what I want.

Come back when you've got a product. But I think the culture in general is just changing now in in all technologies it's much more collaborative. It's much more hands on. It doesn't need different types of skill sets to do everything you can. You know, you can get customers involved in things that they couldn't get involved with before because of the knowledge differences and things like that. It's much more accessible and inclusive for everyone. And and for us, we want to now focus ourselves around outcomes and value streams, things that are important to the business, that make money. Um, and for our customer experience. We don't want to just focus around a part of a process or a silo in the business, because that's not what's valuable.

The outcomes are what's valuable. And the more we do transformation around the outcomes, and it's really the customers that I work for inside the business, they're the ones that own the outcomes usually. So our approach really helps enable them and what they're trying to do and be successful. And the more they see that the more we've grown. That's brilliant. And it's obviously paraphrasing Simon Norton, everything that you're working with Pega touches to gold, which is which is amazing. And it also sounds as if you're it's not just a technology that Pega is changing and transforming. It's the culture and the ways of ways of doing work, which is also fabulous. Yeah, absolutely.

For us, um, experimentation is now part of our DNA. So testing something out in a safe manner, learning really quickly from it, around what works and what doesn't and then going forward. That's the key part. And having these kind of technologies that allow us to do that, that enable it. That's what really drives that culture. Because if you, you know, we've had that kind of we've had this slogan internally for quite a while around experiment and learn fast and a number of other things that are linked to that. But you haven't been able to do it because if you don't have the right tools and people around you that can help enable that, there's no safe way of actually experimenting and getting to an outcome quickly. So with this kind of stuff and GenAI in general and, um, you know, test and learn approaches and design thinking and so on, it really helps enable that. So and, and you know, from a customer feedback perspective that I work for, they absolutely, you know, can't can't get enough of it in terms of what we can do, but equally getting so much faster outcomes for the business.

It's really great. It's brilliant because traditionally business and networks, it's not always been the the most comfortable relationship. They have different viewpoints. But I know Vodafone is absolutely changing and transforming itself. So Vodafone is going from a centralized, governance governed organization with lots of markets and outposts, and those markets and opcodes are now changing to federated, almost like franchises with different markets. How is Vodafone changing and providing those services for things like voice? And do you see like Pega playing a strong part in that? Yeah, absolutely. So there's a there's probably a mix now to be fair, where we've got still our internal traditional market types and you know, we service them like we like we used to, but equally modernizing and providing a better service as, as we should.

But then there's a completely different expectation from other parts of our business now, which probably used to be markets that have, you know, gone into a different model, like you say, a commercialized model and so on. Um, the expectation of what we need from them and what they need from us is quite different. Um, and how we actually interact or, or transact together is also slightly different. Um, obviously much more commercially focused and so on. So Pega is actually instrumental in facilitating that because we're not having separate tools for the different models. We're having one tool which will facilitate all of the different approaches. And with Pega, um, essentially we can cater for that diversity through the Layer Cake and various other things. Um, and essentially we can provide the same, if not better service to all of our customers. It doesn't matter if you're a commercial model or whether you're in an internal market, or whether you're just an internal team as part of digital networks and OSS systems.

You know, it doesn't matter who you are, you should be receiving the best service possible. And it is genuinely tools like Pega that will be the glue and working across all of that value stream. Fabulous. So you touched on that. I just want to get your thoughts. What's it like being working? Because when you say everyone says Pega, it's almost like a nameless badge when you just bring that and humanize it. What's it like working with the account team, the wider Pega team? How have you found found that for people that may be wanting to hear, like delve a little bit deeper into Pega, what's that relationship been like?

Yeah. I mean, you can't we wouldn't be able to do all the things we do without the great people that Pega that we work with, that's for sure. So, you know, absolutely everybody in the account team is focused on what is it that we're trying to do. You know, it's not about licenses or selling things and things like that. It's more around what are the outcomes you're trying to achieve then what is the vision? What is what are you trying to get to? What is your execs need? How do we facilitate that? How can we smooth that?

What can we do to help you be successful? And that's always the conversation. Um, and if there's an issue, they take ownership, they drive, you know, they follow through with promises, all the great things that you want from a trusted partner. And and so it's not just technology for us. We've got to we've truly got a partner that helps enable everything we need in order to be successful in ourselves as well. So, you know, I come to Pega daily almost for advice, for guidance, for support, just to catch up. What are we doing? You know, and so it's not just something that we speak in a governance or something like that. We got a proper working relationship.

Um, and I wouldn't say that about all all technology providers that we work with. You know, some of them, you know, only see only see at license time, renewal time or something like that. Yeah. That's brilliant. Really great insight. But we we are in a business and I wanted to just dig into some elements of the commercial side. And on that commercial side, what you touched on, which was amazing for me, the transformation of reducing the time frame. But from a return on investment perspective, what could you share? Some more metrics, a bit more detail?

Yeah, sure. I mean, for us, we categorize everything. We build into the type of benefit usually that is supposed to or the outcome is supposed to to actually deliver. And for us, sometimes we'll build stuff at a loss because we know that it's driving something more important, like growth or risk reduction or something like that. Um, sometimes. Well, the majority of the time it's for efficiency reasons and we want to deliver better service, better price point, or we want to be able to scale without having to recruit more people and things like that. So for us, most products have paid for themselves within six months. Wow. Most products.

If they haven't, then it's definitely within 12 months. So we haven't had a delivery yet that hasn't paid for itself within 12 months. So when Simon talks about stuff turns to gold. Typically it has. But that's partly because we're, um, you know, delivering some great outcomes. But it's also there's a relentless focus in internally on reusability. Um, only, only, um, delivering what's necessary, working with our customers to focus on, on what's really important. And, um, also the modern approaches we've talked about when we're building the investment is much lower to get to the same outcome because we're doing stuff faster. We need less people, um, to actually deliver those outcomes.

And also, um, we can just get it out there quicker. So you're getting benefit much, much faster. That's amazing that you. So it's none of these business cases that take one, two, three, five, ten years to transform, you're transforming in six months to 12 months. Worst case scenario. And what's the type of say for every euro? What's the type of return you're roughly getting? Could you aggregate it across? Of course.

Yeah. Well, last year on average for every euro we spent, we returned four. Wow. So you're getting a 400% return? Not over a number of years, but within quarters. Yeah. So it makes a real difference to the company? Yeah, absolutely. That's that's tremendous.

Yeah. And the problem I have now, you see, is I set expectations. So I'm always being challenged. Well could you do six this year Ben. And things like that. Yeah. So that's that's fabulous. And where when you, when you look at well look at the things that are changing. What do you what do you see.

What have you seen recently, today, or in the past because you get a sneak peek of sometimes of the the behind the curtain, the latest innovation. What's what's the thing that's starting to excite you today? And I'll probably talk about the future in a minute. But sure, there's a number of things, to be honest that I'd be I'm excited about. But also there's probably a few things on my wish list as well. So the things I'm definitely excited about, which I've seen today, is the Agentic Process Fabric. I can see a real need for that in our strategy going forward for autonomous networks where we where we know we're going to have high, high levels of agents that we're going to need to coordinate and make sure they're not running amuck across processes. So that sounds like it's going to be key. Um, and I'm keen to go and explore and find out more about that over the next day or so.

Um, but also we want to invest in scale more in our GenAI than we are on the platform. So We have not yet implemented Pega GenAI in our actual use cases, and there's absolutely scale and opportunity there to drive up. I won't say in case anybody's listening at home, maybe maybe get some more efficiencies from our from our processes as well. So and our networks commercialization that we're, that we've got going on right now. So we're reselling a number of our key services to other network providers going forward. Um, there is opportunities to drive GenAI in that process and, um, really give a unique experience to the people that will be buying that they won't need to be a network engineer to understand how to order from us, and we're going to use GenAI to help facilitate some of that. So that's quite an exciting. Far enough, fabulously interesting and a brilliant vision of democratizing the tank almost so that anyone can use it. And that's a real leap forward.

Whereas rather than you have to have it, I need to have an engineer who's a PhD, etc. to do that. One of the things is that when Pega works with companies like innovators like yourself, they always work with partners. We don't work alone because no one person can do it. How does that partnership and tripartite. So for someone thinking about working with partners and Pega, what have you got any advice and counsel to give them and what they could do best practice almost. Yeah, absolutely. I've worked with partners for a very long time across, not just Pega, but other processes as well. Um, it's you need partners to help really show you things that you just would have no exposure to yourself directly.

So bringing industry best practices, um, stuff that's distilled from other customers things that, you know, they've got usually teams of people innovating or looking at the latest and greatest and bringing you great insights. Um, so there's that side of it. Well, how can you take knowledge that you just wouldn't have any other mechanism to get? Um, so there's value there. And then there's the delivery strength. So when I need to scale an operation very quickly, I've got a bunch of trusted partners that I know I can call on. Um, and it is worth investing some time knowing which partners are strong in which delivery types, because it's fair to say not all partners are strong in all delivery types. So you should absolutely look at, well, who's the best at doing, you know, just hardcore engineering. Who's the best at doing design or UX and things like that.

Because it might be you need a mix of partners to do specific things, although they'd probably like to get a monopoly on everything. Um, but the reality is, um, a lot of the partners are very, very good at specific things. And, um, yeah, I spend quite a bit of time working with them and finding out, well, what what is it that you've invested in and how have you done that? And how many people have you actually got that know that, you know, is it three people or is it 3000 people? Because if I know I need to scale 50 new developers next month with this particular skill set or we're doing this particular outcome, I know I can call. So it's fundamental. If you're going to scale, I would say, and also for your best practices and your center of excellence is, um, you need partners to help create the structures usually. And then you and the best practices and how you should develop that out. But then I would say you can go off on your own once you've got a level of specialism within your own team.

So if you're kind of new to it and you've, you know, new to Pega or new to another technology, when you're creating a center of excellence, you need you need someone to help you incubate that a bit before you can then go off on your. Broom and just to. So we've looked at partners there and that's a really good answer. I'm just looking back. So you've got a wealth of industry experience, not just in comms, but interestingly for any members of the audience here, just from a banking industry. You used to work for Nationwide. I did. Yes. So when someone says like, Pega shouldn't be in there or that's not what pega's job.

Do you see anything from different industries, different perspective where this Center-out architecture and you've got to feel of this doesn't really fit within a telco or another organization deliver anything from orders to managing great big components in the network, not in one country but multiple countries. Yeah. Yeah. I mean, the the Center-out architecture, it works everywhere. There's no reality is it would work everywhere. I think it depends on how your business is really properly structured and your processes are actually structured. Um, it doesn't work very well when you've completely segregated your sales channel, for example, from the next step in the process. And then, you know, fulfillment is completely isolated. You know, you end up with just loads of point solutions.

Don't talk to each other, and you've got to just hope and pray that the business, you know, the people operate in, the processes will manage to get it through to the end somehow. Um, but the reality is, every process in your end to end journeys really should be an orchestrated by something like a Pega. And then you should be aiming to connect everything into it. So whether that's from, you know, your channels in whether it's customers, whether it's sales, Platform, internet agents, whatever it may be, and then your back end fulfillments around, it might be data stores, it might be actual API's to getting systems updated, whatever it may be that Center-out architecture works every time. There's. I've not come across anything in either financial services or in networks that would change my mind from that. I've come. I came into networks almost with the mindset. That's how it should be.

I didn't know anything about telco when I joined. It's just another process. Looks exactly the same the way it starts, where it ends. Not a great deal of difference. That's probably why kind of the team is successful, because we sort of bring it back to back to basics. The kind of central diamond that you saw this morning is kind of the basics. It's the foundational layer for everything. If you don't have that, you don't have a great place to build out from. You can add more channels, more sophistication, more intelligence over time, more data stores, more Google data lakes, whatever.

But you've got to get that central part right. Otherwise, if you create a data lake first with nothing connected to it, it's kind of just a bunch of chaos that you can't do a lot with this problem. It's a really, really good answer and lots of color. Um, so just to just to give a bit of a summary there. So apart from Simon saying everything that Pega touches turns to gold, which is the Midas touch almost. I think that's that's quite cool. And the fact that you've reduced down to 48 hours that that pretty much well, Kerim lost the water. So I think that was quite also quite impressive. But it seems to have changed the way you've done your culture, the way you've engaged with the business stakeholders, the way you have conversations with your business.

But not only that, but the proof points around €1 to €4, which is amazing. But that's not an elongated business case that takes years. It's one that takes months. So it's taking almost like a couple of days to deliver, a month to get significant value back in that type of investment. And the fact that you you can work with partners, and it really doesn't matter whether it's one industry, one network or delivering other types of it just works. It does. What it says on the tin is is absolutely fantastic. And I can see I can see your passion. And when we speak, it's always coming out.

Why you think this is an incredible application and has got incredible opportunities. And I love the fact that you already know that. Not to create those point solutions, regardless of whether it's a genetic AI or tech is you know, it seems, though, that you're right in the heart. And that coupled with Vodafone's vision of working with the different markets and and the capacity to scale that commercialization is, is fabulous. So I, I really like to put a hand up before we go to questions. A round of applause for Ben. And thank you very much. Thank you. So as we look out, would anyone like to come to the mic?

Ask Ben. This is now your time to, you know, get some of those questions out there if you're keen. Yeah. Please. Please do. Could you tell us your name just to add a bit more? Affordable. 2022. Fabulous.

Thank you. Um, a couple of questions. One is, can you give some examples of some really successful applications that became wildly successful and what happened to the business? And secondly, you mentioned customers. Could you tell me who your customers are asking for further How easy or difficult was it to sway the board to fund pain and resistance? Yeah, sure. So. Yeah. I mean, I'll start with, uh, sorry, I can't remember the first question now.

We'll start with the third one, which was the. Yeah, yeah. So persuading the board around the funding is been, to be honest, very, very simple in that, um, I'm very clear that there needs to be a commercial element to this and it needs to be viable. Right. So whatever we do, you've got to always think in a way that, um, is what's the business going to get out of this investment? So we, we know that we need to orchestrate our processes. We know that we need to automate them and so on. But we we also need it to be compelling, cost efficient, and actually drive the right outcomes. So when we have a look at things like Pega, there is a commercial element to it.

So we've got to make sure there's going to be a long term return on investment. We also need to make sure our solutions are fit for scale. So in Vodafone we've got a lot of markets and we've got a lot of complexity and different markets, although they may have the same process, may have a very drastically set of different set of complexity that we've got to handle. So Pega became very cost viable in that scenario because we only have to kind of build once, and actually it can handle many. So we can scale and be more efficient. So when we put our business cases together around why we should choose Pega and why we should scale that across Vodafone networks, that was at the heart of it. We wanted the ability to drive similar experience, the um, to be able to scale and govern our processes well, um, and also cater for diversity in our processes no matter what market you're in. And, um, you know which silo in the business, it doesn't really matter. You can get that personalized experience and it can be relevant to you and the work you do and make sure the process is fulfilled correctly.

So, um, that was kind of at the heart of our business case. And um, from there, the other part of it is you've got to identify, well, what's what's the likely return based on the use cases, essentially. Um, I think I think you mentioned around well, what's an example of a specific process or outcome that we've delivered that's been really successful? Um, one of one of the key ones for us, uh, in networks specifically, is actually our demand management process. The reason why I focus on that is in networks is hugely complex as a, as a process, our demand, um, there is demand coming from usually up to 16 different markets. Um, and those demands can usually also include up to 100 different types of, um, category of things that you may need to order from networks or ask to be delivered. And as part of that demand process as well, not only have you got things like approvals to go through and all the usual stuff, but we need to check. Well, was this a budget, a budgeted thing and budgeted for networks means hundreds and hundreds of line items of actually physical infrastructures or services to be provided, things like that. So you can imagine this order order management effectively.

Um, but for internal demand is hugely, hugely complex. And Pega is handling all of that across all of our markets and still is able to simplify it enough that anyone can use it. Whereas before we had Pega implemented there. It was hugely complex. We couldn't have all the markets using a single system. They had to have their individual ones. Management couldn't control it because although we, although you could have a local market manager, but we wouldn't be able to have central managers that could manage demand across all of the different markets. Um, so when we implemented Pega, a lot of that just got much better, much easier. And we and essentially it's probably the largest use case because we have so much demand flowing through networks.

And we're just as we mentioned earlier, we're just flowing into commercial order management now, um, which we're going to uplift that process to cater for commercial order management, enhance it all with GenAI as well. So effectively it's going to become even even better. And hopefully at some point we can make it more agentic as well. So you can get your demand fulfilled very quickly. On that point. Is that the use case last year that you said that saved 3% of network spend. Was it? Uh. I'm not sure.

Well, we have to check out the presentation last year for PegaWorld, but I believe it's 3% of network last year. Yeah. Sorry. Yes. Yes. Yes. It was. Yeah. So I think that's the use case.

So in terms of commercial bottom line and you've you've just heard about the size and complexity and the number of markets. So you can do the math. Sure. And your other question was around customers wasn't it. Who's my customers. So I look at the customers in layers. So I like have my immediate customer, which is usually someone in the business that I'm serving. So, um, somebody that owns a particular process or business unit, um, process owners, executives, so on. Then they will also be serving someone right with their process or whatever they're fulfilling, whatever they're delivering, whatever their purpose or their process is.

So I also think about those customers, because if I can't make those customers happy and successful and, you know, then essentially my customer is not going to be happy. So I have to think about customers in layers to, to a degree. Um, but essentially the only one that really matters, obviously, is the customer, the consumer, the people that we're serving. And almost everything that we do, we have the consumer lens on it. We, you know, how is this going to feel? How can we make it faster for them? How do they want a fast service? Or do they want one that's more personable? Do they you know, all those kind of questions come into our design thinking effectively.

Um, but essentially if you make those customers happy, usually you can make the the internal customer happy as well, unless it costs too much to serve them and things like that. But brilliant. Any anyone got any more questions? Yeah. Please do. Please come on. in thick and fast. So, hi, I'm Usha from JP Morgan Chase. So a good session on the keynote in the session was interesting as well.

So I have a couple of questions. So while we are in the process of, you know, adopting, looking at our pilot, you know, use cases for Blueprint, again, being you mentioned Nationwide. So, you know, Chase, being in the nature of industry that we are in a lot on regulatory data security, you know, data use, council security, you know, the that world. Right. So, um, so while we provide the inputs, the prompt etc. power Blueprint. In today's session, we also saw that part of the data model, like we need to describe the data model that we are thinking through and all of that. So how do like in your experiences using Blueprint, how do you prevent, um, you know, some of the sensitive data, you know, while describing the Blueprint inadvertently, you know, operations folks or people should not, you know, share some of that data because especially Blueprint is, you know, outside the. The I know exactly what you mean.

I'm going through this at the moment. So. Um, so what measures are you taking to ensure? Yeah. So in the in the very immediate term, we don't put anything sensitive into Blueprint. So although it's a, you know, it's password and, and email, um, we're going through with security at the moment, the capability to say, well, what's the limit of what you're happy with us putting in here? Um, and at Vodafone, we categorize, you know, if it's C2 is kind of anyone can see it. If it's C3, then it's more restricted. If it's C4.

Forget it. You never you can't use it basically. Um, so we're at the moment we kind of only put stuff that's generic or is non non-sensitive, so we don't ever put customer data in anything we're doing anyway. So on. On development time or design time, you shouldn't ever need to put real customer information or anything like that, right? Um, usually process information is not that sensitive, right? It's just kind of a load of boxes and some arrows and things like that, unless it's got very specific IP related to it or something like that. Um, usually policies and rules, things like that. Not that sensitive to a degree.

Um, but you should look through your categorization and then go through it with security as a, as a capability that you'll want to use and then get an official answer for them. Um, it will depend on industry. I think. You know, I know coming from an NFS, there's lots of rules around everything that you everything that you do. And it's often a barrier to sort of innovation and change and all that kind of stuff. But equally, it may be actually a force for good in that this is helping you in a really structured way. Identify how to handle some of these policies and rules, which maybe years ago it was like, well, this is too hard to try and change these processes because there's so much, you know, things that you have to make compliant and and so on. So I think actually these tools could be really beneficial for security and privacy teams and so on to make use of, to actually create new processes that are modern but equally compliant and things like that. But you should never for sure never put anything in there that you're not 100% certain.

Well, yeah, this is fine to, to use for and but we equally do want to check. Well what's the limit of what you can put in there. Um, and for us at the moment we just put only things that are, you know, C2 as we call them, which is more available to share with most people or. Anyone available information. More, more so on that. Yeah. So that kind of answers the next part of my question, which is like again, so we have the central team, which, you know, takes care of the platforms. Could you speak up a little bit? Sorry, I can't hear because of the clapping.

Sure. Yeah. So that kind of answers the the second part of what I wanted to ask, like more on the governance model and the structure. So what we do is the central platform team, which is predominantly part of my group, um, kind of looks at what is the use case, uh, you know, goes through a review process, etc. before we, uh, you know, open it up for Blueprint and those kind of so, you know, having a bit of a tech governance, security, governance around that helps, uh, and releasing it in a phased manner before citizen developers can actually use these, I think is, is kind of something which has helped us. So that is one part of the question. If it's if it's okay, I can. Sorry. What was the question.

Was it around the governance. Yeah. Around the tech governance, security, governance and all of that. It is better probably that there is a more of, you know, pro developers and security risk and control folks who look at the initial use cases, right. Review them in terms of like you mentioned, you know, there cannot be any kind of, you know, sensitive process or data or classified information, you know, being used when the Blueprint is getting described. So that I think is a good practice that, you know, we follow. Maybe that can help. And the other part of the question is like, so once we have described on the prompt, you know, the Blueprint has generated the whole skeleton and all of that. Um, now when so assuming after that, a full fledged, you know, production ready workflow is is through and it's running.

Now when changes have to be incorporated, how has been your experience? Yeah, sure. So almost never have I ever put a Blueprint straight to life. Um, I don't think I've ever done that, actually. I'd like to, but. But that's never happened. So really, the Blueprint is an accelerator and and and something you can discuss around. So it should be a distillation of your ideas and whatever the LLM has helped you cook up based on what you've kind of well, going forward, based on what you already have with the legacy information or documents that hopefully you can add in now you should be describing what's your ambition? What what are you trying to achieve?

So the suggestion that it gives you is around that. But it's a suggestion and it's something for you to iterate with. So I never, um, just take that and go, well, let's go and put that live. It should always be essentially right. How does this look? Get some feedback around from the people that we work with, the customers and so on. But then we have quite an extensive amount of reusable assets ourselves, Itself, which we want to make use of as part of this. So those of you who. Know what the Layer Cake is and so on.

Um, you know, we've already got data attributes for certain things coming from certain systems. We don't want to recreate those or duplicate them. Um, we want to incorporate them. So if Blueprint has suggested that we have certain data types, probably still need them, but the source that it's suggested might not be the source. So we then spend some time when we import it to our platform, then effectively uplifting it with everything that we already have that's reusable, and then we start to iterate a bit on from there. So it's not that there's no development or no developers in our process, it's just it's a lot faster because we've iterated as much as we can in Blueprint then we've brought it over to the dev side, um, in our platform, and then we've iterated a bit more, incorporated all our existing stuff, and then from there we make a choice on what is this ready MVP? Or is this not ready? And there's more work to do. More sophistication and so on.

So the Blueprint very quickly allows you to do the rapid prototyping. And you do not need to put the security, any security concerns in there. When you go to Agile Studio or into the application at that time, you can still move things around. It's not fixed. And so there you can import and put the right data sets in there, the right data models in there, the right data sources, the right interfaces. And you can work that before you go live. But it condenses that time. And that's why on some of the more simpler stuff, you can go live in 48 hours because it's all the assets are reusable. Okay.

I think unfortunately we're out of time. But I'll go on. One more question. Go on quickly. Thanks for that. Arts Capital Arts Insurance. Um, you talked about the different ways of categorizing data, what you want to put in Blueprint, what you don't want to put in Blueprint, so on and so forth. The question that I have for you is what has been your ask to Pega on what type of features that you want to see in Blueprint? I have a ton, but I wanted to get your perspective because you have been using.

This for a really long list. Yeah, I was talking to Chris about this earlier when we was in the keynote actually. So I'd like to see really some sort of, um, Blueprint pro version where you can have it really coming from your platform because then it can understand well what's in your platform already. Right. And then take design time in consideration of what you already have. Because I really want to re-engineer a bunch of existing stuff, but also take account of all my existing stuff in my design. So I don't just want to take a blueprint every time and then go, right, I know I'm going to have to re-engineer those bits, blah blah blah. Um, so there's that element to it. Um, but also I'd like to continue to evolve into a more of an agentic conversational capability.

So it kind of once you've done your initial description, uploaded your documents, it will kind of stop and give you a picture. Why does it need to stop there? Why can't you continue to conversate? Why can't you continue to describe what works? What doesn't? Things like that. Whereas today you kind of got to go into configuration or if you go backwards, you may lose what you've got already because the LLM might produce something completely different again. Um, so it's um, yeah. So that's kind of where my head's at with it at the moment.

But there's, there's a long list of different things, and we're doing quite a lot of work with the, um, product team in Pega around Blueprint. And, you know, how could that evolve? What would be exciting to us? Things like that. So, um, fingers crossed we may get some of our wish lists at some point as well. Brilliant. Thank you very much. Thank you.