 This is, aha, we're going to talk about platform building. I've spent some hours with the CNCF Tag App Delivery white paper about platform building. And I've also spent some additional hours drawing some stuff for you. So I hope you find it worthwhile. In five to seven minutes, I'm going to distill all of that information for you. So let's do this. So meet some new friends. This is a team of application developers. They're in charge of building and maintaining a microservice, adding new features, and integrating their application with business components, as you can see from the picture. They do their jobs well. If they do their jobs well, they're concerned with things like implementing message queues and brokers, collecting telemetry data for observability, using authentication systems for security, integrating databases and object stores, running tasks and pipelines, and creating development environments. In a typical organization, the app team is likely to be choosing which tools to use, configuring them, and adding them to their development environments, integrating the tools with each other, using the tools. Of course, that's an important one. And then monitoring how they're used all on their own. This is a lot of work, and it's not adding business value. So then consider that most organizations have many such teams, each implementing and managing the same foundational, yet undifferentiated capabilities, all on their own, and in custom ways. So this results in some problems. We have duplicated efforts. We have that capabilities are difficult to secure and govern. And finally, it's difficult to onboard to a new team or to switch between teams. So that's why larger and more mature organizations are building platforms. So what is a platform? A platform provides interfaces between platform users and platform capability providers, which we'll talk about shortly. Platform users may also include data scientists, off-the-shelf application operators, information workers, and more. So platforms provide and manage common capabilities, like the ones we described earlier, to platform users, in this case, to our friends, the application team. Platforms are built and maintained by platform teams. So platforms are self-service. So here, our application team autonomously requests a database from the platform. A platform should be composable, enabling platform users to request only what they need and nothing more. So there, without any human interaction, the app team is able to provision their own capabilities. The capabilities provided by the platform are secured by default, and they follow best practices regarding governance and compliance. And these best practices are specific to their organization. This lowers the cognitive load for application team friends so they can focus on making their microservice and adding business value. As a platform matures, it can start to offer compositions of capabilities. So for example, it could offer a Kubernetes development environment pre-installed with messaging and a database, and it's all already working together. So this, of course, would follow company policy too. So for the developer, the idea is to make the right thing to do the easy thing to do. So a platform is also meant to serve many application teams. So it should be designed to support broad capabilities that are used across the organization, rather on focusing on specific use case for one particular team. So as I mentioned before, platforms are built and maintained by platform teams. These teams provide internal services to application teams and to platform users generally. Platform teams do not provide the capabilities. So who provides the capabilities? Experts. Platform capability providers develop and maintain the capabilities offered by the platform. So this diagram is a bit of a misrepresentation, though. This diagram makes it look like the platform capability providers are all together on one team. But really, it's more like one or many messaging experts provide the platforms messaging, one or many identity experts provide and configure the platform's identity management offerings, one or many infrastructure experts provide and configure the different possible Kubernetes environments that are provided by that platform. So these experts are often dedicated internal teams, but they can also be external organizations. A cloud provider would be a great example of that. So then what does the platform team do if they're not the ones providing the platform capabilities? Platform teams create the interfaces to the capabilities for the platform users. So there are many possible interface types. We have a documentation with search functionality. That would be a really simple example. Or perhaps there are templates from which platform users can start projects. Maybe it's a CLI. Maybe it's an API. Maybe it's a GUI or a web portal. Maybe the platform users access the capabilities through the IDE or any combination thereof. There are so many possibilities. So how does a platform team decide which interfaces to make? How do they go about making those interfaces? To answer that, let's go over the different roles that might make up a platform team. So we have a platform product manager. This person communicates with the application teams and researches the platform user requirements. So they're always looking for the next most impactful way that they can lower the cognitive load for platform users. So this person is also going to gather feedback to see what's working and what's not working. The platform product manager may also manage the day-to-day work of the platform engineers. These people are likely to do the engineering work of building and maintaining the interfaces to the platform capabilities. So as the platform evolves, other roles can become part of the platform team, too, such as platform operators, QA analysts, UI UX designers, technical writers, documentation is so important, and developer advocates. So a good mindset for the platform team to have is to treat the platform as a product, where the platform users, like our application team friends, are the customers. So in conclusion, platforms enable developers and other platform users to deliver applications and services faster by providing and managing common capabilities. Platforms bridge between platform users and platform capability providers, and they're built and maintained by platform teams. That's it. Thank you so much. Thanks for being so patient. That's actually a link to me. But thank you.