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 IT leaders 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 don’t need 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. “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.”
DIG DEEPER: Break the biggest myths on platform engineering.
Why You Need 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.
However, even within domains, software can serve vastly different purposes. For instance, human resources might seek to develop applications that approve timesheets or security clearances.
Managing many software factories can pose challenges, and organizations 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 can help 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.”
UP NEXT: Bake security into platform engineering.
Don’t Forget How Software Factories Affect People
One thing that organizations learn through implementing software factories is that 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.”
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.
It’s also important not to overlook the impact on the people working with software factories, Reitzig adds. 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,” he says. “If you’re asking people to do their day jobs 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: Organizations should assess their maturity in terms of the three core elements of software factories, 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.
