How Government Can Accelerate the Adoption of DevOps (Contributed)

States and localities are saddled with legacy tech debt, but the problem can be fixed by delivering the variety, quality and timeliness of public services citizens expect, using this transformational, collaborative methodology.

by / June 6, 2019

[Editor’s note: This article is the second in a series on the growth of DevOps as a more impactful, collaborative IT development model that state and local governments can adopt to deliver services with both speed and quality.]

Citizens’ expectations of government services are changing — and fast. Shaped by their experiences as consumers — in which technology enables them to receive information and support in near real time — the public is increasingly looking for similar speed, convenience, choice, and personalization from their state and local government services.

DevOps, an efficient IT collaboration model that brings together previously separate development and operations teams, can offer government organizations the agility they need to meet emerging service expectations. 

Tackling Legacy Technical Debt

DevOps can help reduce technical debt. However, many government departments are still operating and spending money on aging IT systems, including some from the 1970s or earlier. Many of these systems are so old that they can be difficult — if not impossible — to upgrade or align to modern practices and regulations. Indeed, it’s not uncommon for IT resources to be channeled into repairing or patching legacy systems just to keep them in service. 

Building DevOps organizations and cultures helps to eliminate technical debt by engaging relevant stakeholders in the design and delivery of software development projects throughout their life cycle, ensuring their ongoing relevance and use. In other words, the internal alignment fostered by DevOps can enable software teams to reduce time to market and increase business value by developing products and services designed to evolve with users’ needs.

The Four Keys to Successful Implementation

Given its differences to current IT development practices, DevOps isn’t something that can be implemented overnight: it’s a continuously evolving method for making process changes that improve day-to-day work.  

Here are four tips to successfully implement DevOps practices and cultures within your agency:

    1. Choose your initial applications wisely.

Attempting to adopt DevOps across an organization quickly can lead to unrealistic expectations and disappointment. It’s best to start small. Ideally, begin with a new or existing application that has no or low amounts of technical debt to build momentum. You can essentially use the work being done on that application as your starting point to build and test out your DevOps practice. If you choose an existing application, look for ones with strong documentation for code and configurations. Avoid applications that have overly tight architectures or are unnecessarily complex. 

By starting with a blank slate — or close to it — you’ll avoid frustrations. When stakeholders see the positive results, over time they’ll start to believe in the cause, help dismantle legacy silos, and pave the way for cultural change.

    2. Create a cross-functional team for each application.

DevOps is more about people than it is about software. One of the core benefits of DevOps is that it brings previously siloed teams together, resulting in better collaboration, engagement and expedited results. The individuals comprising these teams could include security professionals, project managers, or others. Team size can fluctuate depending on the nature of the projects and processes involved, but smaller teams are usually better. They’re easier to manage and there’s likely to be less chance of conflict with fewer people. 

Although there may be other groups involved, security and operations teams will always be essential to the DevOps process. They should be involved throughout the software life cycle, including the design phase. Security is not simply done out-of-band since InfoSec is providing input through the life cycle of the application. Operations teams provide production guidance through the software life cycle. 

    3. Make your work visible.

Knowledge sharing is important to DevOps, and teams should always be on the same page as to where things stand with regards to their projects. Most commonly, this is done through Kanban boards, which use cards, columns, and other visual representations of work to keep everyone up to date. They serve multiple purposes. First, all team members can view each others’ backlogs, which helps to maintain trust and accountability. Second, when work is visible, your teams can gain a complete view of projects, which can help them prioritize, reduce, or eliminate non-essential work. 

A few weeks ago, I witnessed this upfront. I was working with a product manager who was frustrated because a systems integrator was late delivering milestones. Fortunately, the teams were practicing DevOps and agile methodologies and had all their work visible. When the product manager went on-site to review the work, he was able to eliminate the backlog as it wasn’t essential to the mission. This cleared up communication with the developers, who thought they were hard requirements. The result was that the development teams felt empowered to focus on mission requirements and the product manager felt relieved they could now meet deadlines. 

Adopting blameless post-mortems for system outages can go a long way toward addressing and fixing challenges in a transparent yet team-friendly way. This is a best practice that has been adopted in many government IT organizations and relates to all parts of DevOps (people, processes, and technology). You can’t fix the root cause of problems unless stakeholders can meet and diagnose without casting blame. In a high-trust culture, people acknowledge mistakes and contribute toward preventing them in the future.

    4. Stay laser-focused on removing constraints.

DevOps practices and methodologies often mirror the lean manufacturing principles that were created in the 1990s at Toyota. Applying these methodologies to software means that you’ll need an assembly line, and will remove constraints standing in the way of progress.

An assembly line for software is an automated CI/CD pipeline — now often called a DevOps pipeline or a DevSecOps pipeline. This is a way to automate the build, test, and deployment of your software — and where the technology portion of DevOps comes into play. More importantly, it means that in order to improve the flow of code from a simple idea to providing business value (running your code in production), you need to be laser-focused on removing constraints from the pipeline, such as manual processes that do not add value to your organization’s goals. 

One way to remove constraints is to have an engineering or control review board assess changes before they go into production. These boards can be a bottleneck, but fear not because many changes, especially small changes, can be pre-approved by boards to reduce work in progress. 

Free Your Organization from Legacy Tasks

It may deviate significantly from longstanding development practices, but DevOps offers transformational potential for progressive state and local governments. DevOps can help eliminate legacy silos and bottlenecks; bring together key stakeholders to achieve specific business outcomes; instill lasting cultures of collaboration in which individuals take on deeper levels of responsibility; deliver streamlined processes that get products and services to market faster; and fulfill emerging public service expectations.

If you have the vision to implement DevOps within your agency, remember to proceed thoughtfully. Your patience has the potential to pay off in a significant way, with more nimble, efficient IT infrastructures that can free your organization from legacy tasks and enable a strategic focus on continuous service improvement and innovation. 

John Osborne

John Osborne is a principal openshift architect with Red Hat Public Sector. He has been largely focused on the role of Kubernetes in government IT modernization for more than three years. Before his arrival at Red Hat, he worked at a start-up and then spent seven years with the U.S. Navy developing high-performance applications and deploying them to several mission-critical areas across the globe. He is also co-author of OpenShift In Action.

 
 
Platforms & Programs