 Mr. Frederic Leake is the Principal Corporate Technology Officer of DXE Technology and he is leading the development of DXE's new Agile Architecture framework. Right now Frederic will provide an overview of how the open Agile Architecture standard can architect the enterprise to enable innovation at speed and scale. So let's please hear Frederic's video. During this talk, I'd like to give you an overview of the new Agile Architecture standard. I will start with what motivates its creation. I will then paint the big picture and introduce its key building blocks. Let's start with what characterizes digital native enterprises. It is speed, business agility and the ability to scale. The digital enterprise must be capable of changing at a fast pace. Is classical enterprise fit for purpose in this new world? Perhaps not. When entrepreneurship departments impose models and standards developed in ivory towers that form reviews and follow gated process, it slows down the pace of agile teams. When this happens, especially when agility-scale frameworks are deployed, such as SAFE or Spotify, enterprise architects become at risk of being sidelined. This exposes the enterprise to the risk of neglecting architectural concerns, which has consequences. First, inter-team boundaries are often ill-defined, which result in two blind spots and we do not work. Second, too many explicit and implicit dependencies significantly slow down CI-CD pipelines, which curtail speed and business agility. Third, it becomes difficult to integrate components and products that have been developed independently by autonomous teams. Finally, developing and maintaining shared assets, such as digital platforms, is challenging. The agile action standard addresses these problems. It has been designed to complement process-oriented agile frameworks. It provides a comprehensive approach to bring back the actual concern at the centre of the digital transformation. Let's introduce now the main building blocks of the agile action standard. At the centre, you see value-driven and concurrent. Why value-driven? Because it's not just good enough to deliver at a high speed new product and features. Those product and features need to bring value to customers. So we need to shift from being driven by requirements to being driven by value. Concurrent, we all know that agile frameworks promote iteration. But you are not going to scale and deliver at speed just by iterating faster. You need to have many teams that work in parallel, that work in a concurrent manner. That really brings you speed, because you will be able to deliver more. Many teams working on delivering in parallel. You will be able to scale, because if you need to develop more product or features, you just need to add more teams. On the top right, we've got experience. Experience is about understanding customer problems, their job to be done, and defining the products that you need to create to do those jobs to satisfy those customers. On the top right, you've got product, and that corresponds to the product architecture theme. If you have many teams working in parallel to develop products and features, you need to architect your product system so that each team knows what to do. You know where you can leverage commonality to develop new digital platforms. On the bottom right, you've got software and hardware. That dimension is about the software architecture that you need to leverage to actually innovate your products, but also to create more automated, more efficient operations. On the left, you've got the operations architecture building block, and that one is about using the resources of the enterprise in an efficient manner so that you can deliver that experience to those products in a way that is cost-effective, so your business model is profitable. The last organization, the variation building block, defines how you shape the organization to actually deliver new products, product experience, and operate the enterprise. Let's move now to each of the building blocks. The first one is experience. For people who are familiar with design thinking, you will recognize the design thinking approach where you alternate work on the solution space, the problem space, then the solution space, and you converge toward defining value proposition. I don't think the product feature and the killer idea that will define what your product should be to actually satisfy your customer. The product architecture building blocks is illustrated by that picture where you see just a subset of the many products a financial company can distribute, and product architecture is about defining those product families and those products in a way where each of the product is modular enough so that you can have teams that are responsible for them, for instance, a team, consumer credit, for instance, tribe, in charge of both designing and exploiting consumer credit products in a way that is not too dependent from other teams. Product architecture is also very important to identify commonalities, and those commonalities will end up in platforms that will be shared by several products, and at the bottom you've got the example of Quicken and Meiyoto, which are digital companies who leverage the power of platform, the power of highly modular product architecture to deliver a new product faster, new services faster. The next building block is the operations actual building block. The idea is to create operating models that are made of value stream and processes which implements the customer and operating journey that the experience design building block has defined, and that operating building block leverages lean management, automation, the power of analytics to continuously improve those value stream processes, redesign them necessary, and automate them with the power of artificial intelligence. The last building, the last specific building block is the software actual building block. I will not go into much detail here, but just say that the Agile Action Standard incorporates modern software engineering techniques ranging from domain-driven design to DevOps and SREs. Those software engineering approaches are extremely important to scale and also to deliver a reliable customer experience because your site is done for, let's say, a few minutes to several hours, and we've seen that with large companies, both digital-native and non-digital-native, it really jeopardizes the customer experience. All of that can only be achieved if we organize the teams and the teams of teams in a way that mirrors the internal architecture, and if we align those teams using a new way of managing which are more based on defining shared vision and purposes rather than giving orders and which uses approach techniques such as defining forcing functions. At the Fagan's talk, you will see an illustration of how forcing functions can be used. The key idea here is that if you have an organization that is not well aligned on your internal architecture, chances are that the organization will win, so you will not be capable of implementing your architecture vision. So now let me give you a few minutes. I'm sure you have a few questions regarding the general actual standard, and I will be happy to answer to them. Thank you for that, Frederic. Are you available? We have time for maybe one question if you're available to answer. Yes, good morning, good afternoon, everyone. Thank you very much for that overview, Frederic. One of the questions that's come in a couple of times already, initially from Eve's video, but you just spoke to it a bit. Can you elaborate a little more on the project to product move, the differentiation that you've mentioned? The product actually is referred to in many drive frameworks. Most of the time product is not defined, and the reason is product may have different meaning for different people. In that context, the shift from project to product means that you are going from temporary teams. You know project teams, you bring resources on board, and then when the project is over, then you disassemble the team to stable teams, which will last in time, and those stable teams are responsible for not only developing a new product, but also operating. You build it, you run it. It's something you do a lot in the software industry now. So when we talk about that shift, we are referring to that. And of course, we have additional product that is more general in the way, which is services and all goods, but the shift to product, from project to product, refers really to those stable teams. Okay, great. Thank you, Frederick.