00:00:13

Hello, and the warm welcome to the next session. Um, at the conference here, any this next session we would like to present you an approach. We called continuous quality assurance, what it is and how we implemented it and integrated it in our organization. My name is . I'm the R and D manager of, um, digital buildings at Siemens smart infrastructure building products. And today I'm accompanied by my Siemens colleague, Peter.

00:00:48

Yes, also come from my side. My name is Peter . I'm a principle expert for PLM process innovation with Siemens Advantech consulting. I have a very long history in the lean HR domain, but for more than five years now, I'm dedicated my time fully to the topics of continuous delivery and dev ops. And especially to the questions, how those approaches can be applied in a company like ours as probably most of, you know, Siemens is a very large company, was close to 200,000 employees. We have a history of over 170 years and we're coming from a heritage is really physical, technological electronical products. But of course also in our area, digitalization, IOT, and, uh, increasing importance of software as spreading across our portfolio across our business. And this is also the reason why clouds and myself, uh, today here at this conference and talking about a topic such as dev ops and this slide, you can see the current setup of Siemens with the, uh, operative, uh, divisions, uh, with a variety of sows and something that you might not have seen before is a relatively new ad onto the screen. It's called Siemens Advanta, and that's where I'm located. And the mission of Siemens Atlanta is to really look into this digital topics and to unlock the digital future of our clients. And this is also what we've been doing in the past with my client was clouds with a digital buildings where we're really driving this topic forward that we would like to explain to you today. So I'll handing back to your class.

00:02:34

Yeah. And before we go into the subject, just a few words about my organization, building products or digital buildings was a pioneer in the building industry and provides a full set of products and services, um, around the building. And with this, we are basically turning a building into a smart system. And if you look at the building gay, as an example, you can see, um, uh, several disciplines, which are in a building like a security, safety, power, or lighting, which were historically purely on premise and predominantly hardware based systems. But today they are more and more getting connected to the cloud. And, uh, a user wants to manage, uh, mods to operate and monitor those systems maybe with a mobile phone or manage then the system, why are a cloud-based web service?

00:03:47

And with this, the development, um, we had to change not only to technology and we were also forced to change the way we were working because we were coming from an process world where we had projects with an, um, development time and a release cycle for of, of many months up to, up to a year or even longer. And we had to move to a continuous way of delivering, uh, technology, um, to leverage the possibilities of the digitalization. And here I'm probably preaching to the converted because, um, continuous delivery and dev ops should be all known to you. But if you look at an industrial environment, there's also a lot of, uh, chase and regulatory or other quality assurance, um, aspects, which also need to be fulfilled even in a continuous delivery. And the approach, how we embedded and integrated this in our continuous delivery is what we call this continuous quality assurance approach. And what did he say in detail and how we implemented it and integrated it in our continuous delivery pipeline. This is what we want to show and where Pete and I'll, uh, we'll go into more detail.

00:05:17

Yes, thank you. Continuous quality assurance, continuous quality assurance our solution to try this topic forward in a continuous world, also for industrial companies and from our client, this is a very important topic. And one of the crucial, uh, success factors in A-plus to really, uh, bring this continuous dev ops topic into life and our company as ours, as a cloud briefly explained. And in the next few slides, I will first give you an overview about the core idea behind this continuous quality of grudge. We have developed over the past couple of years and actually applied into a couple of Siemens business far. And then I will also talk a little bit about how you can really manage this and practice efficiently on the, this slide is basically you can already see the core idea of this continuous quality approach. And this is something has to do with the mantra queen to creating you, hopefully after familiar with it, the bottom of line, the bottom line of this Victor labor, continuous integration again, should also be very familiar to you.

00:06:24

I mean, coming from a history where we did project in the past of the new it companies, uh, and now moving towards a continuous value stream with the CI CD pipelines and so on really implied a very different way of working the upper most priority was really to make sure that you always have an up and running system, I Korean system, and with the highly automated continuous integration tool, this is exactly how you can share it. And if you want to know when to move towards the small continuous value stream, like Klaus explained to you, which is all the need for our businesses in certain areas. And it becoming of increasing importance of code continuous integration to a chain, but this is not sufficient because even if you would have perfectly, uh, green working software changes, and we cannot just simply deploy it into a production environment, because there's a lot of additional thing we need to provide.

00:07:21

And I like to call them non-software artifacts before we can actually release, deploy a product. And this equally applies to replying on, uh, deploying also only a very small change, and this is a wide variety of things. Some of them are like end user documentation, service, documentation, installation guidelines on so on, but there's also regular tape regulated legal document, like export control, open source clear. And we also have internal things. We really do want to take care about risk assessment, paid applications and so on. So it's a huge variety of topics that need to be ready, available in a defined state together with the product, with the software before we actually can deploy as pointed out this applies, if you would do a large one year project, but it equally applies. If you talk about a very small change, you would like to deployment after a sprint, for example.

00:08:19

And in the past, when we talked about projects, when we had ground checks, all of this was taken care of by the very familiar milestone quality gate approach. Uh, but this is not an option anymore. If you really want to go and do very frequent deployments, we cannot run this whole milestone quality gate approach anymore. So we really had to think about how can we replace this with an adequate, uh, yet continuous approach that ensures the same quality. And this is exactly what the continuous quality approach is about. And the core idea behind this is, as I pointed out, that you really apply the queen to queen mantra. Phone's a continuous integration from the softer side, also to the non-software artifacts. And we call this continuous conformance and it basically implies two things. It means we have a system up and running in the production system.

00:09:12

So we have all these non-software artifacts already in a valid state. And now if you want to implement a small chain, two things we need to do, first of all, we have to ask the question if this change, uh, requires an update of any of the non-software artifacts. And if the answer is, yes, we need to make sure that we update the software artifact before we deploy it. And this is something that we try to put into practice and that we have evolved over the last, uh, iteratively and coming into more and more practice on a very high level. It's also shown on this aircraft, in the yellow pad at the bottom. So again, what we want to achieve is a continuous frequent deployment of, uh, the software update into the existing products. What do you need for it at two streams, we need the continuous integration stream that ensures the quality of the software should be very fair, familiar to you.

00:10:08

The existing two shines of the channel show shelf. You can implement to do this, but as pointed out, this is not sufficient. In addition, we need the continuous conformance team that ensures the quality of the non-software artifacts. And only if both of them are implemented in both are equally important. We really in a position to do frequent continuous deployment. What is interesting when we, when we do, uh, when you started implementing this approach, we found out that quite a number of the criteria on, on software artifact that in the past were part of these milestone checklist. They are actually not relevant for individual deployment decision. So we lifted them up to a high level, which is depicted improving this diagram. These are for example, marketing or organization or topics, and we still have to take care of them, but we don't have to integrate them in this high-frequency slope.

00:11:01

This makes it a bit easier in the yellow pad because of this continuous conformance stream, we have to take care of less artifacts. And now I would like to dive a little bit deeper into this continuous conformance part, because this is really the Nova pod in this whole set up, uh, that, that we implemented successfully. We would like, uh, uh, to bring across to you. And the next thing we learned when we, again, dove deeper and deeper into this topic, uh, we found out that it's not under the queen to queen mantra, but also another very familiar mantra from the software world. We need to apply to these non-software artifacts in our continuous conformance stream. This is a shift left mantra. And the reason behind this is originally you thought, well, we have maybe a two week sprint. We do this continuous integration on a multiple times day.

00:11:54

And so at the beginning of the sprint, we think about what do we need on the names of the artifacts? And at the end of the sprint, we have it, but this doesn't work for two reasons. One reason is that some of these non Sapphire artifacts, if you need an update, it actually takes a long time. So it's not the two week timeframe is not sufficient to complete this update. And this would then mean by the end of the sprint, you cannot deploy because one of the non-software artifacts is not updated yet. The second reason why it needs to be shifted left is because a lot of these loans have the artifacts are actually required as input for development. And this of course then means if we need for a certain change in update of this non software artifact, we need to have this update ready and completed before we start developing.

00:12:41

And these two reasons said, well, we basically need to shift left haul on this. This does not mean that we do a huge upfront planning, but it rather means that we have a continuous rolling process on these ones off the artifacts. But somehow it's 1, 2, 3 sprints ahead. So we always have sufficient, uh, non-software topics prepared there. So we have sufficient, uh, changes through Edie that are in a certain state. So we can actually start there and loving it. And again, diving a little bit deeper into it, uh, and looking at this continuous conformance part of it that you can see in here now, a little bit enlarged, uh, even gets more so to speak complicated if you want to implemented, because these non-software artifacts we're always talking about in here. It's, it's, there's a very, uh, heterogeneous, uh, bunch of artifacts we have, and we identified four different types of them, depending on the time in this process at when you can do the analysis.

00:13:47

And when you need to have the update completed, the type one is an example as for like, uh, for example, patent applications. If you have a change where you say, oh, before we implemented, we need to rerun our patent application. This is something thing to be takes a very long time, so really need to be upfront. And you shouldn't even think about implementing this new change before you kind of have clarified this page stuff. The next one is type two, and this is extra the most common, at least in our typical scenarios. And this is artifacts where with it RN input for development. And then of course the update of this artifact, if the update is required, quiet needs to be completed before you start development. And the examples are, for example, UX design, architecture updates, or maybe risk assessment. And, but there are other items or non-software artifacts, an example would be a user documentation, but you only can do the update parallel or after development because you need an output of development.

00:14:54

This is the type three in our picture, and we also have stuff like open clearing. We're only doing the development. You identify that you need to update something. So you only can do the analysis during the sprint. So this makes it a bit more complicated because we have to deal with these different types, but it's really essential for this to make work, work that you really have this classification that we have a clear understanding when we can do the analysis for each of these nuns off to artifacts, when does the update need to be available? So that has really ran smoothly and we have everything ready to Dysport. So on the continuous integration on the software development, it really ran smoothly like a conveyor belt in a factory. And this also means that we have introduced something like a ready to develop entry gate for each change.

00:15:45

And this means in addition to the definition of ready, where we talk about test acceptance criteria, we will talk about functional specifications. We also need to have completed for this specific change that you want to start development. All the things on the right hand side that have a green tick marks, and this is a lot stronger and stricter than just having the typical definition of a and so to speak, not taking care of the more maybe for formal aspects beforehand. And this from all buy-in is really crucial for us access because by the end of the sprint really want to be ready to deploy. So we really have to make sure that from the non-software conformance compliance, legal aspect, we already have everything prepared and it's already, and it's all there and it's all tick off. So really when the software is ready, we can deploy because we have taken care of the rest as well.

00:16:39

So this is the core idea and how this works, of course. And if you're putting it into practice, you have to think about, does this work? How can you manage it? How can you implement it in practice? And they're very critical point for us in the beginning was to find out, is this really manageable? And this is what I showed you on this picture was an analysis we did very early in the process, and it gave us really confidence that we underwrite. Again, it is manageable on this picture. We have two teams and this is real data team. A and team B DMA has eight features to develop in the next three months, team B 16 features. And we have the, in this case, roughly 20 continuous conformance criteria or non-software artifacts. And we looked at these two examples that based on the feature, the change you want to implement, for which of those you needed to update what continuous conformance criteria, and those are marked miss blue, and the ones that are not blue means there's no update required because the existing nuns of the artifact is still valid.

00:17:44

Even when we implement the change and who do you can see here clearly. And this is also something that made us very confident that it works superbly on Iran, 10 to 20% of all possible updates that are required, which of course means that in 80 to 90%, the existing non-software artifact is still valid. There doesn't need to be an update, but we cannot ignore it. We always have to do the analysis. And in those cases where the analysis says, yes, we need to do this, uh, update of the non SAFTA artifact as a prerequisite for deployment. What also is very clear too, became very clear to us from the very beginning. And I think all the, for you, if you look at this picture, we have a lot of individual micro items, atomic items we have to manage very efficiently. So it was very clear to us that you want to do it in a tool.

00:18:34

And we want to do it in the existing tools where you have all the information that requirement, the features, the user stories, where we have the test cases, where we actually have the continuous integration information. So what we did in, in all the different projects you've done so far that we said, and you can see it on the left-hand side. We have our typical requirements back down with the, uh, content-based user stories that are already existing in the ALM tools. And we basically developed and found ways for the different tools to actually integrate this continuous conformance on the same level. And because in the different organizations, we implemented this concept so far, we had different ALM tools and in place, we also have different implementations for our continuous conformance on the tool stack. So far, we have implemented a successfully in rate IBM rational team concert in Chara and an Azure Def as structured and too looks like it's always the same principle.

00:19:39

We have to implement these two steps analysis and update in tracking. And in the analysis we did in all cases that we have a predefined checklist with all the criteria identified for the organization. And then at some point in time, when you define the new features, in addition to the functional user stories, the content user stories, you also have to go through this checklist, tick the ones that need to be updated due to this features, and then only send in this tool, this task is created and attached to the feature. And then of course, very important is that you keep an eye on idea as you do the tracking and the updating. And then we have created dashboards and all of them. And again, they of course look differently, but in all cases, the matches is the same. The previously identified updates, which resulted in tasks and the tool, those tasks need to be completed, set to be done all of them for a feature and only then you can implement the feature.

00:20:40

So basically we have kind of two dashboards to traffic splice for every change for every feature. One is one that is not shown on this picture, but the existing ones addressing the software, the testing, and the continuous integration pipeline. And in addition, we have not implemented dashboards in the same tool attached to the same changes for the continuous conformance aspect. And only if both traffic lights for specific change at queen, we are in a position to deploy it. And this is a very clear and transparent and efficient way. And, uh, this is something that we have been successful applied as a pointed out in several organizations. But now I will hand back to, uh, clouds to give you a little bit of an idea of what were the key success factors to really, uh, have a sustainable implementation of this continuous quality assurance concept.

00:21:35

Yeah. Thank you, Peter. And yeah. Um, I started, uh, we started in the beginning to set the clear vision that we want to move into this continuous delivery mode with all the aspects in the same quality as before. And for that, from the very beginning, we implemented a change management in order to be, to be ready then also for a coaching and a roll out afterwards. Then we had to set these new and define these new deployments to Adichie. And of course the most important, uh, aspect or factor was that we identify and analyze the continuous conformance criteria, where to put it into the process and, and, uh, to be ready then as a, uh, Peter, uh, just showed on the previous slide that these criteria and the visualization becomes part of, uh, the tool and is integrated into the tool chain so that you have one dashboard where you can not only see the progress and the status of your software artifacts, but also of these non-software artifacts, this continuous conformance and end the continuous integration aspects.

00:22:56

And of course, and we were not talking about this, uh, in, in this session. Um, but these are these roles, responsibilities and the steps we did also, uh, they also need to be integrated in your, um, ALM process. And ours is based on the safe HL framework. And we met it. We met all these steps also into the process, which was, um, uh, uh, possible. And we've been doing this now for, uh, quite some time. And I have to say this helped us quite a lot because the, um, the releases became, uh, no longer as a prize by the, uh, finishing of the software implementation. All of the adjacent artifacts were also ready and the deployment, uh, was able to be done, um, with the appropriate quality aspect as before in the project driven approach we've been doing for many, many years before with that. We are also at the end of the session, and I would like to thank you for your attention. And in case you want to know more, or I have additional questions, feel free to reach out to us. And the, our contact details also included here on this page, in the presentation. Thank you.

00:24:27

Thank you also very much from my side for listening and I hope we can get in touch and have some exchange on what you think about this. And also some further discussions or the costs of this conference. We have also attached here, a white paper on continuous delivery in DevOps, in industrial environment, something I've written some time ago, and it's sort of a high level summary, not only of the topic we just presented, but of let's say the overall, uh, topic of, of dilute continues to live in dev ops industrial environments. Uh, there also similar other aspects that integrate races. So feel free to download it and to get in touch with me, if you would like to more about it, thank you very much and enjoy the rest of the conference.