 And let me quickly start by introducing myself. My name is Karsten Schruppmann. I'm Waldorf based, have been with SAP for more than 20 years now. And yeah, I do focus on event mesh, but I go broader. I typically go broader. You see the title event-driven ecosystem. So to me, things are end-to-end, and it's nice to have an event broker. Still, you need event sources, and you need to have event consumers. So you will get the full picture here from SAP's perspective. I would like to start by quickly looking at SAP's view on event-driven architecture. We've seen Microsoft's earlier. We've seen Siemens' earlier. And a lot of it is overlapping. We're supporting cloud events as well. Nevertheless, there are a few things that are different. So we do have a different flight height, I think. So usually it's really about business, business events. Then the next thing I would like to do is to switch over to SAP's event-driven ecosystem. That's the main part of the presentation. So the big picture, what events do you have? What event consumers are there? Then a quick sidetrack in respect to use cases. And third part of the presentation, the road ahead. What is the vision? What is our direction? And look at a few road map highlights. Q&A, I think, we'll do in the chat there. And we'll answer the question. Oh, actually, if you look at the iceberg here, that is always a very nice picture. Because in the end, the event process is really small part. It's the ecosystem that makes you to generate the value there to really be able to harvest those events. And we'll have a look at that in a minute. So business event with an architecture. What do we mean was that? Actually, I watched Climans presenting really a very detailed view of events. Typically, when we talk to customers, we keep this on a higher level. So to me, a business event is a significant change in state. Yes, you can go into the details and can now discuss whether there's an occurrence and there's an event description and there's an event. Typically, to me, the level is really a business process or a specific business case for which I want to find a solution. And I think we had just mentioned that in the last presentation, there are notification events and data events. So from the SAP side, we do support both. Certain backends currently at this point in time still primarily support notification events. We're more and more heading towards data events, but even in the long run, you will have both options. Event sources, we'll go into details later on, primarily for SAP. These are obviously the backends that we do have. Nevertheless, external third-party event sources like Azure events and so on can be consumed on our side as well, obviously. There are two events that you can actually see here if I move myself a little bit out of the way. Down here, you do see a notification event. A business partner got changed. It's originating from S4. This is an event that has been available for quite some time in the S4 system. You can see it's very small. So it just contains the business partner ID and you have to do a callback to get the additional data. So an additional API call needs to be performed. Up here, you see a newer event. This in the end is not a full data event. It's in the end, I call it a decision event. So you got sufficient data in there to decide on whether you require, or if you require additional data to do that callback. With S4, typically without using the event enablement add-on via SAPIO there, you have to take currently what's there in respect to the event. The important point is here, there are notification events, there are data events under certain levels in between and they all follow cloud event standard. So SAP supports cloud event standard as well, we're part of cloud events jointly with Microsoft, Google and so on. So these events are interchangeable. Very quickly advantages, digit advantages of data events and notification events, notification events are obviously very small. You have a control data access. That's one thing that sometimes gets missed because if you do the callback, you need to go through the authentication on the authorization on the SAP backend side. Obviously challenges, there's an additional synchronous step required and you do need a suitable API. So it's not only the event that needs to be there, it's the API that you require as well. I think most customers value data events more. In a lot of cases that holds true, these notification events from my perspective have a place in the event-driven architectures as well. So I think we are on the same page here, probably. So data is included in the event, you don't need the additional API call, you can just execute on the data that you have received. There are different flavors. With ASAPU, you can build obviously all of those flavors because you're completely flexible to build your custom events. So you can have a full data event containing the entire data set of the business object, for example, you can have a custom data event specifically tailored to your needs, or you can have this decision event that gives you some background and then you do the additional API call. And we can discuss whether that is a notification event or whether it's really a data event. I think it's right there in the middle. Obviously the data events can be bigger. You always want to watch data access and protection, just replicating data from SAP backend systems, you want to make sure. And with event-driven architectures to a certain extent, you lose control where that data ends up. And potentially, obviously there's a higher resource consumption for creating the events and for consuming and transporting those. Specifically with event mesh, our pricing is capacity-based. So you pay for what you use. If you use data events, obviously that is a little bit more expensive than using the smaller notification events. Benefits and challenges of event-driven architectures, overall, why would you want to do that? Well, we've seen several times the real-time aspect. Something changes in SAP backend system. You get informed in other systems, maybe even in the Salesforce system of that change. And then you can react. You can build different kinds of integrations and extensions there. That is very important because we are looking at things from a business perspective. For us, it's important to integrate backend systems and applications and other components, other software components on hypercloud providers and so on to have this really huge ecosystem there. And extending SAP backend is another big factor. Flexibility, I think have been mentioned before. So it's very easy to rewire things. Scalability with event mesh, there's a certain buffering there. So in case of peak loads, this buffer allows you to perform on this peak load. What often is missed is this incremental development approach that I really like that follows on completely DevOps principles there. So you can start with a few components, potentially one backend system as event source, event mesh in the middle and then one or two consumers. And then you click in more consumers and more event sources and you grow your lens trade. So that improves operations quality and is quite a nice development approach. Fault tolerance I think is a good point when applying suitable patterns. And I think that that's the point behind cloud events, we go beyond vendor boundaries. Challenges, and I think this is to my, from my perspective, this has not been mentioned aggressively enough. Monitoring and understanding what's going on in those landscapes is something that you need to keep in mind because in the end, if things get really big there, things are getting hard to follow. It's all in parallel. There's a lot of activity, lots of events flowing around and you need to have tools in place that allow you to see what's going on. The add on by the way allows you to see which events have been fired from the SAP backend systems. Now, and that's the main part of the presentation. This is where we wanted to go. And that's the main slide that you're probably interested in, SAP's event-driven ecosystem. And if you look at this, the slide is getting, oh, it's getting packed. On the left-hand side, you see event sources. On the middle, you see our event infrastructure. And on the right-hand side, different event consumers. Let's start on the event source side and let's start with the first backend that was event-enabled, that was S400 Cloud. S400 Cloud does expose events in Cloud events format, notification events to be specific and what you unfortunately cannot adjust those events. So you have to use what SAP provides to you. So these are SAP developed events. Those are standard events. You can look up those events. Same holds true for S4HANA events at api.sap.com, so the API business hub. And you can find the events there that are available out of the box and the data for those events in the description. As said, nice. It's still like data events currently and you cannot adjust the events. What we did then, we took the intelligence services events of SuccessFactors. So there are events that already come with SuccessFactors, lots and lots of events, and down for there, they are in SAP events format. At the same point in time, you can adjust them. So you can build notification events, you can build data events, and you can easily consume them and there are plenty of events there. Then, and Asapio made me very happy there for ERP, for ECC. We did provide the event enablement add-on, which comes for free when being used with EventMesh. So it's only the capacity-based pricing that kicks in there. And the add-on, as most of you probably know, allows you to create your own events, to use Delta or to go for Delta events. You can go for inbound events. So for ERP, there's a lot that you can use currently already. And in the next step, the add-on was made available for SAP for HANA as well. So it's available for ERP as for HANA and for FieldClass. So you might have figured I've marked in yellow, the back-end system is actually the consumers as well, where the add-on plays an important role because with the add-on, you can go for inbound events, meaning the SAP back-ends can consume events and that will become over time and time more important for SAP because we want the back-ends to be an event consumer as well. Marketing Cloud, Data Intelligence, CPQ are other SAP business applications, other back-ends that provide events. That act as event sources. Marketing Cloud, for example, follows the SAP HANA approach. Now, there is something that's happening on the SAP HANA side on top of the current approach. We're going for a web-based approach to create events that will be made available in the summer. So you have this entire ecosystems of different event sources and you can put these event sources into play with EventMesh. Important point here, as said, the add-on when used with EventMesh comes for free except for the usage-based pricing and some of the back-ends do require EventMesh to be in the picture. Currently, that's SAP HANA Cloud already. With the reparates approach that comes in the summer, the standard broker there is EventMesh as well. So this will go via EventMesh. Let's quickly switch over to the eventing infrastructure. So EventMesh is the event broker as a service. On the next slide, I will go into details. There's more though. We have event routing services that we're working on. So jointly with Microsoft, we're working on building this bridge into Azure, into Event Grid. We're working with Solace and respect to building a bridge there. There are different event catalogs because it does not help you. If you need an event, you need to be able to look up whether the event is available. If it's available, you're going to use a standard event. If it's not available, you will build your own custom event. So api.sap.com is the place to go currently. And then there is the event consumer side. So we do have integration suite and extension suite as the two big ones there. A number of BTP services can consume events, project schema, our serverless environment, our serverless runtime there, can consume and fire events as well, sub-data-interintelligence. And obviously there are plenty of third-party options that can consume those events as well. As important, there is learning material and end-to-end guidance. So I highly recommend the Discovery Center missions. They include some missions as well. Missions are basically end-to-end projects, including code, including guidance, and end-to-end. They do include some missions that focus on the add-on for event enablement. So very SAPI-specific there. So what is EventMesh? EventMesh is our event broker service. The idea behind EventMesh is to provide a very low entry barrier and to have an event broker that still grows with your needs. SAP operates it as a service and, as I said, the pricing is based on the traffic. You pay only for what you use. We do support the typical protocols. It skates very well. It supports different quality of service levels to ensure that events are delivered reliably. And it's fully open supporting standard protocols like MQTT, AEMQP, REST, Webhooks, and so on. If I go back to what Clemens had said earlier, it's Q-based and PAPSA. And it offers something on top. It's fully integrated into SAP's event-driven ecosystem. So it's open. So it's a full-fledged event broker at the end. But in the end, you do get something on top when operating, when using it with SAP. For example, if you do deploy a CUP application that you have developed, then the CUP application automatically creates cues in event mesh and so on. So there are a few things here that come as additional benefits. I think I had highlighted those here very quickly. So it's not only the broker, it's the ecosystem. As said, it's a native event broker for SAP HANA and the usage with the event enablement add-on is free and it's just the traffic-based pricing that needs to be paid there. Ease of use, so there's a low entry barrier and you can connect it easily to the SAP backends, openness and focus. So standard concepts at the same time, additional focus on typical SAP customer use cases and very important to me, future proof. So we use it ourselves. So it's SAP's event broker of choice internally and we will push it further in the future. Selected example use cases, I think we've seen the real time one several times. Obviously data replication is something that is quite obvious and we see that all of this is in the integrations area. Vendor boundaries, at TechEd, I was presenting with a Swiss customer. He was in the end firing events by design and from S4 and the event consumer was a Salesforce system, then the Salesforce system did something executed on the data and fired events back to the SAP system. So we're really going beyond vendor boundaries here. New channels, there's a Swedish customer, for example, that consumes the event on a smartphone and so on, smart trigger, triggering workflows based on events. And as you can see, currently most of our use cases are integration use cases. Nevertheless, once you got this integration foundation setup, you can easily build extensions, new user groups. So you build an extension on the BTP for users that might not have access to your support system, or you add additional steps to your business processes. My favorite example is still the one from TechEd Las Vegas 2018. It's almost historic, I still love it a lot. Why? Because it's just something that I miss. Whenever you go and order a car, typically, and I understand this is different, when you order on the internet these days, you get updates all the time. When you do order a new car, you don't hear from the car manufacturer for months and then a few days before you can pick up the car, they call you. And back then, we had thought, why don't we come up with an event-driven solution that informs the customers in a nice way about the car getting manufactured? And the idea was once the car got painted, we take a picture and the event gets triggered, actually back then, out of a production order. And we informed the customer via a Twitter direct message with the picture of the car on what the car looks like and what had just happened. And I think it's a very nice example of an innovative use case of something that would make me personally very happy. And on top of that, the manufacturer could take additional steps, they could still do some upsetting, they could still try to sell some bigger tires or bigger navigation system during that part of the production. A more straightforward use case, a new employee gets hired in a success factor. So the event there, the intelligence service event is called new employee hired. And in the end, based on that event, we shoot an email or send an email to the newly hired employee. We inform the team in the select channel, give some background, the new employee is going to join and maybe really give some background so that the team has a few connection points to talk to the new employee when he or she arrives. And at the same time, we're replicating the user data to a third party HR application. The road ahead, that's my favorite slide these days. A lot of the customers are still here. They are in this single building and I would assume this is Norway. The events get fired when the light is switched on, when the light is switched off, when the jacuzzi is full, things like that. So smaller scenarios still. Some customers are here. So they have developed into a village. So they have different backend systems that they connect where events are fired from one backend system and consumed somewhere else. So it's already bigger. This here will be the next step. And this is just Frankfurt. Frankfurt is on a global scale medium-sized city. Nevertheless, if you can picture the step from here to there, that's already huge. And at some point in time, this will grow into probably New York or Tokyo or Shanghai and all of these different buildings will fire events. So to me, the future is with event-driven architectures. This here is just the beginning. So this will really, really grow. At the same time, I don't believe that event-driven architectures are for everything. There are use cases where other approaches will still be completely sufficient like API, like typical point-to-point integrations and so on. It's going to be a mix. Nevertheless, event-driven architectures are going to grow. We know that because of that, we want to extend the mesh. So we need even more event sources and more events. We need to grow the infrastructure inside and outside of SAP. We need to unify and standardize to cross our ecosystem, but beyond vendor boundaries as well. So cloud events is highly important to us. And that translates and the slide is from TechEd. This translates in a few roadmap highlights here. So we're going broad and deep in respect to event sources. We're increasing the number of consumers. On the next slide, you will quickly see which one I'm really looking forward to. And we are extending, unifying the infrastructure. So the partnership with Microsoft Azure, for example, this bridge into Azure is the big thing, this pathway. But as well, what we're going to offer is a heavy load on cloud-native event broker on SAP on paper. And there's a solace partnership that we're extending. That does translate into a few more concrete updates here. So currently there's this Custom Engagement Initiative with Microsoft. So we're working on that. And the plan is to have the public preview in Q2. The heavy load option with solace, we're working on. And this is more like an SAP internal statement that still has effects on you. There's an SAP managed internal option available. The goal is that more and more business units and SAP more LOBs will use event-driven architecture themselves with the goal to expose more events. In respect to the ecosystem, I was already mentioning the red-based approach for SAP HANA Cloud and on-prem will follow here. I think these two are SAP here directed. So FIATLAS as an event source using the add-on, a stronger focus on inbound for the add-on. Most of the time the focus had been on outbound events for now. Now we are seeing customers looking at inbound quite more often or a lot more often. Event consumption in Kima is already possible and Kima can be used as an event source. And now what I'm really looking forward to is AdGyver, which will be event-enabled for consumption in summer 2022. Improved experience event mesh as part of the integration suite. So we're going to bring those two even tighter together and that's going to be a closer alignment with surrounding technologies like with Subgraph because there are quite some opportunities and overlaps to use those technologies. And with that said, additional material, I just want to point one thing out, check out the Discovery Center, specifically the event enablement add-on missions. This is a really good starting point.