 Thank you, Peter. That's great. And what we're going to do now is I'm going to ask Etienne, if you can rejoin us as well, please. And also we're going to be joined by a third panelist, Frédéric Lé, who is the Technology Strategist at DXC's Corporate Technology Office. Frédéric is leading the development of DXC's new Agile Architecture Framework and has over 25 years experience with significant expertise in technology, strategy, enterprise architecture, lean, agile and digital. So, Frédéric, if you can join us as well, please. And thank you both Etienne and Peter. It takes a short while for a panelist to join us. So, while Frédéric is coming on, we had a question came in early on, which was, Frédéric's with us now. Well, let me ask this one anyway. It came in for you, Etienne, and it was in French, I'm afraid. So, humor me with my French. But it's... It is still a challenge for us, which I think means, have you integrated SAPSA in information security steps as well with an agile approach, because it's still a challenge for us? Is that roughly right? Yeah, I think it's good translation. What is at stake when you completely transform the model is not only security. We had to face many challenges around the architecture, the support function and the security and the data. For these four elements, we had to reinvent the way people were coordinated together. For security, it was not a big issue for us because the security aspects are managed outside of the IT departments. The IT department is responsible to develop the new patterns, to put them in production and to support what is in production. But the infrastructure itself in terms of security is managed by another team, which is at group level, which has followed as well an agile transformation without to dramatically change their processes. So it was not one of our concerns. We had the biggest concern about the production itself, the follow up of the production. And I think we managed that very properly by putting in place these leaks. I have talked about this leak mechanism, which is the way to steer the transversal aspects between the different tribes. We have a leak for the architecture. A leak is mandatory in our organization to belong to a leak for a tribe is mandatory. So they have to nominate people to belong to this leak and we have three that are mandatory. We have the production, we have the architecture and now we have the craftsmanship as well because we thought that we had to reinforce the craftsmanship aspects. These are the three leaks that are mandatory in our environment. But to answer the question in itself, security was not in our remit during the transformation. Okay. Thank you Etienne. So welcome Frederick. We've heard from both Etienne and Peter sharing their experience inside their organizations. How does what you've heard there relate to the open agile architecture standard from the open group that you've been so instrumental in driving? First of all, thank you Etienne and Peter for those great presentation. I would say that many of the theme topics you talked about actually are also covered in the open agile architecture and I will maybe focus on a few highlights. First of all, I can see that customer experience, which is one of our first axiom is really extremely important both for Société Générale and Fidelity. The entire transformation ranging from the way objective are defined with the objective and key result, which were mentioned by the two presenters, plus the whole transformation of the organization toward agility, the governance, the mindset and so forth is also very important. Also architecture, which comes as an important theme and is recognized as one of the discipline that not only IT, but also the business needs to understand is also great and we'll finish by that last point about platforms. And I think alongside with what Peter said, platform is becoming more and more important for digital transformation and definitely it's going to be an area of growth for the next generation of agile architecture. So that's in a nutshell and would be much more to say, but I think it's the important highlights. Thank you. Thank you, Frederic. That's great. So let's go over a question for Peter then you're on mute right now, Peter, but have you have you borrowed any practices from an agile scale process framework and if yes, which and if not, why? Yeah, it's a great question. You know, I would say that we, you know, we implicitly hard right in terms of how you deal with the overall portfolio. And, and, and I say implicitly because one of our overarching aspirations was to be really heavily tool driven. And so, you know, as I mentioned agile craft right which got acquired by Atlassian and is now called Giro line. You know, Giro line really implements safe. Right. And I say many of the principles that safe, particularly from managing holistically at a portfolio level. And so, from that perspective, you know, we absolutely do. And, you know, we've spun up. We've had an organization now maybe about two and a half years into our transformation, but literally, you know, educates and, and on boards, domains and tribes, etc. with that tool. So, yes, via the tool, you know, one of the things, and I'll just say one more thing, John, with one is one of the things that we wanted to be really, really careful about is, somebody had tried our job before, from the IT side of the house. And we really wanted this journey in the transformation, not to be viewed as a technology only thing, but really as a set of enabling, you know, practices, patterns and processes intended as driving the value stream. And so we've been very careful not to overemphasize the technology dimension of the enablement, but rather the value of the associated process. Understood. Thank you. Thank you, Peter. So, question coming here. What changes in, go to you first, Etienne, I think, what changes in management systems, planning or budgeting practices were most challenging? And, and specifically, was any area team or group more difficult to change, either from a cultural point of view or a process point of view, in terms of decision making or ownership? A lot. Let's take a question one by one. We, in terms of budgeting, we've changed everything. We've broken the per project budgeting process. It was a, I can tell you, within the investment banking previously, during the summer, you had a period of time, maybe other companies know this period of time, where you prepare the budget for the next year, which was a nightmare. It's the, it's a race where everyone wants to select many projects. Of course, you select this amount of project under project, when you will have only 20 selected or 100 million euros that you need when you will only have 20. It was a nightmare, this process. We've broken that. We, we switched to capacity management. Capacity management means that now the budgeting process is really top done. It comes from the management, discussing the top management of the investment banking, discussing with the top manager of the business, deciding where are the objectives. And depending on the objectives and the main area where we need to invest, they allocate the budget for the year. Irrespective of, it's an irrespective, of course there's a discussion, but it's irrespective of the list of a project that you can select during the summer. So first of all, we switched to capacity management. Once this budget is given to the tribe, it's a given budget for one year. It does not change. It is not because you will have a new project at the beginning of the year coming from the Fed or coming from whoever, that you will have more budget. You will have to really, really prioritize inside your backlog. And then we've switched second element. We switched to resource-based management because now not only it's a capacity-based approach with fixed budgets, but we determine a number of FT full-time equivalents at the beginning of the year. So we give you a number of heads that you will have. So you will not play with the budget by trying to do, oh, if I do that in India, if I do this here, et cetera, I try to do a mix to arrange with the request I have. No, we give you a fixed frame, and in this frame, you are forced to prioritize. That's the key change that we've made. And then who were the more difficult staff to change? I would say, first of all, for these processors, it was a long, long journey. We wanted to switch to capacity management one year after the start of the transformation. In 2018, we only switched last year, so we've lost one year because the structure was not ready. And then we had, I would say, the second one, so top management, and second one are, I would say, the transversal functions of the activities. We are the very big support from the beginning, from the market activities, the activities with the trader in front of the market. They saw their interest directly of transforming the IT, et cetera. But when you impact transversal functions like the compliance, like the risk departments, et cetera, departments that are living by asking many tribes to do many things, they are very difficult to convince that it is their interest as well to switch to this model, which is, by nature, aligned with the business, with the core business. Okay, thank you. I'm going to ask a question of Frederick, if I may. You stressed, and it came out in the presentations, and you just stressed in your brief summary of the open agile architecture standard, the importance of platform is, you know, in a digital agile transformation. What do you think Frederick are the critical success factors to shift toward a platform driven enterprise? There's one thing that caught my attention in Peter's presentation is that idea of city planning applied to platform. And the reason why I'm linking that to your question, Steve, is that when you create platforms, you have a coordination challenge, because that platform is only going to be successful if it meets somehow internal demand and if it's used. And frankly, that coordination challenge cannot only be addressed by either a top down approach. The generic platform that I mandated by the top may not meet the needs of the folks who are supposed to use them. But on the other hand, if you do not define a minimum set of standards of way of approaching it, then you will result into a mess. So navigating between those two problems is probably a big challenge. Peter, I would suspect that you've got to also insight into that one because I saw in your presentation that you're quite advanced on that one. Yeah, no, no, absolutely, Frederick, you're 100% right. I mean, the fundamental issue is, and I think that this is the, you know, one of the key learnings from the CSPs, right, cloud service providers, but they're very opinionated about their managed services. And there's a reason why they are, and quite frankly, if one pays attention, one can leverage tremendous benefit from those architectures. And so we realize that we have to be very opinionated about the standards and practices, etc, etc. I mean, you know, so for example, we've articulated a very concrete set of principles five to seven that defines whether you're a platform. And what's ironic about that is the very first one, you know, is actually rather trivial but rather difficult for those platforms, which is, can the consumers of your platform actually utilize it without talking to you, IE, like a managed service. Now for many IT built platforms within organizations, that's absolutely not true, right. So, and then secondly, you know, the, look, there's a fundamental human desire for individuation. So duplication of capabilities, right, you know, is really easy to occurs very easily in organizations. And so we wanted, again, to be very opinionated about that, that we had a construct IE, this logical grouping of capabilities, and that we were going to use the platform construct as a forcing function for that rationalization, you know, so that we didn't have duplicative capabilities within silos, etc, etc, etc. Great, thank you.