 Our next presentation is the data concepts and project management committee alignment that'll be presented by Pierre Gauden and Chad Lyong. Pierre, Chad? All right, good morning everyone. Good afternoon. So when we talk about alignment, we often think about alignment in technology, alignment in architecture, alignment in goal. But to me, one of the important things that we often overlook is actually alignment on people. And to illustrate what I mean by that, yeah, to illustrate what I mean by that, I would like to show you here is a map of actually where all the different teams or SDU is located at. And as you can see, right now we are close to around 15 countries around the world. So when we are working globally with a team that is spread across the different geography, it's important for us to know and be aware of some of the differences in terms of the working timeline and the different cultures as well. Of course, what I mean by that. So one of the things that I wanted to mention here is that just to take for example, so recently we have an issue that we discovered in Reservoir DEMS as Philip was mentioning about the manifest generation. So what happened was, I would like to just give an example. So Alice actually reached out to me and Alice, she's located in Paris in France and I'm located in, of course, Norway in Stavanger. So now we are talking to both of the team in both Norway and Paris. So what happens next is that we check with Thomas from Norway as well, and then we would have to coordinate with the buses from, and he's actually located in Chicago. And we work out all the resourcing gaps that we have today in OSDU. And finally we reach out to our ingestion team, which is again from EPAN, and he's located in Belarus and Minsk right there. So, and finally we managed to get a fix out for the issues that he was facing, and then we passed the feedback back to Lahon and he's actually located in Houston. So what I'm trying to show is that in just a short span of time, we have four different companies, five different cities and six people that are sort of working together to resolve on this problem right now that we're facing. So I just wanted to show you truly how global is OSDU and for us to be aware of the different things that they're working on in these aspects. Which sort of brings me to my next point, which is alignment on expectation. So we talk about alignment of people and the next thing is of course the alignment of expectation. They are right now two different nature of contribution, if you will. And one is on the fresh development. So whenever we kickstart a project in OSDU, it's mainly funded by the contributing companies. So I'm just going to show some examples like the policy service. Some of the groundwork that's been done was donated and then we have the GCC, David was describing that and of course some of the utilities that were donated by the members of the forum. And right now we have the up and coming rock and flute samples, DDMS. So of course there's always the pros and cons to each of these projects and the nature of it. And of course like for example you would have a longer development time aligning with different community. So it's really a different process the way that you're looking at it. And if you compare that to the existing code donation that we have, like a lot of the core services that we have today will actually sort of develop pre-R3 so things are slightly more on the stable end, they're being developed and accepted true adoption and governance. And the pros and cons behind it is of course we do have a shorter development cycle because we sort of tested it before releasing it to the public and right now there's always the downside of it which we have to look into sort of integrating with the different data models that have been out there and sort of reworking with of course a PRIC on the work that has been done on the data definition side. And this is just a quick slide to sort of show and I'm just using DDMS an example of course we have to work on the consumption zones and the different part of the services that we have in OSDU. So this is just sort of going through the different expectation of people in terms of where we are in the development on the well-bought DDMS, the well-delivery DDMS, seismic DDMS, so things that have been developed and been around for some time. So of course they move at a slightly different velocity, things are a bit progressing, but much slower because we wanted to make sure that we have, we are seeing the adoption right there. And then you have residual DDMS which we just released a couple milestones ago and right now we are working on adopting adoption by more CSP integration as well as integrating with the core part of the OSDU platform. And of course we also have production DDMS sort of pretty new in the scene. That is of course happening behind the scene as well. And we also have the rock and fluid sample DDMS which is just announced last week and the teams are right now working on the different parts of the integration. So a lot of you have been asking so what do the PMC really do? So we do have several levels of governance within the PMC so one is of course to ensure that the project itself and if you know in the open source community we do have the owner of the project itself and we have to ensure the maintainers do have the correct access to the projects provisioning the right privileges to the developers so that they can submit code changes and code reviews and all that process. And we do have a published sets of best practices for PMC. For example, we do want to make sure that they're all following the correct project structure. The mouse doing cadence so as Steve was mentioning this morning right now we are on the M16 release and right now we are actively testing M17. So part of the role is to ensure that this get progresses and doesn't sort of stall at any end. And of course looking at the merge request and of course breaking changes we do have to go through the review from the E8, the advice forum to make sure that everyone's lying on the changes. In 4Sec we do look at security vulnerabilities to making sure that it gets fixed before it gets exposed to the public. And last but not least which we do also look at the data concepts alignment which Pierre Rick right here will share a bit more about how we do it through the data concepts integration. Thank you Chad. Okay, so come back to the example of the RD-DMS I won't cover the whole life cycle that Philippe already did very well but just to show how the RD-DMS is the perfect examples of how the PMC data definition and EA let's say transverse arms and coordination self-adopted the operating model that has been presented by the parallel station. So on this story you can divide the RD-DMS life cycle let's say in three different main phases. The first one which was let's say the inception conceptual definitions. It started mainly based on the energy sticks integration where we decided to adopt the RASQML model. At this stage we had a couple of requirements to deep dive into both the data definition itself how to accommodate the RASQML model within the pre-existing concepts principles of the data definition in the USDU and on the enterprise architecture part what are the main services the RD-DMS should deserve. At this stage the let's say activity of the development and of the PMC was quite poor and progressively we moved to the second phase which was the let's say the core development of the RD-DMS. At this stage the main development have been procceded by Spentech as Philippe said but it has been encapsulated or embedded within the PMC. So at this stage this is where the PMC efforts became the biggest one. We still had those two teams for data definition and enterprise architecture and nowadays we are more in a kind of let's say CICD let's say basis so just dating the RD-DMS based on new requirements but minor ones. So as Philippe said also we merged the EA team and the data definition team. We are just proceeding with the continuous additions of requirements and we are fully aligned and fully embedded within the project team. So we still have the calls dedicated to the specifications but the teams are the same within the specification, EA and DD and the PMC. We can consider in the future having some key game changers, technical business that would require us to come back to phase one or phase two to make big updates on the RD-DMS. We don't know so we need to be... The key what comes from this presentation is that in terms of organization you need to make sure that you have the right contributors at the right time which means that you need to be flexible on the organizations and to do so to adapt your organization to the different requirements and different maturity level you are in your projects. The communication is the key. So definitely we kept discussing together with Chad but this is something we need to formalize and to emphasize and we need to keep for the future. So definitely the operating model that has been presented is exactly what we need. This kind of let's say adaptive organizations and to succeed we need to communicate, communicate, communicate, communicate. And that's passed through a couple of calls. Maybe I won't pass all over but you have plenty of weekly meetings and bi-weekly meetings but that's it. So this is the key things we wanted to share with Chad today so thank you very much. Thank you.