How to Build a Software Factory

A Consistent Experience Makes for More Sophisticated Software

Software development evolved from customized to standardized builds, then to a standardized structure for source code in the past two decades. As a result, the artisanal approach to development — in which two people execute the same function differently, or one developer solves the same problem different ways on different occasions — has had to give way, says Christopher Yates, principal chief architect at Red Hat.

“The factory is the machinery you build that allows you to create sophisticated things in a repeatable way,” Yates says.

Similarly, the artisanal way of learning — with a master guiding the journeymen, guiding the apprentices — has proved outdated.

“That’s a human-focused and linear process. You can only teach so many people at a time,” Yates says. “Within the software factory, you can set up guide rails and best practices that affect the way others behave without the need for that knowledge transfer from one individual to another.”

Reitzig highlights three core components of a software factory:

• Lean and agile practices, which extend beyond software development to encompass organizational design, workflows and funding decisions
• Infrastructure that’s cloud-native and containerized, which lets agencies reap the efficiency and scalability benefits of a modern architecture
• Process automation, which covers the key phase of the development lifecycle — from quality scans to security tests to deployment — as well as infrastructure management

The common standards and processes in software factories are like restaurant chains that have a similar menu and atmosphere but differences in their physical locations.

“It’s a consistent experience. People know what they’re going to get, and it’s cost-effective,” Reitzig says.

LEARN MORE: Defense agencies are turning to platform engineering.

Automation’s Role in Securing the Software Factory

Of the three components, process automation is likely to present the biggest hurdle. Many organizations are happy to implement continuous integration and stop there, but agencies should strive to go further, Reitzig says.

One example is automating underlying infrastructure configuration. If developers don’t have to set up testing or production environments before deploying code, they get a lot of time back, and they don’t have to wait for resources to become available.

Another is improving security. Though there’s value in continuous integration automatically checking in, reviewing and integrating code, stopping there can introduce vulnerabilities.

“This is a system for moving defects into production faster because configuration and testing are still done manually,” Reitzig says. “It takes too long, it’s error-prone, and the rework is a tax on productivity.”

Reitzig notes the benefits of security automation practices, such as static and dynamic application security testing. Additionally, interactive application security testing monitors runtime behavior, Infrastructure as Code scanning looks for cloud configuration risks, and software composition analysis evaluates dependencies among third-party components.

These best practices, coupled with code quality scanning and unit test automation, help highlight security issues before code goes into production.

“Automation shortens timelines and improves quality,” Reitzig says.

The technology also lowers costs, and another manufacturing analogy helps explain why.

“Every time a product needs to be retrofitted, it takes time and money to fix it. If you ship a product and have to recall it, that’s extremely expensive,” Reitzig says. “Software is the same, but unfortunately people don’t always think of it that way.”

EXPLORE: Cloud vendors must consider FedRAMP’s identity and authentication controls.

Different Software Factories for Different Domains

While the software factory standardizes much of the development process, it’s not monolithic.

“You need different factories to segregate domains, regulations, geographic regions and the culture of what’s acceptable where,” Yates says.

To that end, Red Hat is working with DOD to distribute software factories using its OpenShift platform.

DOD operates hospitals and telecommunications networks, both of which have differing needs and regulatory environments. Even within domains, software can serve vastly different purposes. For instance, human resources might seek to develop applications that approve timesheets or national security clearances.

MORE FROM FEDTECH: Follow these four steps to modernizing agency applications.

Managing so many software factories can pose challenges, and agencies would be wise to identify redundancies, Reitzig says. And because the goal of software factories is to create a framework for repeatable processes, those used infrequently or that fail to achieve goals for consistency may be good candidates for retirement.

Still, having multiple software factories remains beneficial. Beyond supporting specific domains, they help to foster smaller-scale innovation that may prove more sustainable in the long term.

“If you’re spending $20 billion on a program, there’s more demand to see success sooner,” Yates says. “If you start smaller, you can snowball to success, and if you fail, it’s much smaller and easier to recover from.”

Don’t Forget How Software Factories Affect People

One thing that organizations learn through implementing software factories is that the constraints of common standards and processes aren’t necessarily limitations, Yates says.

Instead of programming first and certifying later, development teams can take a more focused approach. Yates likens it to the difference between choosing among three ice cream flavors or three dozen.

“If you have unlimited options, it can be hard to come to a conclusion,” he says. “Constraint allows acceleration of innovation; it can help you be more creative.”

UP NEXT: Government’s AI plans are coming into focus.

Additionally, the automation of platform engineering enables more efficiency, as development teams spend far less time managing infrastructure and more time on the type of work they enjoy. Among the benefits that DOD sees from software factories, it’s important not to overlook the impact on the people working within them, Reitzig says.

Leadership must convince employees with decades of experience that they need to do things differently. That’s a tall order, especially if a software factory is automating quality assurance or other complex tasks that a staffer was specifically hired to perform.

“You have to respect and focus on the people,” Reitzig says. “If you’re asking people to do their day job and then also try to do something new, they’ll come up with all sorts of creative ways to throw sand in the gears.”

The best way to get started is in steps: Agencies should assess their maturity in terms of the three core elements of a software factory, then develop a roadmap that takes into consideration the applications and people they have in place.

“You have to manage the migration to a software factory very purposefully,” Reitzig says.