Welcome. And I'm glad that you are able to join us today. Um Our topic is on Industrial Dev ops or Cyber Physical Solutions.And this talk um we'll explain what industrial Dev ops is why it's important and our learning um as we've been on this journey together and what is a cyber physical solution as well? Um So this presentation is something Robin and I have been doing together for quite a while. Um I'm Suzette Johnson, I work at Northrop Grumman um in the United States. I'm an ng fellow um ng standing for Northrop Grumman. And what that means is I am one of the technical sort of internal consultants around lean and agile and develop practices and then Robin um who's running a little bit late and hopefully she'll be able to join us. Um But she is from Catalyst Campus also in the United States, uh the CTO and she has also come from Lockheed, which is actually a competive mate, kind of a competitor, sometimes a teammate with North of Grumman in the aerospace and defense industry. And um that is the background and experiences we're bringing today. So, since the title is industrial DEV ops. We thought it would be helpful to start by describing um what is DEV OPS, right? And so it's generic sense here.

We think about it in terms of the software world and it is the processes, the people, the technologies that enable a delivery pipeline of, of features of um new technologies, um new capabilities to end users. And we want to include um technologies and practices such as continuous integration, continuous testing, continuous monitoring. And that way we have a continuous really flow of value into the hands of the users. However, the systems that we build on the Cyber physical solution.

So the Cyber physical solution has software and hardware components, it gets a little bit more complicated um because we might be able to deliver software on a continuous level. What does that mean when you're starting to have a hardware environment um coupled with that, that we need to take advantage of? And we've learned that um we can't just build all our efficiencies into software. We have to pay attention to the hardware as part of that end to end value stream. So we extended DEV ops to think more in terms of industrial DEV ops, which is the continuous um delivery and DEV ops principles to the deployment, manufacturing, um serviceability of significant cyber physical systems that enable programs and our product teams to be more responsive to changing needs while reducing our lead time and a lead time is that um time from a customer has a need to the delivery of value and how can we improve that end to end value stream of that delivery pipeline?

Um When we define this with industry, we brought in a variety of bodies of knowledge. So it includes the lessons from the software dev ops community, the lessons and success patterns from the manufacturing, clean product development systems thinking, right, looking at that whole value stream and of course, um from the agile community. So if you are not familiar with the term cyber physical solution, um that's been around since about 2006. I believe the first introduction of that term was from the National Science Foundation and that are um include systems like the ones you're seeing here um where we build um like fighter jets, um o other auto autonomous vehicles, satellites, radar system, sensors, uh a variety of products.

And it's through systems like this, not necessarily these per se the systems like this where we learned these experiences where I get we were building those efficiencies in software. How do we look across the whole entire system to develop faster? So they are very large cyber physical solutions.

And some of the challenges that we were seeing when we were only looking um at the efficiencies and software was a general lack of alignment among stakeholders um in terms of their practices um having integrated tools so that we could do more continuous um integration, a lack of transparency because of your tools, right, you probably even if you come from a software centric background, you know the importance of an integrated tool set so that you can have visibility of metrics and decisions.

Um You can make those real timely decisions on real time metrics with our stakeholders, the same in cyber physical work, except that it gets escalated because we need to see it not only on the software side, but in the hardware development side as well. So that in turn, then if we start applying these principles, we can um start yielding some of these benefits, which is we want to deliver value in the shortest sustainable lead time. We want to improve the collaboration and knowledge sharing between functional areas. That's between the systems engineering group who help to find the models and the um the requirements to our hardware development teams, our software development teams and our management teams. And how do we improve that collaboration and knowledge sharing will by these, by applying these principles, getting us all together um around some common practices will help do that. Um It helps us improve quality. Um And then in turn, as we're improving quality, we're improving flow through the system. We in turn um want to engage our customers and build customer happiness and of course um happier, more engaged employees as we bring them into the whole planning and um um demonstration of our working systems. So we defined um with industry.

So it was Robin and I, with a, a group of people got together and we're like, what would be these eight principles that we would look at if we were to, you know, define industrial de develops. So, what I'm gonna do is uh the next set of slides, there's a slide um for each of these and I'm just going at a very high level, introduce you to these principles. And then at the end, if you want more information, happy to take questions, um or we can have a follow up if this is your area that you are growing and, and learning and um or maybe you have information to feed back, that would be awesome. So let's start with the first one which is gonna be visualizing around the value stream and for the sake of conversation, I'm going to use an autonomous vehicle. Um That way at times I can have um the discussion in terms of some sort of context and maybe we don't all build autonomous vehicles, but um maybe we have enough familiarity that we can um think of some examples of how this gets applied. So one of the first things we want to do is organize around values. So historically, in some places, um you may have seen where we were organized around functional areas around the functions around the planning to build um design, build, test run, right?

And that's how work was organized. And so we said, well, what if we look at things a little bit different? Those things still have to happen. But what if instead we organize the people and the work around a de um deve development value stream where we're actually building integrated capabilities um um amongst those teams and that collectively, they are all building towards an end solution. And what if we're actually all in a two week cadence where we're doing that and integrating regularly. So we wanted to organize our people around the delivery of um a capability in this context is collision avoidance. So we might have multiple agile teams um organized around how do we build and improve our collision avoidance um for our autonomous vehicle. And we wanna organize people, not around their functional areas but around the delivery of those capabilities of which each team might have some expertise of software, hardware. Um and engineering. The other principle we looked at is multiple horizons of planning, meaning um in our, our software world, right, we have a lot of um agile teams, they do a lot of iteration like two week planning.

Um But we also wanted to recognize especially as we scale the importance of having all of those teams aligned around a common vision. And because of the long lead items that we sometimes have in hardware, we also want to make sure that we are identifying milestones that might come up throughout the year. So that we can work with our um our supply chains because our suppliers need to know um when is the expected delivery for them so that we are feeding that into our road map. And then we can also figure out if something is going to be late from a supplier. How does that impact our road map? And we still plan at a high level so that we want um the flexibility of being able to change or move around and Reprioritize features. But it is taking a slightly um broader view because of the hardware um challenges that we sometimes have. So in this example, here, we have an epic. That's a kind of a big thing that we want to build. Um which in this case is adding a new camera, um adding new hardware with our autonomous vehicle and that includes some level of both hardware and software components that you can see here in the feature road map.

The next principle is um apply um decision based um apply decisions based on objective evidence. That means with every backlog item um from our, our epic that is the, the big thing that we want for the year all the way down to what we're demonstrating at the iteration level. It's all gonna have something that we can actually demonstrate and get feedback on. And that's where the um user and customer engagement is really important because we're constantly validating that we're building the right thing. And it gets a little tricky in our hardware environments because sometimes we don't have the hardware right away. We might have simulated environments, prototypes, 3d, printing, um those types of um kind of technologies that we can take advantage of if we don't actually have the hardware in place. But regardless, we're always thinking about how do we get feedback and um on our demonstrations so that we're going the right direction. And the next principle is about um building for modularity and that comes into play, right? Because if we want to be agile, we want to be flexible, we want to take advantage of new technologies and new ideas and new innovations we have to build for modularity and that also creates a level um of autonomy or, or I should say reducing some of the dependencies between the components of the system.

And if you build software, you, I'm sure you've seen the same thing about architecting your software for modularity. It makes change easier than when you have a tightly coupled system. So the same rules apply here with hardware and software and how we would set that up um from that modular perspective. And then we can demonstrate according to the new capabilities um around those modular uh components. And another principle here is iterate and reduce bash size.

So if you come from an agile background, you will also recognize that. And that is those two week iterations um when we are in a cyber physical world though, we have kind of two scenarios that are playing out. The one on the left, we might be just soft new software capabilities to a physical product that's already in the field to a vehicle that's already been released. And we can build in our that quarterly road map. What are those software features that we want to enhance um to the um cars or the product that already in production. On the other hand, we might have um some hardware capabilities that we need to think about in terms of in this case, a new camera. So we wanna enhance the camera. And if we have a modular architecture, we might actually be able to enhance those that are in production or near, near to production. Um At the same time, we're looking at those that are um currently being designed and we might be able to then swap cameras put in new technologies and take advantage of um of new options that are being made available and then we can test them and provide uh feedback from our users as we are building and enhancing that capability.

The next principle is cadence and synchronization. And this is interesting. So again, in our software world, we are used to cadence, we're used to regular planning, whether it's your every two week cycle or um we're saying also at a regular quarterly cycle so that we can plan out those milestones because of the um engagement we want with supply chain.

However, when we get to synchronization, that gets a little tricky when you have hardware because what if your hardware isn't ready? So we want to think about at what point um are we actually gonna be able to integrate with hardware? Maybe that integration is through a simulated environment.

Um Maybe it's through some sort of model, but we want to be mindful and recognize that we are gonna do a regular cadence of of alignment with our teams, hardware and software. And then um the synchronization points as frequently as we can and we need the teams together to have that conversation as part of our planning and that ties into the continuous integration, right? So when we have that regular synchronization point, um we want to be able to integrate as frequently as we can software hardware is not integrating as much as if you had a pure software environment where you're integrating all day long. Um But we do want to take advantage of how do we uh apply continuous integration as frequently as we can. Um So with our camera, right, we might have an emulator, some sort of software emulator. Um Again, we have um maybe some other type of modeling environment where we can test and um do some regular integration to get that feedback of is it actually working as intended? And that leads us to the whole kind of surge that we're seeing now with digital threads and um digital twin environments. And that is where um we have a model of the um physical environment. And through that model, we can actually test the new features and get feedback.

And our last principle which is test driven development. So in software um might be familiar with test driven development where you're writing your um test first and then you're writing the code against those tests. Well, we also want to apply similar practices in our um cyber physical world where we're thinking about our test first. What models or what environments are we gonna use um to build this test? What are the mockups do we have the test doubles do we have? Are we gonna be testing in a digital twin environment? What is an environment that we're going to be using? And how are we if we don't have the physical hardware available? Um What is it that we do have? Um sometimes it's prototypes, sometimes it's maybe existing hardware that has been released and um that we can still test in, in those environments. So um just test driven development applies both to software and hardware development and bringing that together as often as we can.

Um So those were the eight principles pretty um pretty fast run through of what those principles are. Um If this is something that, that you are really interested in learning more about, we do have several papers that you can go read. So 2018 was when we introduced industrial DEV ops and those eight principles to industry. Um and it was justifying them. Then in 2019, we actually brought in the autonomous vehicle as a scenario to start talking about how those principles could be applied. Um As we moved into a hero's journey, we actually looked at not just the systems environment that we were building, but we also started applying it to the organization. And what in the organization actually has to change in order to bring those teams together. So kind of looking at um how a team structure is set up, how are you actually organized around delivery? Um Also the cultural aspects. Um and then building industrial devo stickiness um really looks at um shared mental models and what are some of the barriers to adoption, the paper we're publishing this year that will come out a little bit later um is really focused on hardware um because there's a lot of um special uniqueness, hardware because of the physical environment.

And we are bringing that paper out where we can talk about some of those um barriers. What are some misconceptions and what are some of the challenges that we still have in the application of these principles and hardware. So in summary, um we recognize the um advantage and the power of industrial dev ops in large complex cyber physical systems and the whole intent or the purpose of that is that we want to increase transparency. We want to reduce our lead time and deliver more frequently and it allows us to innovate faster and of course, continue to build um profitable business. All right. So, um, thank you for your time. I appreciate it and happy to address any questions if there are already. Um So I think we are at the the bottom of our, our half hour time box here. So, um again, if anyone wants to reach out, we're always happy to have this conversation and we're very excited about our paper this year. So it's definitely been a journey. Thank you.