Hello and welcome to our video course: Practical Event Modeling. My name is Bobby Calderwood, and I'm the founder of evidentstack.com and the creator of Evident Design, a web-based event modeling canvas. I've been building event-based information systems with Apache Kafka and the Confluent streaming data platform for over seven years, and I'm honored to have been selected this year as a Confluent Community Catalyst. The Confluent team has invited me to present this video course on how to design, implement, and operate event-based information systems using event modeling. Event modeling was first pioneered by Adam Dymitruk of Adaptech Group, and descends from similar modeling disciplines, like Alberto Brandolini of EventStorming. Event modeling was also inspired by patterns and techniques from the domain-driven design community, specifically CQRS and event sourcing, which we'll describe later in this module. So what is event modeling? Simply put, it is a visual design language and methodology for capturing the blueprint for a business information system. A blueprint is an especially apt metaphor for an event model. Since like any good blueprint for a building, event modeling, one, is a visual design language that enables all stakeholders to visualize the problem, and capture specific requirements for its solution. Two, focuses on the most essential aspects of the system, leaving non-essential decisions to the implementers. Three, encourages architectural patterns that reduce implementation cost, and risk, and four, results in a finished product that provides value to its users and seamlessly integrates into its surrounding environment. In this module, we will dive into each of these aspects of event modeling by looking at a section of the event model diagram for the example system that we'll use throughout this course and its exercises, an autonomous vehicle ride-sharing system that we'll call Autonomo. Imagine owning a super cool autonomous vehicle. After it drives you to work, it would be silly to have it sit in the parking lot for eight or nine hours. Instead, as an owner, you can make your idle vehicle available to Autonomo to provide rides to other people. For riders, it will function similarly to a ride-sharing app. In my experience, capturing requirements for such a system remains one of the key challenges in software development. Most techniques for capturing requirements center on the needs of the software engineers, and are usually text-based in the form of a pile of tickets and an issue tracking system. Event modeling is different, since it provides a very simple visual shared design language for capturing business requirements and mapping the user experience. For example, here we see two workflows for Autonomo, an owner making one of their vehicles available to provide rides, and a rider requesting a ride, which the system then schedules. For both of these workflows, we've made the user experience, user actions, data flow, and system automation evident and visual. The goal of this visual representation of the model is to allow non-software stakeholders who know the business process best to understand and make meaningful contributions, while also being precise and specific enough to be directly mapped to particular software development tasks. Just like the plans for building a house, anyone can understand basic features and constraints just by looking at the plans, but they don't need to know the meaning of every little notation or detail. We achieve this balance of simplicity and specificity by focusing directly on the most essential aspects of the business information system, creating a blueprint that each team member can use in reference. While other design and requirements capture mechanisms focused on elements of a system like user stories, database schemas, API surfaces and interactions, and deploy time dependencies and infrastructure, event modeling laser-focuses on the most essential aspects of a business information system. First, event modeling captures the business narrative, or the sequence of events that describe how the state of the system changes over time. For example, two essential events in the lifecycle of a ride are when the user first requests the ride and when that ride is matched with an available vehicle and scheduled for pickup, both of which we've captured along the bottom of our example model as an orange event sticky note in a horizontal lane representing the ride's event stream. These orange event sticky notes represent event messages that will record to a Kafka topic dedicated to capturing all the events about the rides in our system. Second, the event model captures the customer experience or how the system informs the user about the system's state and how the system empowers the user to change that state. In our example, a rider requests a ride by interacting with the request ride user interface, represented on our model as a UI mockup in the rider audience lane to send the request ride command, captured as a blue sticky note. This blue sticky note command represents a synchronous request to change the state of the system. Later in the process, the rider can view the state of their ride via its read model, captured as a green sticky. This green sticky read model represents point-in-time read only state that is aggregated from the events and can then be presented to the user via an interface. Finally, the event model captures the information context of the business, meaning which teams own and which systems produce the various streams of events and their resulting read models. Other teams in downstream systems can then read these events and read models in order to automate specific tasks and integrate the various business processes together. For example, the available vehicle's model is populated by events from the vehicle's event stream. This vehicle's event stream with the associated commands and read models could be owned and managed by the vehicles team. A separate team responsible for scheduling rides could then use the available vehicles read model produced by the vehicles team as an input to the rides scheduler automated job, represented by this little gear icon, in order to match vehicles with riders. By focusing on these essential aspects of information systems, event modeling simplifies the design down to its essential patterns. In fact, event modeling was designed to visually arrange and group system elements to facilitate several proven systems implementation patterns that reduce cost and risk. First, event modeling clearly separates state changes or writes from state views or reads, which is a technique known as CQRS, or Command Query Responsibility Segregation, which we'll describe more in later modules of this course. For now, we'll simply notice in this model snippet that the path from making a vehicle available from interface to command to event is distinct from using the available vehicle's read model to make a ride scheduling decision. Next, event modeling visually presents state changes as a stream of business events, and recording these event changes in order is a technique known as event sourcing. In our example model, we capture explicit events about vehicle availability, a ride being initially requested, and a ride request being matched with a vehicle and scheduled; in our implementation, we'll record these events to a Kafka topic as our primary source of truth about system state. Event modeling also enables diverse options for persisting read models, using whichever data store technology best suits the particular use case. For example, our available vehicles read model might work well stored as rows in a relational database whereas our ride might work better in a key value cache or stored per user. Finally, event modeling leads to an explicit definition of system boundaries and data exchange schemas. The systems are defined by distinct streams of events. Additionally, each of the commands, events, and read models in our diagram can be associated with schemas so that all system components can know how to handle them. The data flow arrows also make it obvious which components require which data. These tried and true techniques not only reduce cost and risk relative to traditional current state centric systems, but also generate data that is more strategically valuable to the organization. Systems designed event-first using event modeling and implemented using the techniques described above integrate natively into the world of streaming data. Even legacy systems can be event modeled to surface opportunities for putting data into motion. Information in an event model system begins its life being captured as an event on a Kafka stream, or in other words, is stream native. As a result, these systems don't need complex and slow extract, transform, load ETL or change data capture, CDC, processes to bridge from transaction processing systems into the world of streaming data, which reduces the need for complex data infrastructure. It is much easier to integrate with downstream systems using familiar tools and techniques in the streaming data ecosystem, such as the Kafka streams and Connect APIs, KSQL, and ksqlDB, rather than building brittle point to point integrations. Without any additional development work, the information generated by these systems are available to the rich ecosystem of Kafka-based real-time analytics tools to produce data products and machine learning models. One of the key insights in the streaming data revolution is that somebody else in your organization always needs the data that your system generates. Event modeling embeds that observation by making business event information evident in the design and available to the streaming data ecosystem in the implementation. Now that you know what event modeling is, as well as some of its benefits, I hope you'll follow along with the rest of the modules in this course. Throughout the course, we'll continue designing and implementing our autonomous vehicle ride sharing system Autonomo. We'll begin by learning how to facilitate an event modeling workshop to collaboratively design the system with a team. We'll build our event model by capturing the business narrative of events and mapping this narrative to the user experience. We'll continue building out our event model by defining a command API to empower our users to affect change in our system, and a query API to inform them about what's happening in the system. Next, we'll organize and divide up the system while keeping the various parts integrated. Finally, we'll implement Autonomo using the Confluent streaming data platform by designing transfer types and domain types for each model element, implementing the business logic of the state changes and data flow in our model using three simple functions. And by implementing these types and functions using the streaming data platform's infrastructure and APIs. Later in the course, we'll be creating an event model and then implementing the code we've captured in the first two exercises. So if you haven't already created a Confluent Cloud account, take some time to sign up now so that you're ready to go for the hands-on exercises. Be sure to look below for the promo code and use it when signing up to get the additional free usage that it provides. If you're watching this video on YouTube, look for the hands-on exercise link in the description below. My colleague Danica Fine will now walk you through setting up your free Confluent Cloud account. First off, you'll want to follow the URL on the screen. On the signup page, enter your name, email and password. Be sure to remember these sign-in details, as you'll need them to access your account later. Click the Start Free button and wait to receive a confirmation email in your inbox. The link in the confirmation email will lead you to the next step where you'll be prompted to set up your cluster. You can choose between a basic, standard, or dedicated cluster. Basic and standard clusters are serverless offerings where your free confluent cloud usage is only exhausted based on what you use. Perfect for what we need today. For the exercises in this course, we'll choose the basic cluster. Usage costs will vary with any of these choices, but they're clearly shown at the bottom of the screen. That being said, once we wrap up these exercises, don't forget to stop and delete any resources that you created to avoid exhausting your free usage. Click Review to get one last look at the choices you've made and give your cluster a name. Then launch. It may take a few minutes for your cluster to be provisioned. And that's it. You'll receive an email once your cluster is fully provisioned, but in the meantime, let's go ahead and leverage that promo code. From settings, choose Billing and Payment. You'll see here that you have $400 of free Confluent Cloud usage, but if you select the Payment Details and Contacts tab, you can either add a credit card or choose to enter a promo code. And with that done, you're ready to dive in. Thank you for joining us, and we'll see you in the next module. If you aren't already on Confluent Developer, head there now using the link in the video description to access other courses, hands-on exercises, and many other resources for continuing your learning journey.