This content is provided by Red Hat and Carahsoft.

Warfare isn’t just about who can field the biggest bomb, fastest plane or strongest tank anymore. It’s about who can field any particular capability the fastest. That means traditional development processes like waterfall just don’t cut it anymore. That’s why Lockheed Martin reached out to Red Hat for help updating the processes and culture around application development for the F-22 Raptor fighter jet.

And it has worked. Jason Corey, senior director for emerging technologies at Red Hat, said the development process is down from years to a matter of months and even days. Lockheed Martin also saw its ability to forecast to the client improve by 40%, and it’s delivering new communications capabilities three years ahead of schedule.

“It was really about doing two things,” Corey said. “One was leveraging a lot of the newer cloud-native microservice-based technologies. And then combining that with a new way of looking at modern team constructs. So leveraging agile principles and methodologies in a combination with a lot of new processes, like test driven design, domain design, that is allowing them to develop and iterate software to the aircraft much faster.”

Corey said Lockheed originally brought Red Hat in because it was interested in the OpenShift Container Platform for software development. Lockheed had very technical ideas on what tools it needed at first, but technological solutions are only half of what Red Hat does; the other half is culture.

“One of the unique things I think that’s happened over the last three years is people have also recognized that in order to modernize any IT platform, whether it’s on an aircraft or in a data center, you really have to look at modernizing not only the technology stack, but you have to modernize your team constructs, how your teams work together. You have to also modernize your processes. And I think that was probably the most enlightening thing for them,” Corey said.

Before Red Hat got involved, Corey said Lockheed’s teams were organized in a traditional software development structure, with Scrum teams working on different features.

When Red Hat’s Open Innovation Lab team comes in, it doesn’t just teach employees how to use the new software. It teaches them how to embrace open principles like transparency, meritocracy and collaboration. So the first thing that team did at Lockheed was to break up into working groups and establish what they call the “dojo,” an open space for collaboration and mentorship.

This close proximity and open space also helps developers get more useful feedback on the application and integrate it more quickly.

But while Red Hat brings the people together to teach open principles, it’s also breaking up the applications into different containers to be worked on independently, so developers aren’t relying on other teams to work on their particular feature of the application.

“So what that ends up giving you is much smaller, independent services that you don’t have to wait on others to create,” Corey said. “And then you can also reuse a lot of those services. So if you need to do an upgrade of your applications much faster, if you need a search service for another application that you built, you can actually reuse that.”

That also allows security to be integrated during development, which Corey said is a big improvement over traditional methods. For one thing, bugs in the software can be identified while it’s going through the pipeline, rather than after the application goes to production.

It also saves time on accreditation when the platform itself is accredited.

“As an example, I’m thinking of an intelligence customer where there was 507 configurations that would have needed to be met by a system to get an accreditation, whereas now with things like cloud provider platform, or even a platform-as-a-service, like OpenShift, you can reduce that down to around 70 checks that you need to make, because you already know that the platform has been accredited to a certain level,” Corey said.

Corey said this is part of a wider trend he’s seeing across contractors and even some federal agencies, where they’re starting to become more receptive to the ideas of open principles, DevSecOps and agile development.

“There does appear to be a tide change in terms of the government really trying to be more innovative and trying to do things faster. Because I think they recognize that a lot of people think if you do things fast, it actually increases your risk,” Corey said. “What I think people are finding is that it’s actually the opposite, the faster you go and the more automated you make things, the more secure you are. And I think, even if you look at what kind of acquisition reform the government is seeing, that same type of thing is starting to hold true as well.”

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.