Today, I will tell you how to save more than 1, 000, 000 yearly on IT. 1, 000, 000 is enough to buy 20 Tesla Model 3. 1, 000, 000 in cash, if you put it 100 bills next to each other. The resulting line will stretch from one and a half kilometer, or one mile, if you're from the United States. Oh my god! Wow! It's a lot of money, because I've calculated it for a company which spends about five million dollars on IT. So we are talking about savings around 20 percent and this scales up the bigger the company, the bigger the saving will be. Okay, so let's begin by understanding what platform engineering is all about. It's a relatively new IT field that evolved from DevOps, aimed at boosting developer team productivity, incorporating security, compliance, cost, and reliability. Runtime observability, and other elements. The idea is to abstract those elements. So the developers can, for example, launch new working environment within seconds without worrying about technology integration or application integration with observability tools. In simple words, if you treat your developers as you normally treat your clients, and think about how to serve those developers, how to simplify the process of building and maintaining applications, So the developers and ops guys can do better their job, which is delivering business value. You will become a platform engineer. Okay, so platform engineering isn't merely about technology. It's fundamentally an organizational change. It's about how various IT teams collaborate with developer teams and business application teams. Why is it mainly an organizational change? because of need to establish a platform in the organization. You need to meet several conditions. First of all, you need to have clear responsibilities, which must be defined for the platform team and for the other teams. This is an organizational stuff. Secondly, the platform team needs to have the authority To define and implement those responsibilities across DevOps tool set, ensuring that responsibilities are not duplicated across multiple teams. Those are purely organizational stuff. In terms of technology, you need to organize the SecOps tools, you need to put orchestrators and you need to have fitting DevOps tools into your platform services. So the service oriented approach and product mindset in a platform team is crucial. Platforms should give a space for developers to communicate their needs and the platform needs to provide it in an organized way. This shift is also technological, since it requires a structured approach to DevOps tools, to automation, orchestration, and to avoid chaos and enforce those clear responsibilities. Within the rules, within the permission rules, rule set in those tools, you can think about platforms as building a system to build and maintain other systems. And to build such a system platform, a platform team needs to have certain organizational and technological power enhanced in your company. Okay, so how do you approach platform engineering? It should be treated like any other product development. You start by analyzing user needs, in this case the developers are your users, and tailor the platform to fit the organization rather than the other way around. You shouldn't tailor organization to fit the platform. This includes planning the platform architecture, defining services, Migration tools and deciding on user interfaces for the platform. Like whatever a JIRA or internal developer portal you will use for interacting with your developers as a platform team. Ultimately, the deployment phase is involve changing team structure, setting business metrics to measure benefits and defining service level agreements, SLAs. Maintenance then focuses on delivering services to developers and ensuring the platform adds business value, assessed through SLA and the feedback. In summary, while the technological aspects are really essential, the analysis phase is crucial and it defines how the platform team integrates and operates within the organization, ensuring that platform effectiveness and alignment is with the business goal of the platform. Platform engineers, in simple words, are not focusing on DevOps tools, but they are focusing on the developers needs. Okay, does it look complicated? Yeah, if you do it for the first time, it is complicated, but don't worry. You can catch like four years experience in this matter just within a few hours. I've spent four years building internal developer platforms as a manager of several platforms and advisor to the people who did it for the first time. Recently, I've released an online course on platform engineering for managers. In this course. I provide you with end to end guidance how to approach internal developer platform, starting with cognitive load analysis through platform services and architecture design, ending up with success measures, case studies, and selling points so you can convince your organization that platform should be built and should be invested in. Okay, let's go back to the topic. so how will our IT work after introduction of platform engineering principles and building your platform? We'll review it from two perspectives, which we are addressing. First is organizational perspective and organizational results, and the technology behind. So as organizational result, first, and the most important one, Stream aligned teams can finally focus fully on delivering business value. They do not wait for resources necessary for SDLC process. They are provisioned with the tools within a minute. They also don't need to configure those tools on or understand how they work in details. They simply use those tools without fighting at the high entry, high level entry barrier. are being forced to manage those tools by themselves. We also know exactly who is responsible for what in software delivery lifecycle. We have communication channels planned, and we have defined services provisioned by platform team, addressing the very cognitive load that the stream aligned team may have, both organizational and technical ones. If it sounds too theoretical right now, yeah, you're right. So time for an example how the things may look like if you have a nicely done platform. so imagine we have a new stream aligned team in a company. Our existing team wants to deliver a new application. Having a platform, they can simply express their need through a dedicated channel. Hey, we are going to build a new software. The software will be created in Java. There will be a data storage needed and exposition to open network to our end users. We are going to integrate our app with core banking system, regulatory system, So on, and we will be handling like thousand transactions daily, mostly from Polish locations. This is what they say for the portal. And based on such requests for a dedicated channel, it can be portal, it can be other way around. It's time for Platform Team to provision the Stream Aligned team with all the resources and capabilities to create, release, and maintain their new application. So in this matter, Platform Team is responsible for to ensure that all the team members of the StreamAlign team have access to the repository of their new application. In this repository, they will find a demo service with the language they provided that they are going to use building the app. This demo service has already to use CICD pipelines, which are deploying this demo application into their dedicated space or dedicated environments in Kubernetes. It can be namespace, it can be dedicated clusters, sometimes it can be even virtual machine. music ends And this demo service are already integrated with all the observability capabilities, logging, monitoring, tracing, where the users can simply go in, log, and define their own dashboards in a very simple way. Alerts, filters, things like that. This demo service is already connected to the database. This demo service is already exposing some API. This demo service is already publishing and consuming some topics. And finally, the team members receive a detailed instruction how to use all of those tools in order to build applications starting from this demo service. What is crucial that all this is done in a matter of minutes through platform orchestrators. Mature Platforms has all of this automated and triggered, simply triggered by the request on the portal. So the platform engineers are not even present. Like in person, in this, in the service provisioning, having everything provisioned at once, a StreamAligned team can focus fully on the application delivery. They can create the application and publish it to end users from the very first day. They don't need to spend time on configuring environment. They don't need to spend time on specifying how network connections should look like. No, nothing like that happens. Because on those areas, developers may not be experts and getting all the requirements and collect all of this data and gather wrap all the tools is simply time consuming. So platform should do it. Okay, so a quick look on technology perspective right now. First, at the bottom layer, there is DevSecOps layer. We have, here we have an order, like no duplicating technologies and capabilities. Covering each step of software delivery lifecycle. This is what most of the companies already have. Maybe not always organized. Not always non duplicating. Not always automated. But this is what you are going to find in most of the big companies. What platform engineering introduces is orchestration and interface layer. In orchestration, you will find a definition of platform services and scripts, which makes changes in each tool on the bottom layer, on DevSecOps layer. to provide a managed service to StreamAlign team. If you take the previous example, the provisioning example, for those will be a script making changes in Kubernetes namespaces, creating databases, creating indexes in observability, creating a repository, moving the demo service to the repository, and so on. At the top level, we have an interface layer, where you can find either a portal, It's a specified channel which developers can state their needs in a structured way and expect a structured outcome. It does not always need to be a backstage instance. It does not need to be a portal. Sometimes simple APIs or even simple JIRA tickets are enough. However, it's better to use tools which are dedicated to it because they have more capabilities once the platform grows its maturity. And probably we are going to see AI and chatbots here in this layer very soon from platform engineering, community, I already know that things like that are already happening. Okay, but a million dollar? Really? Huh? 20 percent of IT budget can be saved using those principles? Yeah. Let me prove it. Okay, so imagine you have 10 application teams in your company. Okay. Each team has more or less six developers. Average salary of one developer is like 50 an hour. Juniors are going to be paid less, seniors, probably more, and each team is creating one application release per month. So we have 12 application releases every year and releasing this application takes one week of the team involvement on the technical stuff, like creating environments, connecting application to observability tools, securing the application. implementing, network integration with other systems, testing if it works, running on the whole company to find right people to create your database, to create your Kafka topic, things like that. More or less bootstrapping all the SDLC tool set. For applications which are quite a long time in the company, it will be less than one week. But for applications which are new, Or the teams, which are new, it will be much more than one week. So blended together, it will be one week and because of no platform services. So because the teams need to configure technical things every time before the release, the overall cost, because of lack of platform is 1, 440, 000 every year. In this case, it's 15, 20 percent of overall budget in such a company on IT. Yeah, it's a lot of money. So the game is really worth to play. Okay, let me know how much your platforms saved you time and money. And if your developers are happy about your current DevSecOps toolset responsibilities and things, if they are not bottleneck. And if they do, let me know because maybe I will be able to help you with the platform. Bye.