Why DevOps Implementation is Often Unsuccessful (and How You Can Fix It)

This article was originally published on DevOps.com. It has been updated and modified.

Much like "blockchain", "big data" and "digital disruption", the term "DevOps" is another buzzword currently being thrown around the IT departments of large organizations.

Many have (correctly) identified the need for faster software development lifecycles; a more precision process that is closely aligned with business objectives, allowing for clearer workflow and collaboration between the development and operations-based teams. DevOps is essentially "Agile" development, all grown up and ready to take on the constantly innovating, rapidly deploying needs of the modern business. For security professionals, it's a fantastic initiative: we can inject security into the process far earlier, reducing the cost of fixing bugs and avoiding potential catastrophe down the track.

The problem is, few companies are truly successful in their DevOps implementation. Without the right support, nurturing and understanding across the business, it can quickly become a white elephant... you know, one of those "don't mention the war" projects.

So, what's the problem? It's an interesting discussion, and there are a few ways to approach DevOps that I believe will make for much smoother sailing. An effective program goes beyond a few fancy new tools, titles and team meetings. It's not always going to be easy, but taking the time to fix a broken strategy (or implement it the right way at the start) is going to be far less painful in the long run. And ultimately, it's going to result in higher quality and more secure software.

Let's break it down:

Let go of the "Agile" apron strings.

There is somewhat of a misconception that an organization must choose between Agile or DevOps, setting down one path or the other, never to look back.

The thing is, the development process works best when both are being considered and implemented as one. DevOps is not a reinvention of Agile development; rather, it is an extension of it. The wheels tend to fall off when there is an expectation that the process will be exactly like Agile, or completely different from Agile.

Agile supports the principle of cross-functional teams, bringing designers, testers, and developers together from the beginning and committing to open communication lines throughout a project. Its aim is to stop siloed delivery and reduce double-handling, both of which are benefits of the DevOps process as well. However, DevOps goes a step further, introducing systems, security, and operations into the mix to offer a robust, end-to-end skillset that has the ultimate goal of full, functional software delivery to the customer.

During the inevitable pain-points of moving to a more DevOps-centric process, the risk of siloed development can crop up again. You can often have the original Agile team working together, with the security and operations additions still finding their way in the machine; no-one is quite sure how to include them, what they should be doing and their overall objectives.

DevOps does not work without clearly defined objectives, cross-functional onboarding and direct communication with all parties. There will be an adjustment period requiring careful change management, sure, but getting everyone on the same page with the enhancements that DevOps functionality will bring is half the battle.

Increasingly (thank goodness), DevOps is placing emphasis on security best practice as part of the process as well, demystifying that step and bridging the gap between the security team and, well, everyone else. As I have said before, we still have a long way to go in empowering developers to code securely from the start, but the successful implementation of DevOps methodologies is an excellent foundation on which security skills can be built within the development team.

Automation isn't everything (and it's not the most secure).

Another feature of DevOps methodology is, to a certain extent, the automation of the software development process. Continuous integration and continuous delivery (CI/CD) principles are the cornerstones of this concept, and as you can likely guess, very reliant on tools.

Tools are awesome, they really are. They can bring unprecedented speed to the software delivery process, managing the code repository, testing, maintenance, and storage elements with relatively seamless ease.

However, while robots might take all our jobs and imprison us someday, they are definitely not there yet. Heavy reliance on tools and automation leaves a window wide open for errors. Scans and tests may not pick up everything, code may go unchecked, and that presents enormous quality (not to mention, security) issues down the track. An attacker only needs one back door to exploit to steal data, and forgoing the human element in quality and security control can have disastrous consequences.

The "happy medium" is to ensure you have a balance of people and tools. Tools should serve as the assistants to a team you trust to deliver on project goals. You should:

• Allocate enough time for people to become familiar with the chosen DevOps toolchain
• Focus on effective collaboration (and how the tools can support that)
• Address any gaps in the process, whether they are skill/knowledge or tool-based.

In short, don't just "tool up" and hope for the best.

DevOps isn't a buzzword, it's a culture. Are you growing yours?

Change management is tough at the best of times. Fear of the unknown can stop even the most brilliant team members from growing their skills and expanding their horizons.

You see, merely saying "let's do DevOps" and making the operations team move desks isn't going to magically implement a successful process. Many will be confused, and long-serving members of the team will be left feeling disgruntled. Communication of expectations is crucial, as is "walking the walk". DevOps represents a cultural movement just as much as a development methodology, and a team should live and breathe a cross-functional, collaborative mindset.

What does a great DevOps culture look like?

• Individuals are empowered to lend their expertise to a process, not just leaders
• Open, honest and respectful communication between teams
• Each person takes responsibility for the overall objective of building quality and security into the development process
• Everyone is on the same page with the definition of DevOps in the business, the roadmap and how/what/why of each person's role.

For years I have emphasized the importance of building positive security cultures in development teams, and DevOps is no different.

The right tools, knowledge, and support are imperative to achieving security best practice, seeing a downturn in discovered vulnerabilities and opening the team's eyes to the importance of protecting our data. With DevOps, you must lay the cultural groundwork for positive change: ensure everyone understands their role, value, and expectations, the overall project goals and steps in the process.

Have you mastered that? Great. Now, let's shift the needle, dial up the security aspect and make DevSecOps the ultimate plan for software excellence.