PegaWorld iNspire 2023: Panel - Building a Mature Pega Center of Excellence

Hear from Lloyd's Banking Group, Siemens, and Deutsche Telekom about their Pega Center of Excellence – each at varying stages of establishment. The clients will share their successes as well as the challenges they have faced and how they are overcoming them. Join this session to learn how to:

• Increase application velocity through effective establishment and governance of reuse
• Sell the value of the Pega Platform™ vs. out-of-the-box solutions from Pega competitors
• Focus competencies on process optimization and building business value

Learn from our members of the panel, who have been actively participating in building and running centers of excellence at their companies:

• Samer Nazer, Lab Engineering Lead, Lloyd's Banking Group
• Juergen Schoenenborn, Team Lead, Low Code Platforms and Architecture, Siemens
• Daniel Wenzel, SVP Design Authorities, Deutsche Telekom

Transcript:

- Thank you for taking the time to come and hear a little bit more about Building a Mature COE with Pega and the Center of Excellence. So my name is Brenda Looby I'm a Regional Director with Pega Consulting. And I'm joined here by three great clients and I will ask them to introduce themselves as they give a little bit of a history or a little bit of background on where they are each at with their COE journey. So Juergen.

- Yeah, hello everyone. My name is Juergen Schoenenborn. And I'm working for Siemens. We are using Pega since eight years now. We are Pega cloud customer from day one and over eight years. What started very small has grown quite a lot. So on our central environment we are running more than 20 applications. At the moment we are processing roughly a million cases a month. And yeah, we as a TT team we are providing the platform for our partners in Siemens to build the applications and support them with any questions about architecture compliance. And yeah, my role is to manage the platform team and but also to support as a program and integration manager project teams for all those questions they might have, demand, the evaluation, still integrating with the bigger IT ecosystem in Siemens.

- Okay, excellent. Samer.

- Okay, my name is Samer Nazer and I am an Engineering Lead working for Lloyd's banking group. We have started our journey with Pega in 2008, 2009, and we have been building applications, just to give you a scope of the amount of work we've got, we've got about 46 applications in Pega that currently running in production environments. We have around the history about Lloyd's Banking Group. We are the largest retail bank in the UK. We are just a UK bank, around 26 million customers we have, and on average we process around 45 million cases a year using the Pega technology. We have matured with a number of different versions of the Pega applications. We started with Pega 5, 6, 7, and now we are on Pega 8 on the cloud using the latest available releases. So my role is primarily looking after retail banking, but I work for a platform called Core Platforms. And in Core Platforms we've got four labs, retail, insurance, commercial and enterprise that uses Pega technology. But my role is primarily building customer service application and defraud, which is fraud and disputes using smart dispute application. We have a long growing history with Pega and we are trying to kind of mature alongside the Pega journey.

- Cool. Yeah, thanks for having me here Brenda. My name is Daniel Wenzel. I'm working for Deutsche Telekom and taking care of function called Design Authorities, which is literally the business and IT architecture governance. We are a Pega customer since 2018. And we are lifting currently 800 HR processes for our internal employees to pick a customer service. But beyond that, growing in areas like compliance ESG and we are preparing a corporate platform on which we wanna scale to customer service. Like our colleagues from T-Mobile US are already doing, so quite an ambitious roadmap ahead and looking forward to share some of our thoughts about how to establish a COE function while at the moment we don't have a COE.

- So Walter, would you introduce yourself too?

- Yeah, first of all, I wanna say a big thank you to the three of you Juergen, Samer, and Daniel to do this today with us and a big thank you to you of course our audience. My name is Walter Kohler. I am responsible in Pega for our consulting function globally. And we have heavily invested in the last couple of quarters and years to kind of provide better services to the clients who typically have this challenge at the crossroads of business and IT to build a real true mature COE. That is both looking at what do we take into Pega, how do we do it in Pega, and then how do we run it in Pega in the most optimal and efficient way. And our program architects and technical architects are of course a key offering in that regard. So thanks for coming today. Back to you Brenda.

- Okay, so Samer can you talk to us a little bit about you know, like you said you've been using Pega a long time. Can you talk to us about some of the steps that you took in the journey to build your COE to where it is today?

- Yeah sure, so working in software technologies especially something like Pega, there is a lot of work that you do, and then you kind of revise it. So a lot of retrospective trying to understand how can we optimize the way that we delivering things. So some of the stuff that we have in Lloyd's is things like a mature Pega Guild. Now Pega Guild is effectively responsible for anything to do with Pega technology. So the participants is anybody who actually code in Pega and we have a large audience that attend that Pega Guild on weekly basis. Now what we do in the guild is effectively review design decisions. Now with any COE you have to kind of try to address two things. The first one is actually saying, okay, I need to review and make sure that we are complying with the standards. And by standards there is two things. The first one is the Pega standards, i.e. the Pega guardrails. And the second one is the standards that you have in an organization. So in LBG we are a financial institution, so our primary objective is to make sure that we have robust systems that deal with customers accounts. So some of that requires us to be a bit more restricted with what can go into production and how we kind of deliver these applications. So the guild meet on weekly basis, we review designs, and the other thing that you need to bear in mind that your COE should not be an interrupting force to your delivery because obviously we are delivering code and as you deliver the code, you need to make sure that you kind of put the right governance in place to allow teams to deliver applications smoothly. So for example, you should not be restricting your COE to review every single design because you would not have enough time. But what we are reviewing at the gilding LBG is effectively things that could potentially impact other areas, i.e. reusable shared components, kind of things that could impact others. That's where you review things at the guild. But if you are doing something for example, you wanna change your UI, you wanna do data table stuff like that, we would not review it at the guild. So that's one of the first thing. The second responsibility of the guild is effectively saying, okay, so now we have, just to give you an idea, I look after retail banking and in retail banking I've got nine teams. So things that comes out of the, I've got a lot of work going on, and you cannot kind of review every single design. So you have to have trusted people that could actually review things as saying hang on, this could impact other people. We need to push it to the guild. You push it to the guild, you make a decision and these decisions kind of saying, okay, what is the best optimal option for picking up and delivering a certain component. Once you build that, you take it, and you kind of commercialize it. And you put it across every single instance that we've got. And we have gained a lot of kind of quick wins and paybacks by reusing components that is already built and approved by the guild. The second one is providing additional support for other labs that we've got. So somebody comes saying, I've got a problem in my area and I need additional support. So the guild will spin a mini group that deal with specific issues. So that's the kind of things that we we're doing at the guild. But also we are linked to center architecture. So if we have another group called the Design Working Group that deals with anything that Pega needs but is outside Pega technology, i.e. you need connection to a certain area within the bank for example, that goes to a different group but the actual Pega design is done and approved by the guild.

- Excellent, so Juergen, can you talk to us a little bit about how you prioritize and decide which projects are coming in with your COE?

- Yeah, sorry.

- Yeah, as A COE, and I think this is what you also somehow mentioned is you always need to take care that you are not the bottle right? To support, you need to have a certain level of governance but you should not slow down the application teams which are implementing the application. What we tried to do from day one is there was a clear call use the cloud so you don't have to deal with the OS and database stuff and all those things use the cloud and a very clear outsourcing and off sourcing strategy. So we build up a partner network and if you have trusted partners then you're able to scale. So whenever you get new demands, you reach out to your partners and hopefully you have enough capacity. That's the best case for sure. There can be situations where capacity is not available and then yeah, in Siemens is a little bit tricky because we are not following a global program. We have a lot of decentralized decision cycles and we as IT, you should then probably not take those kind of decisions. So sometimes it's simply first come first serve.

- And Daniel, you had mentioned that you're moving toward a COE, what's the vision that you have and some of the things on your roadmap as you're getting started?

- Yeah, thanks for the question if you don't mind Brenda, I would like to briefly comment on the two things before, because my perception is that we do things a bit different than than you guys because actually we are looking at every user story that is handed over. So one of the teams is checking and before we get this governance function going, we have a pool of architects, business and IT wise, two separate groups that are reviewing designs and giving design patterns we would like to enforce to use. When we do the screening of everything that is going on. Because literally we have roundabout 170 people working on that, like in total nine teams, six of which are in one project, not the magnitude that you have, I agree. But the important point is that like 70% of the stories are just flowing through, they're okay. But on 30 we take a deep dive. For example if it's a totally new component, if it's impacting others, if it's overriding a standard rule. So those kind of stuff we definitely wanna share in a round which is once a week, round about two hours. Review that everyone has a chance to comment on. And that is really something that we use as a gatekeeper and prevent that from going to production if that hasn't been reviewed, that enables us to have a high quota of reusable functions and to have a scalable pattern because also I perceive that as a little difference. We are trying to have a harmonized layer for every project that we got and to grow that beyond. Coming back to your question, what do I envision regarding a COE? We started first of all with communities of practice because the name COE always creates a power struggle. Who does it report to? Is it an IT function? Is it a business function? Is it within a service unit? Is it directly reporting to some overhead function? In order to avoid that, we set communities of practice where motivated people and competent people come together in certain boards and everyone can participate in this board. So it's literally fluid and not reporting to anyone and we are more dedicated to the result. Looking forward, we perceive that we need to have a dedicated organization in order to invest on basic things. I was really scared hearing today a lot of the AI stuff. Because that requires a lot of foundation work, a lot of work that is going to last month or years without seeing a payback because that's the liftoff point for everything else. And that's our next plan to grow a platform team, which is really working on those core functions. Having the vision for Pega, looking for the use cases and pushing that forward. Anyhow, I tends to keep it small and to have this decentralized function in order to have checks and balances in place.

- Great, and Walter, I know you see a lot of clients, are you seeing other similar things or what are you seeing with people that you're talking to as well?

- Yeah, I mean all these points are really valid that we just heard. But what we in typical in a general COE situation see with quite a few clients is that depending on where they have started and whether they have come from a traditional IT operations side or whether they are more business driven, these crossroads that we've also spoke about in the keynotes and we've heard about in the keynotes this morning where the real value generation happens is where kind of how do you implement that proper center out strategy? And how do you make real use of the layer cake so that you build for reuse and you build components that you can restructure and reuse across the enterprise. That is really where the COE then drives the value for the organization because that is really where you speed up the next project, where you make sure you can easily navigate to the next release of Pega. And where you reduce the time that you use in kind of building new stuff because you have already all these components available, whether it is to your systems of record, the integration there, whether it is to any kind of outbound channels like Facebook or others where you want to kind of promote your ideas and your technologies and your solutions. Build it once, reuse it. That is where we typically see if a COE does that really well besides all these other aspects of kind of the technology et cetera. Then we see the real acceleration in adoption and we see the value generation being much more fruitful for the organizations.

- And I know that as we were preparing for this, Samer you had mentioned and hopefully you'll be able to talk a little bit more about it, you had mentioned that you've got maybe 120 components that you're reusing.

- Yes, so we moved from Pega 7 and we are right in the middle of a transformation journey where we are rewriting all our application in Pega 8 on the cloud So we are trying to use the latest and greatest and as part of that, one of the key things that we are doing is building the foundation. The foundation is extremely important, because once you build that foundation, i.e. build your components, you could actually do things a lot faster, a lot quicker. So just to give you an idea, we started with customer service took us about seven, eight months to build the foundation. But once we build the foundations of the customer service i.e. 360 degree view of the customer, products, accounts, vulnerabilities, all that kind of things using customer service, we were able to say, okay, we know the customer now, what is it can we do to service that customer? And once we build that framework or that foundation, we were able to deliver things like one project that came in or a case type that came in, which historically would take us about 18 months to two years to deliver. That was completed within the first three months. It's not in production yet, it's been developed, but it took us three months to get to the product that the business said yeah, I am happy with this, let's scheduler it to go into production. So components is extremely important part of the next gen Pega delivery because that will allow you to move quicker and build things faster because you have the data.

- I would fully agree, I mean for us we really learned that the hard way and I guess it's one of the things where new Pega customer struggles the most with, we really scrapped one year of development in Pega and reset up our complete platform to exactly follow that modular approach. Probably in a very tough and extreme way maybe, but that allows now the scalability. And I just would enforce your point, you need to do that right from day one because it gets slow and expensive later on and it's worth the investment.

- A 100%

- Maybe adding a very, very concrete example and something where we actually failed at the beginning when we tried to understand the layer cake model, it was quite obvious for us that we have Pega as the foundation and on top we build our enterprise layer and if you see those nice pictures, it's one bar, right? That's exactly what we did. We implemented one bar and this bar got bigger and bigger and bigger over time. So all the applications catched a lot of overhead, which they actually do, didn't really use and neat. So later on we then started to cut it into pieces, componentize it, because then you're way more flexible. It's helps in maintainability and then yeah it can even better grow. Because it's single components and wherever you want or wherever you need them, you involve them and you don't take care for the rest.

- Right, and that's the whole premise of the layer cake is being able to make sure that, you know, departmental boundaries or countries or you know, all of that it sounds like you're really using that better now.

- Yeah, if you failed once, yeah, I mean at least you learn something and then you just need to do it better for sure It needed a lot of rework to cut it into pieces, to componentize it. But I think we have reached a good level now.

- So another question, I mean we focus a lot about the technical part of the COE, are there other key skills and components that you would recommend as part of your COE?

- Yeah, so our COE is very much IT driven. Yeah. And when you are that IT driven, then you tend to focus on IT, on technical stuff, right? And what we have now seen is in those eight years, I think we got a good understanding of basics like the layer cake. But especially in the last two, three years, Pega came up with a lot of new features and we figured out that our business stakeholders didn't understand those new things. So we asked one stakeholder, do you know what's the difference between process mining and process AI? And he said no, which was a very easy or obvious example. So helping our business stakeholders to understand the full capabilities and the full power of Pega and especially the new features of Pega is something we need to improve. So being closer to the business translate technical things into business language and to, yeah, even and fire them. 'Cause they need to come up with the use cases, that's nothing we can do in IT, right? So we need to help them and that's a lot about communication, about enablement or I would even, I call it being a catalyst. So as close as possible to the business and help them to really get all out of Pega they king get.

- Other comments on that from?

- I mean we have the same experience and I think it's one thing to describe the things but it helps when you have a prototype to show it, like to give an inspiration and so on. But that is something a COE can be very useful because when you are in operator rush, I mean it's amazing how much you deliver. Yeah, but I guess that this is very streamlined going forward. Push, push, push, push. Same for us. So who shall build those prototypes? Who shall think of innovation, having a dedicated function, taking care of this as part of their mission frees up capacity to do so. And that is something which definitely from my perspective, definitely pays back in business as soon as use cases are understood or inspired and getting forwarded.

- And I think one of the things that we are actually doing at the moment is that although you have the COE, the COE, the Center of Excellence that we are using as a governance body to control what reusable component you should be using. Because a lot of the suggestion that comes into the COE basically saying we are building this component, we think that it can be used across the enterprise. So just to give you an idea, we have eight different VPCs, and each VPC does a certain business functionality because of the way that we are kind of structured. So what we do, we build something once and we roll it across all the eight VPCs. So the COE is connected directly with the release management pipeline. So that is things that we do. So if you did not get approval from the COE, you will not be able to go to production. So that's one of the main things that we are controlling. What code goes to production, what is the customer impact and how we can control that. Now as for innovations, obviously we are working in a tech world here and there is a lot of things happening. I mean a lot of stuff I've seen today is just blowing my mind away. How we gonna fit this in a financial organizations, how we gonna ensure the integrity of our customer accounts? How we gonna manage that kind of component? So there is a lot of questions to be answered. Some of the stuff that in my view that the COE can do is effectively provide the correct governance at the right point of time. It's non interruptive governance where you apply the right kind of conditions for the right user story. But things like stakeholder management engagement and things like that is something that you build it by building that trust between you and your stakeholders. Once you build that trust and you created that pipeline, you could start saying, okay, we know that you're doing this thing if you try it this way, what is the impact? And you can have a conversation about that.

- I mean to that point, I'm almost seeing you like running a Pega consulting function like I do in your organizations. And we know we have always been really, really super strong in our technical advisory that we give to our clients. We are the best people who can build whatever application you imagine, but adding that advisory part to it, where you really kind of give your business the ideas and then help them understand how to leverage Pega in the best possible way. I think that is where I am currently working with my organization to build all these new offers, bringing them to you with that advisory reports. But that's also where I see really, really strong COEs moving into so that they not just do have the build and the assurance, but they also have that kind of visionary and guidance to the business on how to leverage Pega to the best return so that you get the best return for your investment.

- So we've talked a little bit and we were wanna make sure that there's time for questions as well 'cause I'm sure there are questions, people in the audience. But a couple things, as you've mentioned a failure in the beginning with, you know, using the enterprise layer and the foundation. Are there any other things that you can comment about during your journey where you failed or where you might suggest that someone else watch out for?

- One thing, probably, which fits very well to what Samer just said at the beginning, we were pretty much quality driven and our first approach was actually also to not only have this necessary level of governance but complete transparency. So we also tried to review each and everything, but this simply was not possible. Not in our setup with the given capacity. So we had to find ways to let loose of certain things. Yeah, so it's a little bit loss of control, it doesn't feel comfortable at the beginning. But this was our way to make sure that we are not blocking. So trusted relationships. You said it right? So it's not only our development partners, our external partners, it's also our business functions we are partnering with. So the more mature they get, the less governance and control is needed. So if you have once established certain standards, if they're understood and accepted, then everybody knows why they are there. Everybody takes care of them and you don't need to do it as COE.

- Goes to some of the enablement you spoke about. So Samer or Daniel?

- In order to add to up to this, I think, well we established a certain KPI framework. A lean one, but general corporate mechanics work. What gets measured gets done. So we track the guardrail scores or the Pega compliance to the code, but also we implemented a standard KPI how we call it. And this standard KPI tracks how many rules are overwritten and used in a different context. And this has an ambition level of above 80%. So that we stick at least 80% to standard code, which allows us to enable upgrades easier and have a certain standardization in the system. And that becomes important as this report is reviewed by our CEO for all the systems that we have in it. So SAP and others as well. Once a month. Yeah. And by that we have a certain level of attention when those figures drop and we track that for every application that we have in our Pega environment.

- And I think one of the other things that we have also done quite successfully, one of the, on the Pega marketplace, there is a number of tool in there which helps the COE kind of implement kind of guardrails and standards. So you could actually, there's a number of tools that you would actually define your guardrails. There's two things that you do. First is Pega guardrails, the second one is your organizational guardrails. And you could plug these in into your Pega application. And if your developers are not complying with these guardrails, obviously you have to think about the speed of delivery. Is it acceptable? Is it moving away from being standard out of the box? That's what we're trying to do. Can we build something out of the box where we don't have too many specialization or customization that deviates away from the main Pega box. Because if you do that, what that would mean that actually on every upgrade you have to carry with you that technical debt. And we have an Evergreens strategy. So all our applications that we are building at the moment is compliant with the Evergreens strategy, which is about 97% on certain application and 98 on others. So anything below 95 does not get through to production environments and the developers will have to fix it. So also providing technical controls is extremely important. Standard governance will work 'cause it provide the guidance, the support and the option selections, but actually applying some technical charges will help you ensuring that your code is up to date to the standard that is expected as an organization.

- One thing I would like to add is that I'm quite often confronted with the point that governance makes development slow and I get the point, yeah? it's an additional board you not need to go to, you need to be prepared. My experience is a slight different one. Going through an agile journey, we run a can should must approach from a COE perspective to those approvals. And we say as soon if you have your user stories and you know what you do, you can get the approval. When you start development, you should get the approval. And when you wanna go to production, you must have the approval. And in my perception, just because this gatekeeper is there, the quality of stories improves, the things get more to the expectation of our clients. Whereas when we didn't have these steps in place, we often tested our systems healthy. So we had a lot more testing effort, a lot more correction effort, a lot more change requests. And that is something I get the bottom line, yes it's an additional work step, but on the long run it's rather speeding up than slowing down.

- So one final question before we open it up to the audience. What is something that either Pega or our partners could do to help you be even better?

- I very much like what Walter said, and I think it fully fits to the challenge I mentioned. With all those new capabilities of Pega, I have often seen those one or two pagers, very high level, which give a little bit of a glance and then I have seen the big slide decks, 50 pages, 100 pages, something like this, right? So the one or two pages are often not enough to inspire people and to really create an understanding of what is possible and nobody wants to go through 50 or . Yeah, so the level in between, I think that's the missing thing and if we can improve that together, then I think we can really boost the implementation of those new capabilities.

- Yeah, so we have a monthly meeting with our partners where they come up with new opportunities or options. So we sit down for an hour once a month and we look at, one of the things that we do, I mean especially in my area, that we would say, okay what is the next step? What is happening? So we encourage developers to say, can you come up with an idea that we could potentially implement and you know, deliver in a, you know, whether it improves system performance, customer service or colleague journeys. We review them, we assess them, and if these ideas are successful, we take them on board and we start looking towards implementing. But I mean partners, one of the biggest issues probably everybody's experiencing is the amount of resources or the likeness of resources who actually knows Pega really, really well. We get a lot of issues around the attrition rate is a big issue for us and quality Pega resources is another issue. And when you have really good resources, you wanna get hold of them and keep them a new platform. So these are some of the issues that we've got. So we work internally, one of our things that we do in Lloyd's is trying to encourage our graduate program schemes. There is a number of Pega kind of university grads who actually complete their essay courses. So we're trying to recruit these kind of apprentices or you know, graduate schemes that would come in. We provide the training, the support and allow them to kind of find their career path in Pega development. So that's one of the other things that we're doing. But in terms of partners, a lot of stuff happens. We kind of rely on them to deliver really quality resources as well.

- So when asking what Pega could do better, there's one thing I would strongly encourage you and that is for new customers, educate them better on the importance of the enterprise class structure because that is really a frustrating point when you're starting and you're getting up to speed and delivery and then comes the harsh stop when you recognize, oh my gosh I need to refactor, because what we are having is not carrying us where we want to go to. And that is a mistake that happens in the very beginning. As soon as you get this point you can handle it, but it's something you don't know when you get in contact with Pega for the first time.

- Yeah, no that's an absolutely valid point and we are really working hard on kind of making sure that in the first projects already we set these points because I mean the temptation is so big to just focus on the first project and just do that right and not think about, okay, what is the base that I'm building for the future with that first project? And of course it's a fine balance between too much effort for the first project and not setting up the system from the beginning in the right way. And you have to find the midpoint there and that is always a tough decision to take, but helping you there with that decision is definitely something that Pega consulting can do better. And then the other thing I think we can do better is kind of really early on provide that advisory on what are those overarching steps and design decisions that you take early on in a project. And we are working on this hard, we are coming up with more target operating models, we are working more on our advisory side with building offers there and I know that our partners, I'm pretty sure there's a few of them in the room here as well, are doing the same thing. And that's how we take this to the next level. And then one last, if I would say one mistake that I've seen in some of the COEs that have been set up is also never forget about your end users. Involve them as early as possible in your processes because they are the ones who later will work with these systems. They are the ones who will say, this sucks or this is really cool, this is wow. And the sooner you have them in your boards or wherever where they are represented, the more successful your endeavors and your projects.

- Okay. So we'd like to open it up for questions. If there are questions, if you could walk up to the mic that would be helpful because the room's pretty big. Yes?

- Yeah, we can hear you.

- Well I think from my perspective it's as soon as you consider that if you use a reusable, you don't have to invent it by yourself and you're spending, you save budget and development time, that rather creates a draw. Our bigger task is going to be to make those transparent and to make people aware which functions are available under which circumstances, with which borders. At least that's my perception.

- I think there's another question over there.

- Okay, so my name Sib, I'm also from telecom. I would specifically ask them to enlight the specific evaluation activity and that COEs are also doing this approval for all deployments. I would like to ask how often you are deploying code to production? And second, what are the key measurement area or gatekeeper evaluation activity you as the COE follow to evaluate and approve this deployment lifecycle?

- Was it?

- [Sib] It was to Sam, specific to Sam.

- What is the question? Sorry, can you say that again?

- [Sib] Okay, so you mentioned that COEs are also evaluating or making sure that deployment lifecycles are approved. So what are the key measurement area you have activity which you consider and approve your deployment?

- Yeah, so we have a DevOps pipeline. So as soon as a project starts, one of the key kind of considerations for us is saying, okay, you need to build a DevOps pipeline. Now the DevOps pipeline is managed centrally by our shared services and what that... In the COE we have a combination of resources or team members that would be Pega developers, release management, the DevOps team. And when we kind of review these designs and we decide that this is the right design, then it gets signed off and then it moved. Once the developers completed their rule sets, they close that rule set and move it to the DevOps pipeline. Now the DevOps pipeline team will assess the rules that is gonna be implemented. Just to give you an idea, we implement roughly about once a day into production. So we used to do like one major release every Saturday and we move towards a number of releases during the day, including Saturday and Sunday. And sometimes we release things and when we release it, it sits in production for a while, but basically the DevOps pipeline team will look at two things. The first one, has it been signed off by the COE? The answer is yes, they move to the next one, what is the application compared to, what is the application scoring in Pega? So if it's anything less than 95%, we don't implement it.

- [Sib] Thanks Sam. And maybe one last question to Pega side, as we discussed about COE, we discussed about CAB, Client Advisory Board. I'll be really interested to know if Pega also have client architect board where internal architects are also communicating. I know there are LSA community, but it's a huge round. That would be also one thing which I would like to know from Pega.

- Good question. Can I take that one?

- Yeah.

- I'll take that question. So.

- Okay.

- Yeah, the architects actually there is two types of architects. You've got central architecture, which is your enterprise architects, and then you've got the Pega architecture, which is the lead system architects. Now the lead system architects will make decisions with anything to do with Pega because that's their role, yeah? Now in our organization we are very, very large. We need central architecture and we have a architect that actually when we have a need to kind of say we wanna connect, for example, should we be using REST or SOAP services? That kind of questions, can we use Kafka, can we use MQ? All that kind of questions. These central architects, they will look at the requirement, they understand what needs to be delivered and they help us provide in the right solution. So we build the solution as a lead system architect saying these potentially are the three options that we could take. And we take it to something called Design Working Group, and it gets reviewed and approved by central architecture.

- And I'm happy to answer your question after this session directly because there's another one.

- Yeah. Go ahead.

- Good afternoon, my name is Shanton DeYoung, I'm from De Volksbank in the Netherlands. We are working towards a COE. And one of our questions is which roles are representing the COE? And is it also specific team what the COE represents? And the roles in that team are yeah, are also important for us to have the whole scope of in our organization.

- Yeah, maybe I can start and then you can compliment. I think this heavily depends on how you define the scope of your COE. So I already mentioned it. Our COE is very much IT driven. So we have a strong focus on the technical roles. So we are managing the platform, we have a platform management team, we have a strong focus on outsourcing, so we need to manage our implementation partners, but even as a IT COE, we also saw that certain business architecture capabilities are needed. You need to support demand evaluation, for example, also as a COE. And what we try to achieve over time is, we try to provide an end-to-end service. So business functions can come to us and we can do more or less everything for them. From ideation until implementation, maintenance until retirement of the application. We can't do everything, but we also allow them to bring in their own capabilities. So it depends on how you define the scope. If you really need all that roles or if you can also have certain roles provided by other organization.

- [Shanton] And is it a permanent team or is it a temporary, virtual?

- We have a mixture of internal and external resources. For sure or things like the platform team, we try to ensure continuity. 'Cause only with continuity you can oversee this little application so we are having. For application implementation there we are more flexible. We can carve and cover our teams based on the demands.

- [Audience Member] Hi, thanks first of all for sharing your experience and insights, this definitely helps. Just I want to extend his question on governance, right? So you mentioned that it could be depending on how your COE structured, whether it's a technical COE or it is more business driven, COE, right? But I want to look at the steering level, right? Where you actually need to make things work if they're not working. So do you have any specific roles that you have from a steering committee point of view, maybe the exec sponsors or the technology partners who are working with you, they have their own exec sponsors who are there so that it works at the end of the day because things get stuck and they need to work. So how do you see those roles? That is one question. And second is what's the typical timeline that you see, say maybe from Juergen to Daniel where you have a COE in place and you are getting towards it. How do you see that typical timeline? It is it 12 months, 18 months? I know it's evolving, but what is the typical timeline that you have seen?

- I try to answer your second question first. Just start it. I think it's never done. It's changing according to your requirements, to your scope, et cetera. And I think you will identify the points that you COE can contribute. So I would rather say start lean with the things that are most important to you and then enrich it. How we handle when stuff doesn't work out. We believe at least in Deutsche Telekom about checks and balances. So the projects are organized in a safe methodology. You have business owners, product managers, and then the product owners and the teams. For sure there is a steering board where also the different business units are represented and where at least solutions are discussed on a strategical level. Yeah, they're not interested in the nitty gritty stuff. But that one, and the other thing is the control function of the design authority, which makes sure that no one goes maverick and tries to push something through which is just in their interest, but to keep the whole platform in order. And that works pretty well. Mostly in harmony, sometimes it gets rough, but when it gets rough there is heat and that's good for progress.

- So I think we're almost at time, I see there's one more question and then we'll try to wrap it up and for those that didn't get launched,

- [Audience Member] I Thanks for sharing this. Oh I'm sorry,

- Go ahead.

- [Audience Member] Just would like to know with the, or the level of the participation and the sponsorship you guys got from your C level executives and then how important that was to the success of the program.

- Well as I said, the interest of our C level is very high. We are running these methodology on any system that we got. So also our ERP implementations and others, those projects mostly report directly to a C level or a level below. And also the design authority as a function is directly reporting to C level in order to assure it's autonomy and protect its decisions to regards to pressure from outside.

- Yeah and if I may add, I mean when you really strategically start using Pega and that's when you typically start looking at, okay, how do I build a COE around it? With the Pega system in-house, what you typically see is that you touch many different parts of your application landscape or your enterprise architecture because we provide that overarching process capability that takes processes from end to end. Like if you look at procure to pay or order to cash, that typically touches multiple organizations and multiple backend systems. And so it is really, really important that you have that C-level attention and that C-level support and sponsorship for what you do in your COE. Especially when you become strategic and you build these reusable components, you build that center out architecture and you start leveraging the true power of Pega.

- Okay, with that I'd like to thank Juergen, Samer, and Daniel and Walter. Appreciate your time and thank you for coming. Hopefully this is.

- Thank you Brenda for hosting.