Containerization, strategy and culture all central to DevSecOps, say federal tech leaders

Imagine building a home, a new foundation, beams and roof, then transferring all the equipment and appliances from the old home into the new structure, room by room. That adjustment will be hard, and some things are unlikely to fit in the new space. You replace those incompatible items with new models, but you still need to learn how they work.

Now imagine instead of moving houses, you’re moving technology to the cloud.

“It’s all about the cultural expectations, and how you tactically set it up for success,” said Jamie Holcombe, chief information officer for the U.S. Patent and Trademark Office, during an ACT-IAC webinar Thursday.

As leaders in the federal DevSecOps space shared their best practices Thursday, Allen Samuel, the General Services Administration’s director of Modernization and Innovation, echoed Holcombe’s comments and said IT folks need to keep perspective that new technology may not seem as exciting to others. As such, GSA has tried to keep old applications running while using APIs to bring out data and functionality in the new technology.

Likewise, Daniel McCune, executive director of Application Management at the Department of Veterans Affairs, said the “lift and shift” model comes with some benefits. For example, he cited VA’s ability to rapidly implement telehealth during the pandemic for veterans thanks to the cloud. But drawbacks exist and as a result, the department began breaking things out into micro services. Leveraging APIs allows them to do a better cloud native kind of application, McCune said.

“Second Gen for us is really containerization,” he said. “Next Gen is containerizing it and then we really want to look at native cloud native applications and preferably in, like a low code, no code pass solution.”

For high speed application development, Samuel said a robust continuous integration and continuous deployment (CI/CD) pipeline is key. It allows projects to better follow a “time to value” metric that GSA uses to determine how long a business requirement will show value in the system.

“If you don’t have that and standardize that and all your developers, you might have anywhere from 50 to 60 different contracts with developers coming in,” he said. “And if you don’t mandate, this is what we’re going to use, and you let them dictate, that’s a recipe for disaster.”

Aside from technology, Holcombe said being strategic about whether agencies are doing the right thing when it comes to DevSecOps is key. As an example, he said agencies should not be concerned with developing custom code when the entire commercial environment can be adapted. Keeping bespoke systems around for the long term is more difficult this way.

“Who in the world would build a new payroll system? And yet, the Department of Defense has their own payroll – that’s ridiculous! There’s so many good payroll systems out there, right?” he said. “So we have a chance to do the right thing, and only develop code for core differentiation. Whatever your mission is, that’s OK but if it exists elsewhere, use it as a service, to doing the right things, the strategy is go to the commercial marketplace where it’s better, cheaper and faster, it will always be that way.”

Likewise, McCune said VA has shifted its focus from project management to product management. Traditionally, the agency has focused on scope, schedule, and cost with a habit of “throwing the product over the wall between the dev team and the ops team” which he said does not work well.

“We’ve been working on a product line management transformation, which is really a cradle to grave support and accountability for products and applications. We build on our agile DevOps practices and really build one team that owns the entire lifecycle of product,” McCune said. “We then grouped these products into product lines, and that allows us to, to really work directly with the customer on all the software that that they care about.”

When asked if any playbooks exist which enable a more systematic approach to modernization efforts and development, Samuel said these were central to his team’s work. Everything they do should helping either internal GSA IT or the federal government as a whole, hence why their playbooks are available at Tech.GSA.gov.

The playbooks answer questions such as, “What do you have? What do you need versus what you have, right? And then, what we did with, initially before we started, our modernization strategy is we mapped all our current applications to business capabilities, then we went back to the business, ‘Are you still using this capability? Is this the way you do it?’” he said.

If something is no longer needed or does not need to be modernized further, the findings will be the a playbook as well.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.