The Air Force Life Cycle Management Center’s (AFLCMC) Detachment 12, which goes by the operational name, “Kessel Run,” is one of the most innovative organizations within the Department of Defense (DoD).
However, while many across the public and private sectors refer to Kessel Run as a “software factory,” that’s not what they consider themselves. Rather, Kessel Run is a military unit that is leveraging a DevSecOps approach to application development to field mission-critical applications that help warfighters accomplish their missions.
And Kessel Run has been incredibly successful in its mission – bringing multiple essential and effective applications to bear for the DoD.
The organization launched two applications – Slapshot and C2IMERA – that were instrumental in the incredibly difficult and challenging evacuation of Kabul. Kessel Run also developed and deployed its namesake Kessel Run All Domain Operations Suite (KRADOS), which, according to Sushil Kumar, the Head of Engineering, OpsC2 at Kessel Run, “…is made up of applications that are primarily built to replace the legacy Theater Battle Management Core System (TBMCS) and Master Air Attack Plan Toolkit (MAAPTK)…[with] something that is more automated and efficient.”
To learn more about this incredibly innovative unit of the United States Air Force, DLT’s ContinuousX Podcast recently sat down with James Edmonds, Project Manager for Kessel Run’s Dagr application.
Click the play button to listen to their conversation, or read the transcript of the podcast below.
Transcript: ContinuousX Podcast (Season 2, Episode 5) with Kessel Run’s James Edmonds
Rick Stewart: Hello and welcome to another ContinuousX episode, where we “Search for X in the SDLC equation”. Our guest for this episode is Jim Edmonds. Jim is the product manager for Kessel Run’s Dagr application, an operational unit intelligence application. We’ll discuss that app in more detail in a subsequent session, but for now, Jim, welcome.
James Edmonds: Thanks, Rick. I appreciate it. Thanks for having me.
Rick Stewart: Alright. Terrific. Well as you know, Kessel Run is considered a significant DevSecOps transformational effort, specifically in the Air Force, but across the DoD, delivering combat capabilities via a software factory, but DevSecOps is not just about tools. Can you explain how Kessel Run sees the difference between DevSecOps and their software factory, and how they coincide?
James Edmonds: That’s a good question, Rick, and there’s definitely a discrepancy. I think when people think of software factories, they think of a place where software developers can come in and do work. You’re given the ability, and the tools, and the facilities to conduct software development. Period. Stop. And that’s what happens there.
DevSecOps is not that. It’s part of that, but it’s a lot more. One of the things I’m really happy with, is that with the Dagr app, we’re part of a DevSecOps unit, not a software factory. And I’ll get what I mean by that.
First of all, Kessel Run is indeed a military unit. And with my 34 years in the military, units have special mission requirements, mission tasking, and roles and responsibilities. So, a unit is really dedicated to a certain kind of mission. A software factory is just where something gets done. A DevSecOps unit is trying to accomplish the mission.
So, what is it trying to do? Well, the “Dev” part of it gets to the software factory aspect of your question. The “Dev” is what I do as a product team. I lead a product team and the design, the development, the testing, all the type of things that make an application user-friendly and usable for the mission that is going to be done. In that aspect, the “Dev” piece is very much a software factory, but then there’s a lot more.
The “Sec” part of it, the security, is something that is vitally important and not necessarily included in a software factory. We at Kessel Run and as an application developer within Dagr, yes, we develop the software, but every step of the way, we’re on a pipeline, a very extensive and complete pipeline, of security scans.
My code, my software goes through five different types of scans, every day, all the time. It identifies any kind of vulnerabilities and fixes them. I’ve assigned a dedicated information assurance team, that accompanies and works with my product team to make sure that all the tasks that we need to do to be compliant with the security of the pipeline are adhered to. I get as many tasks from them as I get from users sometimes, and they’re important ones. You’re developing software. You’re making it secure. You have teams that help you do that within this pipeline.
But the last part is the “Ops”. And as a career airman and now a Naval civilian, I’m really proud of being part of Kessel Run because of the focus on Ops. The mission for this DevSecOps unit, if you will, is command control of airpower on behalf of the United States Air Force and the nation. We build capabilities, we’re winning software, as the commander likes to say, on behalf of Airmen, sailors, soldiers, Marines, anyone that’s employing airpower being applied in a joint fight.
Our apps are focused on supporting those warfighters. Wherever they’re at, or what they’re doing, it’s our job to not only develop tools in a factory, but secure it, make sure it operates on operational networks with no vulnerabilities, and that it meets the mission requirements. Because at the end of the day, it’s about the mission. We’re just a means to accomplishing the mission. We focus very much on addressing that mission, through a secure environment and creating great capability.
I think that’s what’s really different about a DevSecOps unit, as opposed to a software factory, which is a place where you can conduct software development and design.
Michael Fitzurka: I think the factory includes that security hardening though as well. That the pipeline is part of the factory. But again, to your meta point, you need that software factory, and the security hardening is just to support the team. And then it’s the team that’s carrying out the mission and the DevSecOps.
James Edmonds: Absolutely. And a lot of the software factories do in fact, offer you different levels of security. Within ours, we’re not just working at unclassified or military unclassified, NIP and that, but also secret and higher levels. It’s the level of security in addition to providing security.
Rick Stewart: I think, as a product manager, Jim, it’s safe to say, the factory takes away all those automated processes that you would normally have to consider when you’re putting a product together. And when it’s built-in to your processes using your quite capable people, from a product perspective, you can focus on the capabilities and features of the app without regard to … knowing those safeguards are already implanted.
James Edmonds: Absolutely, that’s a good point. I would just even take that a little step further. Because we’re able to do that, the beneficiary is the user. Because knowing that those things are being done while you’re building the software are different from the days of Waterfall development, where a lot of the design/development took place, did OT/DT, and then you would deploy it, and maybe security was an afterthought. So, it was back to the drawing board, it’s back to fixing those types of things.
Having continuous integration, continuous delivery, continuous security scans really helps, at the end of the day, the user, because they know something’s not going to be taken away from them. It’s going to be provided continually. They know it’s secure. They know they can rely on it. And it’s a much better way of doing business. I think they’ve really cracked the nut on that.
Rick Stewart: Well Jim, you’ve really wrapped up our ContinuousX Podcast with that last statement!
Michael Fitzurka: Yeah, you plugged our show very well there!
Rick Stewart: I appreciate it. Thanks to our listeners, stay tuned for more conversation with Jim in subsequent episodes as we “Search for X in the SDLC equation”.
