DevOps goes to Washington: How DevOps in government works
From procurement to compliance and security, the federal government will face enormous challenges as it brings DevOps on board. Here's how what to expect.
As departments and agencies make the move to DevOps, the United States federal government faces a unique set of challenges. Traditionally slow-moving, today's governmental bodies have to find a way to handle changing mandates, increased cloud use and ever-more-demanding constituents. DevOps adoption is a struggle in most large organizations; DevOps in government agencies will face those hurdles, as well as a number of unique problems.
Procurement hurdles
For starters, procurement has always been a challenge for public sector entities, said David Egts, chief technologist and director of the North America public sector at Red Hat. Governments buy big-ticket weapons systems and conduct multiyear IT initiatives they expect to last for decades, he said. That leads to a culture where it's OK to spend extra time to get things perfect, or, to put it another way, it means waterfall rules. It means projects too big to fail.
The issue, Egts said, is the concept of a minimum viable product (MVP) is new to a lot of agencies. "But it's encouraging for me to see a lot of agencies being very progressive in this standpoint of doing Agile [Blanket Purchase Agreements]," he said.
Competing for Agile Blanket Purchase Agreements, though, requires a submitted demo that develops into a minimum viable product along with a written response.
Stringent security and compliance
It's no surprise rigorous and widespread security and compliance requirements will create plenty of obstacles when it comes to DevOps in the government sector. The federal government operates IT systems under stringent security mandates, like the Federal Information Systems Management Act, a set of government-wide cybersecurity practices, and Federal Risk and Authorization Management Program, a standardized approach to cloud security. Federal IT projects must also pass another level of compliance known as a change control board (CCB). A CCB brings together agency-wide management to approve software changes.
A typical applications team may have to navigate six or seven other contractors in order to be able to deploy their application and get it into production.
Peter O' Donoghuevice president of application services at Unisys
The good news is the Modernizing Government Technology Act and the Data Center Optimization Initiative mandates will move more agencies to the cloud. The Modernizing Government Technology Act, in particular, could prove a powerful force for digital transformation in the public sector because it provides funding and an incentive for agencies to migrate to the cloud. As cloud service providers (CSPs) replace agency data centers, security compliance in the cloud may prove easier since the major cloud providers have new levels of it in place for their federal customers. These CSPs also have security specialists on staff, which could end up an unexpected -- and useful -- side benefit to government agencies unable to pay the high salaries security pros demand today.
Too many third-party cooks
Sometimes there really can be too much of a good thing. The long-established federal systems development cycle, based on third-party verifications and multiple hand-offs, is an impediment to federal DevOps, warned Peter O' Donoghue, vice president of application services at Unisys. At any given moment, a federal agency might have multiple contractors doing development, quality assurance, security, IT Ops and security testing, all with their own contracts and procurement strategies, O'Donoghue explained. In other words, there are too many cooks in the kitchen.
"A typical applications team may have to navigate six or seven other contractors in order to be able to deploy their application and get it into production," O' Donoghue said. "Each of those contracting teams competes for each other's work."
He recommended a reimagined federal development lifecycle that simplifies the end-to-end lifecycle, reduces hand-offs and moves to a trust, but verify model. He described that model heavily using automation to manage builds, deployments, regression testing and security scanning. Such an approach lets DevOps in government agencies actually achieve better, cheaper, faster and more secure.
Lessons for the private sector
What can nongovernmental agencies learn from a federal DevOps effort? A lot, particularly when it comes to technology.
"When I talk to my government counterparts, they know what [Security Content Automation Protocol] is, and they use SCAP," Egts said. "They know what a [Defense Information Systems Agency Security Technical Implementation Guide] is, and they know how to lock down systems and automate that. Or most of them do. On the commercial side, they don't know that as much. And a lot of times, they know they want to automate their security as much as possible."
Federal agencies play at a larger technology scale than most businesses, Egts said. The scope is much broader. Agencies have concerns beyond those of most commercial organizations, especially security, privacy and Section 508 accessibility, O'Donoghue said. And those concerns are all driven from government mandates. Businesses in financial services, insurance and healthcare that work with personally identifiable information and personal health information should look at DevOps in government agencies, because they have even greater security hurdles to overcome.
The private sector certainly leads the way in DevOps adoption, but how the government handles its unique challenges is useful information for every DevOps practitioner.
