On DevOps: A Cloud-Native Government—What it Takes

Like commercial sectors, government bodies want to solve the DevOps ostomachion. However, DevOps isn’t hardly an accepted practice in government, and a recent survey sheds light on why. The fact is, government IT leaders can do something about it, and this post sums up those points, which I also wrote about in a longer article on FierceDevOps.com.

A few months back, MeriTalk published “The Agile Advantage: Can DevOps Move Cloud to the Fast Lane?” Of the 152 U.S Federal IT managers who responded, 66% believe DevOps will help agencies shift to the cloud faster. In addition, 63% believe DevOps will speed app delivery and migration, 68% see DevOps as a viable path to improve collaboration between development, security, and operations, and 62% anticipate faster testing. Yet, only 5% say their agency has fully deployed the DevOps model. Hmmm. Every one of those 60-something-percent ones can actually lower IT costs, which is like a primary government project motivator, right?

The report goes on to explain that there are a number of things getting in the way—the top ones are complexity, fear of change, inflexible practices, and a lack of clear strategy. It also mentions problems like process and policy changes, cultural changes, and organizational changes. These things must be addressed for DevOps to have a chance to re-conceive a Cloud-Native government.

Culture, process, orgs—these are mostly meatware problems right?

Changes Internally and Externally—The Meatware Problem

Of course, many think of government as a bunch of red tape. Understandably, there is often quite a burdensome change management process—accounting for failure conditions, security re-certification, over-documentation, retesting unnecessary things, stringent waterfalls, etc. Yet, the General Services Administration’s 18F group reduced the time for changes from 9-14 months to just two or three days. They are actually running a Cloud Foundry instance on AWS and only have to change the app, not the whole stack—just testing what was cf pushed.

If we ask how this is possible, we need to dig into the meatware side of the traditional process. We have asked our government project members to over analyze, prepare verbose documents, and follow a process black hole. The meat is us—the ware is our neural programming. As noted above, there is an admitted fear of change and inflexibility not to mention cultural issues. To change these things, well, we need to change. Start with this. Ask your teams—what if we could actually publish code every day? How do we get to smaller batches of requirements, design, and deployed code? How do we all work together to cut a 3 month deploy cycle down to three days? How do we reinvent the things that we all find burdensome? Where can we iterate intelligently to get mutually exclusive portions of apps out the door? Team, why would we even consider doing this—what is our vision?

In addition to internal teams, contractors can sometimes be a dirty word in government IT circles, and both need to be “reprogrammed.” While it isn’t the only way it’s done, the generali characterization of contractors is that they do one deploy a year (hopefully!) based on a 300 page spec. In addition, it is very difficult to shift projects from big contract firms to smaller and more innovative firms who can change things up. The traditional, waterfall-based SOWs just don’t apply in an agile environment, where you need to discover as you go and change based on new information. It’s actually not hard to scope in agile terms, it is just different.

Still, this issue is compounded by the fact that decades of outsourcing to contractors has created a skills, process, tools, and culture gap within the IT group. Importantly, government IT leadership needs to mandate the integration of groups that make DevOps happen, backed with a clear vision and all the culture change practices that apply. Now, I may be preaching to the choir—a recent Gartner global survey showed that 40% percent of government CIOs said they need to focus more on developing and communicating their vision and also do more coaching.

Again, there is a deeper dive of this content over in my FierceDevOps column this month.

But, let me leave you with one thought—we, in the “enterprise,” are busy roaming the halls of capitalism and don’t often get the chance to positively affect, let alone simply help and improve the lives of, everyone on a daily basis. Government has that chance. When you speak with most people who are passionate about using IT to improve government, they want to do it because they are morally motivated to help society, and that is genuinely interesting. motivating, and valuable.