Breaking Down What DevOps Means

The software development life cycle has continued to evolve since it first emerged in the 1960s, with each iteration intended to bring about a faster, more reliable, methodical process for developing software and delivering it to end users. From structured programming and requirements analysis to rapid application development and scrum, developers and project managers alike can struggle to keep up with the new frameworks, methodologies, processes and tools. That struggle often turns into finger pointing (e.g., “Worked fine in Dev, it’s an Ops problem now.”) and frustration (“Did they even test this?”). With DevOps being the next iteration in the development life cycle, organizations have the opportunity to rethink their approach to software development. To do it right, they’ll first need to understand what it is and what it’s not.

DevOps Defined

DevOps is not build-in-place development or rapid prototyping. It’s not agile, and it’s not a role or a job title. It’s not a separate team or a special tool. It’s not just automation and there’s not just one way to do it effectively. It’s a rapid, customized approach to software development with minimum resources, maximum quality, and unification of development and operations for strategic mission fulfillment.

DevOps requires a culture of real-time collaboration among every group in an organization. It’s fast, and produces frequent deployments to production; if it’s slow, it’s not being done correctly. DevOps challenges distributed, status quo software development. It is different, and it requires time, funding, training, testing, communication, collaboration and buy-in but the benefits far outweigh the costs.

DevOps Considerations

There isn’t a single approach to DevOps that’s universally successful, but there are a few core elements that every organization needs to consider:

Communicate to gain commitment: DevOps represents a fundamental shift in the way developers and end-users operate. Just like any potentially high-impact, organizationwide change, there’s a significant chance it will be met with resistance. Prepare for the tough questions and anticipate who in your organization will fight it the hardest. Often, if you can win them over first, the rest of your organization will follow. Build a vision that everyone can understand and see where they benefit. Be as transparent as possible and eliminate barriers to communication; let everyone involved know how critical it is to have 100 percent commitment across the enterprise. If only four out of five groups commit, it’s still not going to be a success—no amount of technology can overcome a lack of commitment.

Break the rules: This isn’t necessarily an endorsement for asking forgiveness over permission, but a few maverick innovators can help make the case for why an organization should pursue DevOps. Instead of trying to transform your organization’s development mindset overnight, identify the developers and departments within your organization that can help you build a success story. Start small, and limit your DevOps pilot to something small (e.g., hot fixes only), and collect metrics. In time, once others in your organization see the benefits (and lack of outages), you’ll earn the trust and confidence necessary to make DevOps a success on a larger scale.

Automate: More rapid and frequent deployments require more rapid and frequent testing. To keep up, it’s best to leverage automated testing. With a manual approach, testing is typically reserved for the end of development. With DevOps, testing occurs throughout development to ensure consistent quality. Automated testing is continuous, but just as 100 percent commitment is required for DevOps generally, it’s also needed when it comes to testing because it’s a shared responsibility across your organization and individual departments.  

Remember security and choose your tools carefully: With a constant stream of headlines about the latest cyber breaches, it’s become a little harder nowadays to ignore security, but not impossible. There’s a wide variety of DevOps tools available, many of which can help to raise your security profile, but it’s important to also determine what you need your tools to do for you. From code and container creation to infrastructure and process monitoring, there’s a host of self-proclaimed DevOps tools available for purchase. Be sure the tools can do what you need them to, ensure they are secure, and verify that they will function properly in your environments.

Realize DevOps is part of the whole: While DevOps can certainly bring a variety of benefits to an organization—from a shorter development cycle and reduced errors, to increased uptime and reliability—it’s important to realize that it’s really a philosophy and only part of a greater IT solution. Implemented correctly, and coupled with other IT solutions and processes, organizations can realize even more benefits.

DevOps isn’t just about development and operations. It’s really more like DevAutoCommSecOps, but that’s a mouthful, even in the federal space. There are a number of definitions of what DevOps is, but what really matters is understanding what it can do for your organization. With the investment of time, the allocation of certain “rogue” resources, and steadily earned buy-in across the enterprise, federal organizations have the opportunity to considerably reduce their deployment times, and increase the engagement and satisfaction of end users while also significantly increasing their security posture.

According to the 2016 State of DevOps Report, high-performing DevOps organizations deploy 200 times more frequently, have higher employee loyalty, and spend 22 percent less on unplanned work and rework. Those benefits reflect what a mature DevOps organization can expect. Those just starting to adopt DevOps can achieve similar results, but it will take time and total commitment.

Colby Proffitt is a senior analyst at NetCentrics.