TNS
VOXPOP
Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
0%
At work, but not for production apps
0%
I don’t use WebAssembly but expect to when the technology matures
0%
I have no plans to use WebAssembly
0%
No plans and I get mad whenever I see the buzzword
0%
DevOps / Software Development

Breaking Down the Wall in DevOps

The barriers between dev, ops, security and QA hinder software development, but they aren’t inevitable. Learn how to tear down these walls.
Dec 1st, 2023 5:30am by
Featued image for: Breaking Down the Wall in DevOps
Featured image by Mick Haupt on Unsplash.

The Wall.

This phrase is often used in the DevOps world to describe the proverbial barrier between teams that prevents collaboration. For example, you might say a development team “throws code over the Wall” to the operations team. The Wall stands as a mental and emotional barrier to an imagined utopia where development, operations, security and quality assurance (QA) all go frolicking arm and arm in a field full of flowers, ready to tackle every problem together.

But what, exactly, is this barrier? If we know it exists, why can’t we make the Wall disappear? No matter how many times someone says DevOps is dead (or old hat or obsolete) while trying to entice you to the newest, shiniest thing, the Wall still appears. The barrier might shift within the organization — after all, every dev seems to want to own a platform (that’s sarcasm), but it is always there, even if the infrastructure responsibilities slide underneath.

What Is the Wall?

In the modern organization, the Wall represents a barrier of ownership, a transition point where teams meet and hand over responsibility for nurturing some part of a product to the next owner. Simply making developers the owners of the infrastructure, as many initially tried when teams moved to hyperscalers, just moved the Wall’s position. The barrier is still there and still a problem.

At any of these transition points, conflict may be found. From ops demanding answers about messy dependencies to devs demanding others treat their project as a golden ideal, the conflict arises at the moment of a handoff, no matter how many times you try to move the Wall. Some organizations try putting everyone on the same team, but there’s still a handoff of responsibility. It’s also not as simple as having one person own everything all the way through, because that owner delegates responsibility to different people at different steps of the process based on their expertise.

These transition points also represent changes in measurements. Development is measured by how many features are released. Operations are measured by how much uptime is gained or maintained. Security is measured by how many systems aren’t breached. QA is measured by how many bugs don’t appear in customer reports.

From a high level, an executive examining the Wall may be baffled at why there is conflict; after all, we all just want to keep the company running and customers happy, right? However, when a developer passes a mistake over the Wall to the operations team, the ops team’s uptime declines. When an ops team decides not to update an operating system for another week to maintain stability, the security team’s concern about a breach increases. People fundamentally cannot take in the wider viewpoint when their job may be threatened by someone else’s choice. Instead, the first instinct is to protect themselves by meeting their measurement. And thus, the Wall persists.

Breaking Down the Wall

If you want to enact change in an organization, you might try to use tooling to overcome the Wall and bring about a cultural transformation. Or you might try to adjust the culture first by shifting ownership around before choosing tooling. An organizational transformation is about making a radical shift to improve an organization. So a cultural organizational transformation is a radical shift that improves an organization’s culture; it’s not necessarily a radical shift in culture that improves an organization. As such, one initial step toward breaking down the Wall may be shifting the company’s measurement structure so that everyone starts and ends on the same page. That radical change in measurement can improve the culture by enabling people to care about other teams’ outcomes.

From a more practical standpoint, to truly remove the Wall does not mean getting rid of ownership — the idea of having a project without an owner is patently ludicrous — or having one person own something the whole way through. It also does not mean isolating layers of your systems so that they are always owned by one team. To truly remove the Wall is to make the transition of ownership more seamless and less conflicting.

Often, we are told that a healthy organization is one where strong communication and psychological safety (among other things) are considered critical. There are key things you can do to reduce conflict: Use common language when starting the software development lifecycle (SDLC) so that there are no surprises when you meet to hand something off. Make mistakes less problematic by making small enough changes on a fast enough cadence that the impact of a mistake is minor and temporary. Address technical debt quickly to avoid overloading any team with too much ownership of something that will never get fixed.

This is the true goal of DevOps. The goal of DevOps is not to scale the Wall with more tooling. Instead, the goal is to erode it, reducing it down to where you can step over it with ease while sharing the burden of ownership — much like carrying a picnic basket together into the next field.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Simply.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.