So Close and Yet so FAR: DevOps and Federal Regulations

Jennifer Hoover, DevOps Program Manager at TSA, addresses MeriTalk and GAI's Federal Focus: The Cloud Generation event on July 12, 2017, at the Newseum in Washington, D.C. (Photo: David Keith for MeriTalk)

The Federal Acquisition Regulation, the guidelines dictating how Federal agencies procure goods and services, is not flexible enough to keep pace with modernizing agencies, according to Jennifer Hoover, DevOps program manager for the Transportation Security Administration.

DevOps, which refers to software development and IT operations, prompts agencies to purchase services in the way of software and cloud computing. However, Hoover said the blanket regulations need to be adjusted. Hoover, who ran DevOps integration at U.S. Customs and Border Protection before joining TSA, said restrictive language prevented her team from working with an organization that could have helped them with agile services.

“One of the big things we ran into was language in the contract because we had to stick to very rigid language. We found some really amazing people. The verbiage required by procurement really narrowed down what we could say,” Hoover said at the Federal Focus: The Cloud Generation event presented by Government Acquisitions Inc. and produced by MeriTalk on July 12. “I don’t think the FAR is quite as flexible. I think we really need to take a look at the FAR and make it more useful. I think it needs to be completely revamped for the IT world we live in today.”

On the other hand, Chad Sheridan, chief information officer of the U.S. Department of Agriculture’s Risk Management Agency, said that the FAR, while convoluted, is flexible enough. He said agencies can succeed by sifting through the regulations and forging their path by paying close attention to language. For example, sometimes agencies’ plans hinge on what the FAR “suggests” rather than “requires.”

“Too many program managers are unwilling to buck up against” established practice, Sheridan said. “I would love to see the FAR revamped. But let’s deal with the reality. The reality is that’s probably a decade or longer.”

Sean Jennings said DevOps forces teams to come together. (Photo: David Keith for MeriTalk)

DevOps encompasses more than just software development, according to Hoover. She said the true definition is much broader, and includes the circle of tools people use, the latest technology, the process of acquiring services, and the people operating the systems.

“There are all kids of definitions for DevOps. There is automation, but there is so much more than just that. There’s the culture and process piece that needs to come along with that,” Hoover said. “DevOps is really a misnomer. DevOps really should include all the business lines as well. Inherently, DevOps is about the people. It’s about the culture. Somewhere in the middle of that is DevOps. IT requires education and communication throughout all agencies to define that.”

Sean Jennings, co-founder and senior vice president of Solutions Architecture for Virtustream, said one of the most subtle and important aspects of DevOps is the teams it forces to come together. He said that people grew accustomed to “glass house architects,” who built a tool that was what the customer asked for but not what they really needed. DevOps connects customers with the engineers who built the tools they are having trouble with in addition to service relations staff.

He said DevOps accelerates the model of incorporating software solutions because it involves incremental changes, rather than sweeping ones.

“Engineers that used to be isolated now become part of that continuous flow. When they go home for the weekend, engineers are just as likely to get a call as customer service people,” Jennings said. “Waiting nine months to find out that there was bad communication is just a recipe for disaster. And unfortunately it’s been the case for the past 30 years.”

Most members of the panel agreed that accepting the culture change is the most crucial aspect of embracing DevOps. Jennings compared the shifting mind-set to the San Andreas fault line, where people who understand DevOps and people who are comfortable with the traditional model grind against one another.

To address this cultural struggle at USDA, Sheridan walks the halls, meets with colleagues, sends weekly emails, and holds all-hands meetings.

“My job is to constantly broadcast and walk the hallways and talk about the ‘why.’ My job is to continuously communicate the ‘why,’ ” Sheridan said. “When I didn’t do that, we got off the rails. I realized I needed to say it 10 times for it to sink in.”

Similarly, Hoover hosts brown bag lunches, lightning talks, and guest speakers. She stressed the importance of communicating in a personal way with her body of 500 Federal officials, which is smaller than the group of 2,000 developers she dealt with at Customs and Border Protection.

“I’m looking at different avenues to deliver this information. For the most part, the people that I have connected with over time are really willing to share their story and share their wins and their losses,” Hoover said. “I’m very excited about doing empathetic training. DevOps is a very human thing. Developers are doing development. Operations officers don’t know the whole process that developers go through. You want them to understand each other.”

Recent