00:00:12

Welcome everybody. Thanks for joining us. Uh, we're going to get started. We're talking about within the government, within the air force, bringing DevSecOps into the org into an organization at supersonic speed. Well, after three years of progress, we're getting there. We're, we're in, we're making steps

00:00:30

And we're going to bring up a lot of acronyms. We're gonna have a lot of jet metaphors, so it'll be prepared. Okay. I'm Derek Bissinger. I go by ER, and I'm a retired 20 year air force pilot. So the B one and currently living out by checking my second childhood, um, enjoying life as a software engineer. Now, back in the government, part of the 309th, uh, software engineering group,

00:01:03

I'm like Snyder. So I'm a principal heading up our defense business unit at our small company Timo. Uh, we do cloud native dev sec ops and transformation work for both federal and commercial customers. And I am pretty much the most non-technical person ever working in the, in the technical field. So we're going to keep this

00:01:24

Pretty good if you've pretty well. All right, so I'll start this out. Um, government is huge. If you can imagine the air force governed by DOD, um, it's a large entity. So when we try to talk about dev ops in at least this, this, this presentation, we kind of have to keep that in mind. Um, I was working with industry before I got into the air force. I was part of the corporate software development world, and I really wanted to bring all of that dev ops goodness that the industry really has grabbed onto and bring that to government. But then I realized how big the government is and how difficult it is to actually affect change. So this has been about three years of work for me to get to where we are today at this presentation. And so I decided to break it, break it down into let's find a small team to pizza roll, let's get them together and work as much as we can with industry to learn best practices, to learn dev ops, to learn all of these different tools and all of these different capabilities that exist.

00:02:50

Um, and really about a year ago, I realized that what we really need to do at the 309th is bring on best of industry engineers on contract to sit side by side with government, to be hands on developing solutions together. And this latest after that we're presenting here started in April and it was our first real run-through at the 300 knife with dedicated contract support with best of industry. And we were very, um, well-suited in that set up with our small pro prob problem set to develop capability very quickly. And our, our goal was to bring DevOps to the government, to lower cycle time away from the current months that we experience within the 309th to a matter of hours. And really this is just the starting point. Um, but it sets the need for what we need to be doing within government, how we need to be working at this. And it's still very much the need today

00:04:06

When one of the things that we needed to do from the beginning, what we found is that traditionally, when contractors were brought in, it was to holistically outsource all the development work or push it off or get it out of the government's ownership. What we came in and came on board as part of this team was how do we help to build the organizational capacity within ER and his team to help them one take more ownership of the path to production so they can, so we can continuously improve it, but to also, how can we solve problems and work together and be more of a partner organization then just a full outsourced. So it's a different dynamic for the, for the 3 0 9, this he was saying to do this.

00:04:49

Um, we're going to be thrown a ton of acronyms at everybody. So just going to set level set of few to get started here. So a big one that I hear is the swag we've mentioned the 309th already. So there are three software engineering groups across the air force, and each of them are associated with the three maintenance depots. So the 309th, which is based and connected with hill air force base on an Ogden or out in a Layton, Utah, just north of salt lake city, the 76 swag, which is connect, which is at tinker air force base in Oklahoma city and the four oh second, which is at Robins air force base, then on Warner Robins, Georgia. So all three of those groups have very specific mission sets, customer report, a portfolio of a lot of different customers, weapon systems, aircraft systems, um, and other software programs that they support.

00:05:39

And with the mission of doing cradle to grave, software development and software sustainment for the air force, um, one of the big, the big pieces of, of software that's one of the most traditional architected elements of the, of the entire of the entire is the OFP, right? The operational flight program. That's the embedded system software that the aircraft will not fly without O F piece. It controls, it helps it integrates and controls the propulsion, the avionics, the navigation targeting systems, all the data, everything that that operates within those aircraft all is, is run through the OFP, um, rapid OFP. So the next thing for that, again, like we were saying before the OFP cycle to get any updates is typically months sometimes longer to get, to get those things deployed out to the whole fleet from initial concept development, through testing development, testing, all the testing on systems, integration labs, testing on the aircraft, and then deployment, right?

00:06:46

The rapid old P framework that, that yours has really been leading with with the team at ski camp. And the 3 0 9 is a stock is looking at that solver supply chain in a small size, small enough size that can extend all the way from either a cloud or an on-prem development environment to an invented system point where in the field, right, as we said on here, it's within 24 hours or less, that is a game-changing vision that we're looking for. How can we build that software supply chain that breaks, breaks out of that traditional mold, but really sets a new way for safely securely ended? Unheard of speed.

00:07:29

Yeah. The, what Michael was talking about there with ski camp is a small, small team about 10, um, engineers that are working off base on commercial internet. And we like to call ourselves ski camp and we've been working with the, um, strategic development planning and experimentation group based out of right pat Dayton, Ohio, who is largely, um, the program lead running the, the requirements for our work. And they're asking for this capability and the term that we use to refer to that framework that we're delivering is lightening. And we have that metaphor, like a set of cloud to jet lightning strikes at the speed of, um, supersonic we can get there, right. So, you know, lightning's a lot faster, but if we can get to those lightning speeds, that'd be even better, um, to, to, to give us that capability and that we've been talking about.

00:08:30

All right. So basically, um, I'm going to break down a little bit on the current process just to kind of level set and set the framework for, um, some of the unique challenges that we're still struggling with, um, with, when it comes to this rapid capability to deliver the operational flight program. So, um, obviously we have constraints throughout. I'm just going to draw attention to some of the key constraints that we face, um, having come in, uh, derived code for the, for the air force. Um, I was immediately brought into the understanding of how software development basically works, um, ahead of hardware. And a lot of times, even ahead of the testing. So it'll be not, it won't be that uncommon to have software development teams start writing code from requirements to provide combat capability and ride the algorithms and data crunching to, to make that comment effect happen without even knowing the specific hardware architecture that would be available as far as how much memory is available and how fast is the drive acts is times.

00:09:48

And so we're having to make a lot of assumptions based on past architecture, um, and largely based on what the vendor has provided previously, um, to make these decisions, as far as software goes, there's also the integration and the systems integration lab that is another whole team outside of the software development team. That is your hardware test dance, your software integration, that could be a simulation system or any mix between simulation and hardware. And these are experts of those specific tests systems. They may not be familiar with your OFP, but their job is to test it on the prescribed regression testing that has been established for past releases. And obviously there's manual steps where we will burn source code to a CD to mail to the system integration lab. And just, just, just the same when they're done, they'll turn around and mail that out to the various tests, wings, like the ones we have at Edwards and as a flight test will be scheduled to evaluate that capability on the actual jet itself.

00:11:09

Um, everything ends up being a flight test, and that is, um, costly, as you can imagine, and time intensive, there, there could be delays with mailing this source code between the developer and the integration lab, and then again, delays, mailing it out to Edwards for that flight test and delays for that schedule of that particular debt. And then, um, the last point I want to mention is every release is a full release. There is no single release of a new page in the UI. It is the entire system from flight control systems to stars management systems, navigation systems like Michael was talking about the outset. Everything that's required for that jet is released in one package, one release.

00:12:09

And then again, looking at it from end-to-end the total value stream, right? The organizations that we may be a part of the lines of communication may be separated. They may not have clear planning program, like they're not aligned throughout the whole life cycle of software development, but they have to work together in order for this whole process to come to, to come. So that updates get pushed to the fleet effectively. So that is a very lengthy process to work through all that, a lot of back and forth,

00:12:40

Right? So that's the current state. And obviously you can see there's, there's a challenge just with the current process. There's additional challenges, um, within the organization as a whole, um, navigating those challenges can be extremely difficult because these are career positions that have been established for testing, for design, for accreditation, for flight safe D and their expertise is extremely valuable. And we want to make sure that they feel part of this, but obviously we can't include the several thousand people that our program office has. We wanted to keep this small and limit it to just 10 people, people. So we just decided that what we could do is find a small piece of this, that we could affect a change with. So some aspect of the RFP that we could segregate and isolate and bring away from the rest of the system, the rest of the value stream, so that we could actually demonstrate and prove out and illustrate the lightening framework in a way that, I mean, one from top to bottom could recognize and say, I can see what my role would be to add my role to that. And that was our goal. And really in doubt, drives back to our needs statement, um, of trying to get that dev ops to happen at supersonic speeds.

00:14:17

And then there is a ton of work. There is a ton of, of investment and efforts that's happening across the swag to try to bring agile into it, ideal delivery, um, rewrite and address some of the traditional waterfall ways of operating. But at this scale where we're talking almost 2,500 engineers and 90 different programs, a lot of which they, they don't develop it from the beginning. It's, it's an, it's an original equipment manufacturer. It's a big integrator product that isn't handed off to the swag to own. After that, after the fact, it's a, it's a very tough, it's a tough challenge and, and a, a worthy challenge, but definitely a deeply embedded one that we have to try to work through. And so you were saying earlier, we can't, we realized like, well, this will not be successful if we try to boil the ocean. If we alienate the people who have a lot of these established rules, and we don't find a way of making it so that they see their part in it going forward, when we try to scale, that's one of the biggest challenges that we want to make sure we address.

00:15:27

And then we have to have our, our, our army requirement for, for all slides that are presented. So I wanted to make sure we included this one here, because it is, it is a government presentation after all. So,

00:15:39

Yeah. So yeah, so basically this brings us to the point, um, in order to show, um, that this could actually work. This is a purposeful, um, systematic approach that basically came out of the last three years of trying, working on making this happen. And just like Michael was saying the challenges, the existing processes, we cannot just go around all of that. We have to find a way to work with and, you know, in a way that meets their schedules. So we have time, we have energy and we have passion to move this ball forward. And what we wanted to do was create the isolation necessary to be able to accomplish our goal while still responding to, and, and being responsive to all of the other offices that we know at some point we'll have to be integrated. So the way we did that is to keep the conversation small.

00:16:54

Um, this was something that became very, very important early on like year one, when I was working with this team and we were showing our capabilities, we're showing our progress, we're demonstrating our capabilities to program office management, and they immediately saw that value and wanting to add everything under the sun. So to keep the conversation focused and to keep the ball moving forward, we rapidly came to these four tenants of keeping the conversation about increasing the use of agile. And it's very important to set these tenants properly. What we're saying here is nothing new. None of these tenants are new. What we're saying here is within government working in the air force, working on this project with the rest of the infrastructure and the greater air force and DOD enterprise. If we could keep the conversation about what we're doing to add, to make it more agile, not saying you're not agile, we're just saying you are you.

00:18:06

And we're going to add by, by focusing down hard on agile and making sure everything we do is agile. And with automation, we're not saying all of those system integration labs are suddenly going to be out of business. What we're saying is we are creating automation where everything is manual. So it's an ad. It's like, if we can do more testing, that's always, that's a good thing. If we can show that automation happens faster, it doesn't slow down. The OFP that's even better. And then digital twins to show various different hardware configurations digitally to help improve the software solution. Going back to those hardware architecture standards that allow us to use modern hardware architectures to help improve security, trusted platform through zero trust. Also get at some of the more reliable system architectures for memory, for networking. And then if you roll on top of this, the work we really worked hard on the last year of getting best of industry engineers on contract to work side by side.

00:19:17

What we found out here is they already understand this. This is all like, of course you do that, but what they're doing is they're keeping us on point. So it's very easy for our government employees, our governance and engineers that have been working for 10 years in the current system to fall back on, well, let's just write a manual test. Well, we'll get to automation later or we'll do a waterfall because that's what we know that works with our leadership. So are our corporate partners on this? We're very good at bringing it back to these tenants. Once we said, this is our goal, they held us to it and they were very good about that.

00:20:03

All right. So this is really the summary of where we got to. So if you fast forward to today, and this started in April, we were able to get those contracts, um, built and those best of industry to sit side by side. And we created what we know as the lightning rapid OFP framework. Um, it's truly focused on agile top to bottom. It's using dev ops and automation throughout through integration for testing creditation security documentation. It uses the digital engineering help Kush those known hardware architectures and do multiple parallel system tasks. It allows us to get to container based applications to show that, uh, immunity immutability of containers as they move, and really allows us a lot more. It gives us so many benefits that are proven and ultimately gives us that capability to take a line of code and put it in the jet in 24 hours.

00:21:10

So that this has been, as yours mentioned a three-year process, right? This all started back when I was just as small of a small government led team. And then back in April, we really started our team came on board, uh, from, from our company. But then also there were several other vendors that were all working together as well on this effort. So it wasn't, it wasn't just us. It wasn't just the ski camp. It was a very, it was a very good mixture of integrated teams that came from different experiences in different focus areas. Um, so before that though, leading in right ear and his team had been working on their on-prem infrastructure, I mean, literally MacGyver their, their data center on prem with, with bubblegum and, and, and, and, and rubber bands to keep this thing up and running. So we came on, we came on in April.

00:22:00

Uh, it was a process to get all of our contracts up and up and active finally, to bring us on, to deliver the work. And by the time we came on, we found out, Hey, guess what? You have a June, um, flight test event that you're going to be scheduled against already. So you guys better figure it out and get cracking. What we realized though, is, um, your has this year has this tremendous vision for sending the whole project lightning framework for a reusable and tailorable and portable capability that can be used to support any aircraft system out there, right? Like that's the vision for lightning? How can we change the way that software is truly delivered across the air force to the embedded systems, but we can just start that. So our team came in and we worked with them really closely in the way that we like to approach this as a ticker, a cupcake where you really identify what are the core components to get approved, to get something proof in production, proof of value out there, show people this new capability is possible.

00:23:00

So we, we did it. We did our first design exercise with the whole team. People who had never worked before came together, right? And we decided this, these are the components that are gonna make up. The cupcakes have to eat security controls, have to hit certain functionalities, have to make sure that we hit these other sorts of, um, architectural things as well, documented that capture that out. What would it be? What is the next thing to get to that next level? What's the vision for then cupcakes starts small. You want, then you want to take it to the next level up. You take it to the birthday. This now we're going to go into the next few iterations and start delivering the birthday cake. And then Dior's wedding cake, right? When the big part is happening, everything, that's going to be like the final lightening thing that keeps growing keeps keeps improving, but we started at least setting a vision, a true technical roadmap forward, and we proved it out, right?

00:23:52

We got something that to happen. So we established all the technical baselines for remote access, SSOs, test automation, figuration, the Mandou and the grow group components. And we integrate it with the OFP development team, right? All of this group came together. And then in June, this year, we executed a full proof of concept during a us air force flight test event, right? So we deployed a baseline OFP to an aircraft pod at the beginning of an eighth of an ATO and air tasking order a day. It flew, it came in, we received post-mission data that fed back to the development team who put, who updated the software. And then we were able to deploy updates within the same air tasking order of 24 hour period. In fact, it was less than 12 hours of difference with testing with security validation and with a complete reboot of the system on the hardware, the proof of value was, was demonstrated. And it actually, and it showed that the lightning framework is going to be is truly something that is viable going forward. That was pretty, it was pretty game changing. Considering those, those updates don't happen at that speed at that timeline at all.

00:25:07

Now let's say again, this was just an initial proof. We still have lots of, lots of challenges that we have ahead of us. So

00:25:14

Yeah, we want to get to regular flight tests. We don't want to be waiting for a flight test. So now that we got a demonstrated capability, let's get on a calendar. Let's give the developers something to iterate over time. Let's try it every quarter to get applied, test, keep pushing a swag, to take a look at what we're doing and see where it can fit in. We're already talking to a 10th to see where we can adopt and more of the lightning framework for them. We're talking to several other programs, the three on ninth, that hill has over 90 other projects out there. So we have this capability as a small team to bring them all in and show them, give them one-on-one have them sit down and spend a day in the life of, with us and help spread the knowledge out to the rest of the swags program load.

00:26:03

And some of the things that we recognize going forward as well is for this truly to be successful. We need to make sure that we integrate our team that comes from the DevSecOps world and cloud native world and the other contract with the OEMs and their software development path that that had to production has to merge with light pass to merge with this effort has to be a true partnership, not a fully outsourced and not a complete, like we need to bring the teams and the efforts together. And we also need to continue to mature what we started, right? Like within, within the swag and within other swags and within other software development organizations platform, one ski camp space camp, all these other groups are working together, right? We need mission partners, organizational support funding, an engineering team members. The biggest thing for us success for us in this is building the capacity within the air force to own the path to production.

00:26:58

So we want to make sure that our combined team really works together to help level up the true people who own and will drive this effort in the future. And that's your, and his team, and then the broader swag. So again, as we're looking to the future, I, this is just a nice shot ski campus. Ski camp is a, is a, is a unique organization within the air force in that it is attached to a unit on base, but it is, it is off base. It is 15 minutes off of the hill air force base. It's working that it's in downtown Ogden. It's, it's helping the economic recovery in Ogden. Um, and there's a lot, there's a big community, technical dev sec ops product development, huge tech community. That's, that's growing around this effort and we can't wait to see where it's going. We want to make sure that we open it up and bring and bring other people into the mix too. So all the best of, best of the best can come and help support these problems. And it's a coworking space it's off. It's not a cubicle farm. It isn't a revamped old like feed and like

00:28:05

Manufacturing, like warehouse distributing like warehouse from the 1880s.

00:28:10

Yep. And it's, it's, it's changing the dynamic of what it means to truly build software for the air force and deliver true mission impact for, for the work that people are doing. So with that, we'll transition to questions. Um, really appreciate everybody's time. Uh, we'll be in Q and a, on the, on the slack channels. And can't wait to hear what people think and what people have to say back. Awesome.