The term “software factory” is a hot new buzzword. It’s no wonder why. In its DevSecOps reference guide, the DoD points out:
“Legacy software acquisition and development practices in the DoD do not provide the agility to deploy new software ‘at the speed of operations.’ In addition, security is often an afterthought, not built in from the beginning of the lifecycle of the application and underlying infrastructure.”
We agree. DevSecOps has been defined as the answer to these historic issues, and software factories are the solutions—digital and otherwise—agencies are putting in place to apply DevSecOps best practices.
Software factories are the future. We could argue they’re the present, with government agencies still working on catching up.
A software factory is essentially a structured collection of related software assets that aid in producing software applications or components and follow specific, repeatable processes throughout the lifecycle.
Under this broad definition, any software development team, agency, or operation could be considered a software factor. At Geocent, we look at it a little more holistically. A successful software factory, like a manufacturing factory, involves everything that supports the process of taking raw material and turning it into something—in our case that means secure, working software.
The raw materials that go into a software factory can include:
Think about all the things that go into a software system and how they come together. A software factory is set up to make that process from input to output as efficient, standardized, and repeatable as possible.
Picture a factory, with a conveyor belt moving products through the assembly line. There are people (and robots) working, each of whom knows their role in building the product and performing repeatable tasks to best practice specs. These builders have identified the best, most efficient way to produce their product. The entire factory system makes it happen.
Now let’s look at the process of building software. Let’s repeat that...the process...of building software. The efficiency and effectiveness of a software factory come down to having repeatable processes.
When “raw materials” (let's call user stories our raw materials) come into the software factory, there should be a digital assembly line each story travels through. At one station, git branches are created—that one is automated. At another station we have development—a talented human handles this part. And at yet other stations, we have automated testing, bug reporting and fixes, continuous integration/deployment (CI/CD), and more.
At our software factory, because it uses DevSecOps, security is paramount. At every step of the process—each station in our metaphor—security is a prerequisite. The user story can’t move along in the process until it passes certain security checks.
To build an effective software factory, you must have the people and processes in place to make it happen.
People
Software factories are built with automation in mind, but building software is still a very human endeavor. Humans plan, build, and evaluate the software, and in most cases, humans are the end-users. So while software factories seem like they’re built solely on processes and automation, we still have to take into account the human element.
For software factories to succeed, every member of the team has to buy in and be committed to following the processes. You’re only as strong as your weakest link.
How do you get buy-in?
Make the processes beneficial for the people doing the work. Make their jobs easier. Show them how the framework benefits them.
It’s also important to have leadership for these principles at the top. If the entire agency isn’t committed to making a software factory work, it’s not going to work and the benefits will be hazy. There’s a cultural shift that has to happen to put the team in a DevSecOps state of mind.
Do we have everything about DevSecOps perfected at Geocent? No. But what we have is commitment. The entire team is completely bought into using processes and automation to build secure, quality software.
Processes
In a software factory, there should be a process for just about everything. There’s a process for gathering requirements, pulling work, creating branches, code reviews, merging, testing, deploying, fixing bugs, and everything else along the way.
Some of the processes will be manual. For example, how and when work is moved through the kanban board. But many of the processes will be automated, especially in testing, security, integration, and deployment.
At Geocent, we have a codebase of automations. There’s no need to reinvent the wheel when an automated wheel is already in the team repository. With this mindset, we’re never starting from scratch. We use proven, tested code and automation whenever possible.
When you have established processes, you should be able to take individual people out of the factory and still have it run smoothly. Having this standardized workflow enables teams to efficiently share resources depending on mission priorities.
We’ve all been part of a team where things get too reliant on an individual—that person becomes a crutch. What if they get hit by a bus? With a properly implemented software factory, the processes stay in place and software keeps getting built, even as you mourn that individual’s—we’ll say they’re in a coma.
DevSecOps is usually the framework around which software factories are built. Many of the key components of a software factory—processes, automation, security—are DevSecOps principles in action. So a software factory is what’s being built, and DevSecOps is the framework with the tools to build it.
Security First
The Sec part of DevSecOps is incredibly important for government software factories. Security has to be a priority, embedded in every step of the process, not an afterthought.
It’s more efficient to build and deploy software without considerations for security. But your software absolutely has to be secure, so that’s not possible (or smart). Instead, we focus on leveraging automation to integrate security without impeding the productivity of the development team in the long run.
At Geocent, we have layered security, with checkpoints at every step of the process. We start at the beginning. A platform doesn’t move out even to a low-level development environment until it has passed security checks. Everything in our code is containerized and we have penetration testing on every build and deployment.
We walk the walk when it comes to security and is confident in the systems we build. And thanks to processes and automation, it doesn’t come at the expense of speed and quality.
The Fastest Way to Build a Software Factory
Building a software factory can, again, be compared to building a manufacturing factory. It takes time. But when you work with someone like Geocent, experienced in building software factories, you aren’t starting from scratch.
When we help an agency build a software factory, we come into the project with—metaphorically—the building, the end-to-end conveyor belt system, and machines ready to do work. In other words, we bring the framework, processes, and people to set up the software factory.
From there, we just have to configure the factory. In manufacturing, that would be programming the machines and workflows. In a software factory, it’s setting up the specifics around the exact environment we need to do the work. Each software factory is a little bit different.
We can deliver fast because we come to the table with processes, automation, and tried-and-true codebases. You get to that first deployment—even if it’s just a hello-world application—fast, with confidence in security.
Build it Before They Come
Another big way a software factory is like a manufacturing factory is that both should be built before products start moving through the line.
A lot of agencies try to build the software factory as they’re trying to build software with that factory. That’s like watching your product, let’s say beer, ferment on the line while you’re still building the bottling station.
When you build the factory as you’re building a platform, you ingrain bad habits and set the wrong culture. You set anti-patterns by doing what’s convenient instead of doing them right. And you likely have the wrong people in the wrong roles. You need a bricklayer to build the factory, but what does that person do once the factory is built? The skills required to set up a software factory are much different from the skills required to work in one.
MCBOSS
The Marine Corps Business Operations Support Services, or MCBOSS, is a revolutionary platform that offers a cloud-enabled environment that allows users to access and build applications for the Marine Corps. MCBOSS was the first DevSecOps capability developed by OASIS and reduced development timelines, automated testing and deployment, and improved security.
MCBOSS is a fully operational software factory and is running approved applications, including:
Software Factory 101: The Modern Government Factory