You. Hi and welcome to my presentation about the digital factory, how we can industrialize our product development. First to myself, my name is Romano Roth and I am chief chief of DevOps and partner partner at Zirke. I work now since 21 years at Tilke. I joined Tilke directly after university, became a junior net engineer, then an advanced software engineer, then an expert software engineer, then a lead software architect, and then a consultant. And one thing that was always at my heart is how can we continuously deliver value? How can we ensure the quality of what we are building, and how can we automate things? And when the whole DevOps movement started, I jumped right on top of that, became one of the organizers of the DevOps Meetup Zurich, which is a monthly meetup we are doing in person in Zurich. And you can always join us, it's completely free. And I'm also one of the organizers of the DevOps days Zurich. The DevOps days is a global movement. In all of the big cities all around the world, there are DevOps days. And I'm the president of the DevOps Days Zurich. And you can see DevOps is really a topic that lies at my heart. And that's also why I have my own YouTube channel with over 100 videos all around DevOps platform, engineering, architecture and leadership. And I'm also posting quite a lot and tweeting quite a lot. You can always follow me on all of the social media channels that you see there. When you want to learn more about DevOps in the products that I'm doing, I work for different clients in different industries and I do DevOps transformation. Now when I'm at such DevOps transformation, or when I go to the clients, then I see the following picture, which you can see here. The business together with the clients, they have great plans. They are putting these great plans into ideas and they put that into word documents and into gyra tickets. And then they throw these word documents and chira tickets over the wall of confusion to the development team. The development team looks at these documents and they say, yeah, if you want to have that, we can implement that. And they implement it and then they throw it over the wall of confusion to the testing team. The testing team looks at that, what got delivered and looks at the specification, and it is not the same, but they test something, it's green, and they throw it over the wall of confusion to the operation team. The operation team said, how should we operate that? That will never ever work in production. But of course, somehow they get it to work and it goes back to the customer and to the business. And they say, hey, what is that? That's not what we wanted. This is not usable. And what you can see here is actually this infinity symbol. This is a value stream. And in that value stream you see all of these walls of confusion. And these walls of confusion, they are coming from the silo organization, which we find in many companies. So the value stream, the value flow is broken by these walls of confusion. You also can see that there is no alignment. These different organizations, they don't work at the same goals. And overall there is a very bad developer experience and a complete lack of excellence, also of software engineering excellence. Now there is this big movement of DevOps, where you put the client into center, you stop using projects, you go into product development. So you have products instead of projects, and you continuously deliver value across the value stream. So DevOps is a mindset and a culture and a set of technical practices which allows you to continuously deliver value or the products to your customer. So when we talk about DevOps, then we also need to talk about that term, DevOps, because that term DevOps is not so well chosen. It says development and operation. And of course there are some people, smart people out there, they say, yeah, we need to fix that term, because nowadays security is very important. So let's call it devsecops, which is development, security and operation. And others say, no, we need to call it Bisdev ops because the business is a very, very important, they are giving us the money. So BisdevOps business development and operation is the right term. And you can see this discussion does not go everywhere, because as I mentioned before, it is about organizing across the value stream, bringing all the people together which work on a product. So we should need a term like Dev, Sec bits, Arc, user experience, quality assurance, Ops. Or we just call it DevOps, because DevOps is about bringing all the people, process and technology together to continuously deliver value. This is what DevOps is at its heart. So what does that DevOps bring us? So science has looked at that, there is this state of DevOps report and the amazing book accelerate which had a look from a scientific perspective to DevOps. And they are comparing companies which are not doing DevOps versus companies which are doing DevOps. And you can see the benefits are huge. For example, you have a 973 lives, increased deployment frequency. So how many deployments you can do also faster lead times into production, faster time to discovery, and you have a much lower change failure rate. When you summarize all of that, then you can clearly say when you are doing DevOps the benefits are you get more value for the money, a faster time to market, a better quality, a higher customer satisfaction and top qualified employees. This is the benefits of DevOps. So now we have understood what DevOps is, but doing DevOps is already quite difficult. Scaling DevOps is even more difficult. Let's have a look how we scale that. So usually what we see in companies is this picture. You have different development teams and then you have the wall of computation and then different Ops teams. And many companies try to fix that by establishing a DevOps team in the middle. While this is sort of an okay start point, it is not a real solution to the problem, because with that you are just introducing another silo and you are not organizing yourself across the value stream and bringing all the people together to work on a product. So it's just another silo. But of course it can be a starting point. Now, how does DevOps look like when you are doing DevOps? Then you will have such a picture where you bring all the people together, not only dev and Ops as you see it here. So there will be all of the people which are working together in product teams. But this is also not the silver bullet, because with that you are introducing quite some inconsistencies and some redundancies. And you also can see that many of these teams, they are lacking product or operation experience. And of course there is also that complexity, for example of the toolings of the cloud and everything. So there is quite a lot of cognitive load on these teams. Let's have a quick look on the tooling. You may have heard of the term CI CD, which is continuous integration and continuous deployment or delivery. And usually what I also say is this is not enough because what you have in front is you have the continuous exploration where you are doing the requirements, engineering, the ideation and all of that, the backlog management. And in the end you also have the release on demand where you are continuously deploying and switching on and off features. So the whole thing is called continuous delivery pipeline. And here you see just an example of such a continuous delivery pipeline. It's really an example of what kind of tools you have in there. But what you can see is you need to integrate all of these tools together and you also need to maintain all of these tools. And when you have DevOps teams, they need to maintain that there. They need to maintain their continuous delivery pipeline. Of course, there are big vendors out there which say, hey, we got you GitLab, GitHub or Azure DevOps and other vendors are out there which say, yeah, we have that DevOps platform for you where we can cover everything. When you take a closer look you will see, yeah, they have a platform, but still you need to integrate quite a lot of tools in there. And also they are promising that they have everything, but in the end they are also integrating some other third party tools into that and you still need to maintain, of course the integration is quite good and everything is okay. Nevertheless, you need to understand these platforms. Now you have recognized that DevOps is a mindset, a culture and a set of technical practices. It's not only about tools, it's also about these technical practices. And here I show you in this DevOps cycle what that means, these technical practices. So if you want to build great products, if you want to do modern software development, then you need to implement these technical practices in order to continuously deliver value and build in quality. Of course you don't need to implement all of that, but some of them need to be implemented when you want to build great products. And what you also can see is, and especially when for example I join different clients, what I see is when a new team member or when I join a team, the onboarding takes quite a lot of time until I have really access to all of the environments, to the source code, to the repository, to the CI CD pipeline, to the Kubernetes cluster, it takes weeks and even months. And then when I want to have for example a new Kubernetes cluster, new VM or a new database, it again takes quite a lot of time until it gets provisioned for me. And also when I got it, usually I need to configure it according to words document or a gyro ticket. And when it comes to devsecops, doing devsecops, identifying all of these vulnerabilities, this is also quite a huge topic. When you enable vulnerability scanner license compliance, scanner software composition analysis or SAS, you get a lot of vulnerabilities and you need to make sense out of that. In the end, what you can see in most of the product development or the projects, you have a bad time to productivity, a slow time to market and low quality and no standards. So this is quite bad. Can you at all scale DevOps? Is that really something that is possible? For that we need to make a step back and think about what do we want or what does our company want. And I'm bringing now you a picture which I will build up so that you understand what we really want. On the top level you have the board, the board of directors, the management and what they have, they have a clear vision where they want to go with the company. So, for example, in this example here, you have a drone, you have a small market share and you want to have more market share. In the end, you want to earn more money and get bigger. So potentially you want to have more drones. When you only have software products, it's the same. You have a small application and you want to have more application or a bigger market share. So what does these people do? They are the portfolio level. There you have the portfolio of all the big initiatives. They have a portfolio backlog, and in the portfolio backlog, there are all of these bright ideas, and now they will choose the most promising bright idea and give that down to the product level where the product managers are. So in this example here, you see the board of directors, they have chosen that they want to build a drone which can lift heavy weights. So that's the idea. It's not yet a product around that. And they give it down to the product managers to sketch it out. What do we need to make? Sort of a drone which lifts heavy weights. So they give that down and the product managers, they will have a look at that and they will extract the features out of it, which you need to build. For example, a drone which can do the heavy lifting in software, it would be the same. Perhaps you want to have an additional software, additional feature and you would give that, again, down. So on the product level, you have the product backlog, where all of these features are in, and these features are then broken down into user stories, which you give down to the team level. And of course, they are all discussing these things. They are working very closely together. You always have feedback cycles from the top to the bottom. But in the end, you have teams, perhaps already working teams, and you give these user stories down there. They are going on the team backlog, and the teams are continuously working on these user stories. And of course, because you are now creating perhaps something special, like here, you perhaps also need a new team in order to create that. And this is where the platform engineering comes into play, which builds the platform for these teams. The teams are owning their own platform, but the platform engineers, they are providing these platforms to the teams so that they can work efficiently on these platforms. Here in this example, we will create a new team with their new CI CD pipeline. In the end, all of the parts are coming together, are getting assembled and it will be shipped to the customer and the customer will be, of course, happy about that. But the most important thing is now we have implemented the first step, we deliver value very fast to the customer. Now what we need to do is we need to get feedback from the customer and we need to make sense out of that. And it's not only customer feedback, it's also the whole telemetry about how our application is working so that we can again give feedback also to the teams. And you see that in there, feedback goes everywhere. It not only goes to the teams, to the product level, it also goes to the portfolio level, to the board, because they had an idea, an idea has hypothesis, and now they can evaluate if this hypothesis is true or false, if they want to invest more money into this idea, or if they want to stop investing money in this idea and build something else. And what you see here is exactly a digital factory. And this is what most companies want to have. Talking about this platform engineering, I think here we need to dive a little bit deeper so that you get a better understanding, because the platform engineering is the foundation of the digital factory. So in the end, what you want to have is you want to have product teams which take care about a product. They build it and they run it. So the whole operation is within them. In the middle you have the platform team. But bear with me, this is not a silo organization which you have, and you again have walls of confusion. No, they are building a product which the product development team can use. And the point lies on can. They don't need to use it, they can use it. They need to love that product. Let me give you another picture about that. You see, the platform team builds the platform and the platform can be different things. It can include API gateways, CI CD pipelines, repositories, synthetic test data, kubernetes cluster, and so on and so on. So really the platform where the products of the product teams can be built upon that. So the platform teams, they develop, build and maintain the whole platform. So they are generating value for the product teams. The product teams, they generate value for the customer. So the platform team, they are enabling the teams to do DevOps, because the platform teams will build and run and maintain their products using that platform. And here again, it's very important, they need to love the platform. So the platform itself is a product and you should never force the teams to use this platform. They need to want to use your platform. That's the approach you want to follow. But platform engineering is not the only thing you need to do. You really need to look at the digital factory from a holistic point of view. Because when you want to deliver complex products. This always requires a holistic approach. And it's not only about that platform engineering which you have in the DevOps part, where you have the platform, the CI CD pipelines, the platform engineering, also all of the practices. You also need to have the right architecture to ensure the scalability of what you are building. You need to have the quality standards and also the APIs. But not only that, you also need to have the data because you want to make something out of the data. You want to have effective data pipelines, you want to use the data. So in order that you can make the right decisions. And this leads us to customer experience only with the right data you can have a great customer experience. Because customer experience is all about gathering feedback from the market, from your clients, and ensuring that you have a great end to end customer experience and to continuously deliver. You need to have an agile program delivery where you have the different teams and how they are working with each other, backlog management and all of that. And on top of that, you need to have the product management where you connect the strategy with the execution. So all of that is needed to build a digital factory. As you can see, the platform engineering which this conference is all about, is about building that foundation of a digital factory which enables their teams to do DevOps. And as you can see, this is how we are entering the age of industrialization in software development. Thank you very much.