What do we talk about when we talk about DevOps? Not technology, even though the concept touches application development and operations within a technical system. It’s not quite a mature practice in some segments, particularly the federal sector.
Instead, we talk about people and processes. DevOps as a practice evolved from agile management, in which the application development process is broken down into multiple components, with deadlines for each. Agile grew from the traditional waterfall practice, where the goal is to hit a final implementation date rather than a series of deadlines leading up to it.
DevOps is the latest iteration of project management, bringing agile practices to bear on both development and operations. It increases the amount of communication and collaboration between the two teams, speeds up the overall process and gets projects to clients faster.
DevOps Leads to Transformation of the Business Process
With DevOps, we’re talking about the complete reimagining of an entire business process workflow for developing, supporting, maintaining and deploying applications. Even the name “DevOps” implies tight integration between the development team and the operations team.
A DevOps workflow makes sure the operations team can build and package infrastructure that the development team can grab as necessary, knowing the proper governance exists so operations doesn’t have to worry about development overstepping or overspending.
The conversation we could be having with customers in the federal space — where DevOps is still a relatively new idea — is about how to leverage the new capabilities in the marketplace; how to figure out which applications or application processes are best qualified to work for an initial move into a DevOps mindset.
Say, for example, your agency is running on a software framework that’s five years old and operating it on hardware that’s 12 years old. What would it look like for you to build out the system as new? Or, say your agency has built an application using the waterfall method; how do you shift future upgrades to the DevOps process?
Those are the kind of conversations we want to have — understanding how projects fit into a DevOps process.
IRS, Air Force, USCIS Are Working on DevOps Programs
Some agencies are already having those conversations and seeing the results. The IRS, owner of some of the oldest technology in government, moved to a DevOps way of working in late 2016. Nearly three years later, their results — as outlined by Kaschit Pandya, IRS Enterprise Operations deputy associate CIO, at an ATARC summit in March — are spectacular:
- Full-integration testing and deployment time has fallen from 500 minutes per project to 30.
- Package build and deployment time has fallen from 27 hours to four.
- Automated testing time decreased from 15 minutes to one millisecond.
- The agency’s ability to deploy releases and upgrades plummeted from 18 weeks to nine minutes.
“These are actual, measurable gains that we have seen come out of our DevOps initiatives,” Pandya said at the event. “We are able to demonstrate those achievements that our teams have come up with and use that as our momentum to continue.”
In recent months, other agencies sought information and training in DevOps, including U.S. Citizenship and Immigration Services; the Office of Personnel Management; and the Air Force, which has turned to the General Services Administration’s Federal Systems Integration and Management Center pilot for assistance.
So, what do we talk about when we talk about DevOps? We talk about joining the conversation and helping interested agencies bring their programs up to speed — and we do it now.