Overcoming Inertia At Scale – Moving Government to DevSecOps by Amelie Koran

Amelie Koran is a senior technology advocate at Splunk and wants public sector technologists to know how they can move their governments to DevSecOps.

In the session “Overcoming Inertia At Scale—Moving Government to DevSecOps,” she gives advice on how to pick projects and use metrics to incentivize employees and make a successful transition to DevSecOps.

Before we figure out how to shift the government processes to DevSecOps, we must understand the significant differences between the private and public sectors. 

Public sector systems have different funding processes and often operate under stricter laws and regulations from private sector systems. For one thing, there is a larger amount of legacy services and technologies than in the private sector. Businesses need to aggressively modernize and possibly consolidate their legacy systems in order to stay competitive, whereas governments don’t necessarily have this pressure. Additionally, in the public sector, everyone is a potential customer and user. This means a government agency has a myriad of personas they have to support and develop for, and there are known unknowns due to this situation.

The Problems

These differences can make overcoming DevSecOps inertia look like a lot of thankless work. There are issues such as:

• Lots of technical, policy, and process debt. Many legacy systems contain built-up debt to overcome. Regulation also means processes can be slow to change.
• Complex politics and money relationships. Funding has much more oversight and process around it in government. Politics exists in the purest form of the word in the private sector, and is more based on personalities.
• A lack of operational support. Support is more important than modernization. If you build it, you will need the staff to maintain it, and public sector staff often wear “many hats” in the execution of their duties.
• Contractual workforce. Much of the public sector workforce has switched to primarily contractual in the last 20 years, with federal employees primarily focusing on project management rather than development and operations.

Risk Factors

Government technology work is inherently risky, and exists in a risk adverse environment.

It requires a significant amount of organizational cultural change. We need to support government contractors and their leads in order to succeed in introducing and continuing DevSecOps practices. As a leader, some of your key work is to get people involved, and getting employees to move from “talking about it” to “doing it.” 

At the same time, we need to get buy-in from leadership, business/mission areas, support staff, other public sector partners, and even external oversight and funding authorities. Buy-in is key to avoid “cost center” labels during discussions, instead aligning these efforts along CapEx and OpEx expenditure discussions. We must help federal agency workers see that technology is an enabler of public value.

Moving from Inertia

To overcome these challenges and risks, we have to follow Newton’s First Law, which states that an object in motion stays in motion. This means some of the most critical steps must be followed up by a lightweight process to keep everybody rolling toward DevSecOps. Get the right people involved upfront with a consistent schedule for your initiative. 

You also need to make your measurements meaningful. To incentivize people to succeed, you need measurements that point to that success and ways that they can achieve it. Make them realistic and understandable.

Too many measurements will be like trying to drink from a firehose for your employees and contractors: they won’t be able to take it all in, and will likely be overwhelmed by the flow of data. Several garden hoses on a fire could be just as effective as a firehose, and allow for easier consumption and management of the data and information to be consumed.

Pick your sources of data by how useful they are and compare them to get an idea of their quality. Don’t let the magnitude of the measurements overwhelm you. Remember that moving from 0 to 1 is as critical as moving from 1 to 100. Once the process is moving forward, it’s a lot easier to keep it rolling than getting it started. The hardest work is the start and establishment and methods of measure, especially if they didn’t formally exist prior.

How to Successfully Start Your Transition to DevSecOps

Critical to starting an effort to overcome organizational inertia with modernization and transformation activities is to pick the right projects and people. Look for projects that are well-documented and are properly resourced. Poorly resourced, managed and designed projects with very little funding are set up for failure no matter what initiative you choose, it is important to review the whole strategy for an activity and perform a gap analysis in order to identify chances for success. You will also want to select ones that are as apolitical as possible so they can be resilient to administration changes and divisive politics that typically accompany projects in any level of the public sector.

Conclusion

The work may seem tough, at times overwhelming and thankless, but, like a boulder, automobile or any seemingly large and immovable object, once it starts rolling it is easier to keep it rolling and picking up speed and velocity. Don’t let any vanity or ego get in the way as it serves no appreciable purpose. Select projects that are well-documented and have the resources to support your efforts. Find people with good ideas for positive change, and support them. With perseverance and good incentives, you can make a difference in your government.

This post was written by Mark Henke. Mark has spent over 10 years architecting systems that talk to other systems, doing DevOps before it was cool, and matching software to its business function. Every developer is a leader of something on their team, and he wants to help them see that.

Photo by Ross Findon