 So maybe before starting my representation, I'm very proud to announce that with Eric Cohen and Axel Lagont, with the heavy support of Birgit and the AEA, we launch the French chapter of the association of enterprise architects. So wow, very proud to announce that today, but we are not so proud because for many years there is no French chapter of the AEA, so we just correct, just fix it. So French people, please come to us to discuss that and we will bring more news, maybe two days and a few next weeks and months just to recruit people for the French chapter. So that's it, okay? I'm starting. It's called Continuous Architecture. Just remember that it's really a work in progress because things are changing very rapidly and we're just starting to really think about agility and architecture. Okay? Just a few words on Arismoor, I know you know Eric, so it's okay. Well, I'm happy to say that we are the French leader on the AEA. Just a few words about Arismoor Academy because we are very proud to certify a lot of people in Tugaf, Archimate, and we start thanks to Sylvain to have the first 84 IT certified in France. So we are very happy with that. Okay? So it's quite easy. Why Continuous Architecture? We'll try to go fast on that. I hope you're already convinced that we need to have agility and architecture. So that's what we call Continuous Architecture. So what is Continuous Architecture? And I want to do the art of the presentation about how to do that or how we start to try to do that. Okay? So what's the problem with the agility and architecture? So I think that this is the best picture I found on the web to explain the problem. People from the agile side want some salt. So he asked an architect to have the salt. And 20 minutes later, he don't have any salt or anything. Okay? So what's the problem? The architect is preparing a better solution than just giving salt. And that's the problem with the agility and architecture. They are both okay, but are not really working seamlessly together. And yes, it's right. You want the salt just now. And yes, you're right, Mr. The Architect. On the long term, it's better to create some things for any sort of condiments. But you are managing these two parts. Okay? There is a way, but it's not an easy way. If you're from Wales, maybe you may recognize this mountain. I do not remember the name because it's sort of a Welsh name. But that's the famous mountain in Wales. There is a difficult way between not enough analysis. And that's maybe from the agile part. They want to go fast. They want to try and learn. And they do not do maybe enough analysis. And on the other part, there is too much analysis problem. And it's probably the way the classical architects want to do that. So we have to find this very, very narrow way to do both things. Okay? So I'm starting with a quote from Wild Cunningham. Who knows who is Wild Cunningham? Maybe you don't know who is Wild Cunningham. But Wild Cunningham is recognized as the inventor of the technical debt metaphor. It was long time ago that he invented the technical debt metaphor, which is, of course, some things you already know. If you're a real architect, you already see technical debt face to face. And it's not funny. But Wild Cunningham recently writes more articles to explain. And this is another good explanation about why we need to have this continuous architecture concept. Because you do your best, but you only produce a solution that reflects your current understanding of the problem. And the truth is that your current understanding is always a partial understanding. So even if you take more times to analyze the problems, you still have a partial understanding. And maybe you could analyze forever, you still have a partial understanding. So the way to reconcile that is to have feedback. So maybe I'll just stop to why we decide to call that continuous architecture. Maybe if you Google agile architecture, there is something called agile architecture. There is something called evolutionary design, emergent design, evolutionary architecture. In our small, we like to say that architecture is from end to end in programs and projects. So for us it's quite natural to say that a continuous architectural effort. And of course it's clearly related to what is called continuous integration. And continuous delivery, which is part of the revolution in our ecosystem. So we like continuous architecture, but just called that agile architecture, emergent design, evolutionary architecture. That's okay for me. Okay, so what is really new? It's not really new, but the big difference between architecture before and with continuous architecture is that, in fact, we want to have feedback. So it's just a new cycle, learn, build, measure, which is very, very different from our classical cycle, which is think, build, run. And most of the time there is not clearing between think and build, not clear links between build and run, and not enough, maybe no feedback at all between run and think. So the new thing for architects is that you start, yes, with a bit of thinking, but you're in a feedback and interaction with the build phase and the measure phase during the run phase. So the idea of feedback, of course, is not new, but by the way, the agile is not really new. I think that's the 20th anniversary of the algae manifesto, by the way. So it's not so new. For many architects are new, that's really, really a new thing. Many of them are really happy to just to think and then other people build and then other people run. And if it's not running well, it's not my business. I'm sure if you're here, you are not this kind of architect, but there is this sort of an architect. Okay? So what is continuous architecture is architecture with feedback, that's all. So I don't want to elaborate a new definition of what is architecture, because I think that's the real way to know if you are speaking with an architect, you start with redefining what is architecture. So now I'm fed up with just redefining every day what is architecture. So architecture is architecture. Continuous architecture is architecture with feedback. That means that you start continuous architecture when you stop doing just big upfront design. That means you do all the design before and then hoping that people build it right and run it right. Okay? And the real real challenge is to have shorter and richer feedback cycles. Shorter, that means probably in months rather than in years. And maybe the more continuous we will be, more in weeks than in months. And maybe one day more in hours than, days than weeks and then hours than days. But today just have feedback in months will be a real success for many, many of the context. And the other point is to have a real feedback, richer feedback, but not just to take the measure and say, okay, I changed nothing but I have my report. So I really change, I really reconsidering the solution, the architecture, the design of the solution, based on true facts. And not just the fact that we want to elaborate the right architecture. Okay? So I continue the architecture better. It's feedback. If you understand that feedback is the key word and my, the only concept you have to remember, you can go for more coffee and so that's all for today. I will try to elaborate a bit more. It's better, it's better than what? It's better than no architecture at all, which is a great debate and maybe a great divide between many people from agile world. They consider they don't want to do architecture. When I discuss with them, many of the times, in fact, they like architecture and they like to do architecture, but they do not like architects, which is a real problem for our profession just to be sure that maybe we don't have the right way to behave with people. And it's very, very frequent, maybe 80% of the time. The problem is with the architects, not with the architecture as a concept and as an activity. Okay? And it's also better than just big upfront design. So architecture with feedback, that's continuous architecture. Okay? There is many, many things changing with that. So I'm sorry for the real architects, or the real classical architects in the room. If you create a real architecture, you will not win. It will be on the second place. If we create the good architecture, it will be on the third place. Okay? The new things we have to invent, we have to define, we have to create with other people is the good enough architecture. And Eric Cohen from Thales used the lean thinking or the lean approach for EA. And he said that we want just enough architecture. And we want, yes, we want just enough architecture to produce the good enough architecture. And I do not know just now how to really define what is the good enough architecture, which is the problem. What is the good news with the fact that we don't truly know what is the good enough architecture? Feedback. So I start with an architecture, then we have the feedback and we can create a better architecture. Step by step. But we have to accept that we will never produce the great architecture we want to produce. Maybe you know the quote from, I think it's Mr. Gary Duce from Canada. And if you are working on Toga for looking for viewpoints concept in architecture, there was a very powerful quote from this guy, which is an enterprise architect in the government in Canada, something like that. General secretary, I think. And his quote is, architecture is not to create better architecture. Architecture is to create better enterprise. I think that the concept of good enough architecture, it's more creating a better enterprise than to create a better architecture. And once again, it's probably a return for many architects. Another problem with the classical way we do programs and projects is that we have the sequence. Many people from the agile don't like the word sequence. In fact, what they do not like is a predefined sequence. That means you already know before starting the activity we will do. How much that will cost or how many times it will take. And maybe you know that it's not working at all. It's not working for the last 40 years. So that's why the people from the agile world react from that and say, we can't have a predefined sequence. So what if it's not a predefined sequence? It's not from Welsh. It's not a Welsh player. It's a French player. That's one of the most famous French players. It's called Pierre-Enville Pro. And it's played for one of the best clubs in the world. But maybe I'm alone in this room and maybe in Paris to say that. It's called Brieve. It's maybe less famous than the Welsh mountain. But that's okay. The idea of Pierre-Enville Pro as a player, as a trainer, as a rugby manager, it's to develop with the players what you call the situational intelligence. That means that it's not a predefined sequence. And it develops individual and collective skills.