DevOps looks different at every company. Sometimes what seems like a good idea, in theory, creates roadblocks and redundancies in practice. In this blog series, we’re unpacking seven of those scenarios so companies can learn how to do DevOps right. This week, we’re looking at why security and compliance is often perceived as a burden.
Security and compliance are often treated like an afterthought. As you can imagine, this way of working creates problems. So why do companies do it? The answer is simple – they are stuck in their old habits.
Here’s an example of what this looks like in practice. A software development team gets a new project and starts the development process by reviewing the client’s requirements. A product owner then evaluates the feasibility of delivering those requirements and begins to do functional analysis on what the team wants to build. The team works Agile to build the software. When the final button needs to be pushed to move the source code to production, security and compliance is called in to review their work.
That’s when problems begin – the wrong infrastructure was used, a different authentication mechanism is needed, the possibilities for error are endless. When it comes to security, it’s rarely a quick fix. Rebuilding components takes a lot of valuable time and thus money. And the most problematic aspect of all? People blame the security and compliance team for these delays.
When security and compliance is treated as an afterthought, companies often begin to think of that team as a nuisance because their involvement frequently creates the need for rework. The mindset becomes that security and compliance slows down the production process. However, it’s not the team that’s the problem – it’s the workflow.
Problems Start with Silos
Traditionally, companies are organized by grouping people that have the same expertise together: development, operations, marketing, security and compliance, etc. Each department wants to have operational excellence so they create all these standardized processes within their own team. These processes work great within each department’s own bubble but when they need to collaborate, conflict arises. One department asks the other to follow their process: “Fill out this checklist.” – “What? There are 50 items. That will take way too long.” The teams have to negotiate where to even begin before they can get anything done.
Ditch Linear Thinking
Software design and development is not a neat, linear step-by-step process. When teams work in silos, there ends up being a lot of rework and hard feelings between colleagues. The most efficient and productive workflow is to collaborate from the beginning.
When security and compliance is included from the start, discussions are exploratory and positive. “We are going to run on this infrastructure. What do you think?” – “That would incur some security risk but if you do it like this you will cover that risk.” Then, the team can build without fearing lengthy rework later. This type of collaboration also has the added benefit of increasing security awareness in the development team.
While this may sound easy in theory, in practice change is hard! Giving up the comforts of your silo where everything is controlled and optimized according to your preferences will be challenging. So, adopting a more fluid workflow not only requires a shift in how things are done – more importantly, it requires a shift in mindset. How this change is implemented will look different for every company.
Want to dive deeper into doing DevOps right? Chat with us!
When it comes to DevOps, there are no one-size-fits-all solutions. Each company needs an approach that is tailor-made for their needs and teams. We can help with that! Please contact us for more information and ideas on how to find a solution that fits your team.
Also, tune in next time to find out why “we focus on 100% uptime for everything” is the third habit of a highly ineffective DevOps team.