DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • DevOps Onramp
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » Defining DevOps: Not Theory, nor Implementation

Defining DevOps: Not Theory, nor Implementation

By: contributor on January 24, 2017 2 Comments

Ask a dozen engineers, developers, testers or their managers what their definition of DevOps is and you will get likely very different answers from each of them. Some may say it’s primarily about culture, others may say it’s about accelerating or automating the release of software and infrastructure changes and some may use the mantra, “People, over process over tools.”

Recent Posts By contributor
  • How to Ensure DevOps Success in a Distributed Network Environment
  • Dissecting the Role of QA Engineers and Developers in Functional Testing
  • DevOps Primer: Using Vagrant with AWS
More from contributor
Related Posts
  • Defining DevOps: Not Theory, nor Implementation
  • 5 Things DevOps is Not
  • How DevOps Can Effect Culture Change to Improve Business
    Related Categories
  • Blogs
  • Doin' DevOps
    Related Topics
  • definition
  • devops
  • implmentation
  • specialization
  • theory
Show more
Show less

What no ones seems to be able to agree on though is how to define the boundaries and constituent parts of what DevOps is really all about. It is all-encompassing, it seems to cover topics as varied as continuous improvement, collaboration, a whole raft of processes from agile, through testing to operations procedures, audit, compliance and customer feedback to collaboration. It seems to be attempting to cover every facet of life in this small part of development and IT operations that we live in—and because it’s so broad no one can really agree on what it means.

AppSec/API Security 2022

My suggestion is that we should try to narrow the definition of what DevOps is in an attempt to create some boundaries so that it can be considered more of a discipline than a utopian goal. For this reason, let’s consider some of the core concepts—culture, communication, collaboration, continuous improvement—as things that are important to its implementation, but not the thing itself. These are aspects of high-performing teams and should use a different lexicon outside of the DevOps world.

So culture should not be considered part of DevOps?

Put simply, any initiative that fundamentally reshapes an industry through a fundamental change in its objectives, process and delivery mechanism implicitly needs the support, buy-in and leadership of those involved. Much of the cultural aspects of DevOps seems to be around these areas—but if you are attempting to radically change the way any industry works, then these are common goals that use management and leadership theory that are not restricted to change within a narrow segment of software development and IT operations. These leadership challenges exist not only within the teams responsible for the delivery of software and IT operations—but in many industries that undergo disruptive change.

Should culture be a primary factor in implementing a DevOps initiative?

Now, this may sounds like a contradiction to what’s been said above but the answer is, of course, yes. However, the culture of any organization should be at its core. The culture within a law firm is important, as it is in a research lab or within a retail organization. If we take retail as an example, when a retailer implements just-in-time (JIT) delivery, which is analogous to what certain aspects of DevOps is trying to achieve—the faster delivery of goods, automation, small batch, feedback loops, metrics, audit, collaboration of disperse part of the supply chain—how much priority is based on whether the employee’s need to be bought into the idea before the initiatives were started? I would suggest not much; it was a management decision, based on shareholder value and the competitive advantage it would provide over competitors. Now that DevOps has become much more mainstream, I think we should think about it in a similar fashion. Retailers that have not implemented JIT are either out of business or very niche. We should no longer be thinking we need to get staff buy-in; the world has moved on, it’s happening, it’s mainstream and if your not on board, then get a job elsewhere. If you work in a shop and put some goods in the store for sales that have not been delivered by JIT, then you get fired. Simple as that.

Is DevOps really the same as JIT Delivery?

No, of course it’s not. JIT was a top-down, strategic management decision to implement on its workforce. It did not come from the grass roots, it did not come from a philosophy and belief from those at the coal face that there is a better way to deliver goods to customers, it was not a revolution by checkout staff that demanded that no longer should their managers buy from suppliers on a golf course and return to the store and tell them to make it work. The DevOps culture, by which I mean the culture within the DevOps community, is so inspirational because they shunned the top-down approach to implement bloatware and chose to go off piste—collaborate with their piers and change the face of an industry in a revolutionary way. They demanded that they know best.

Too many Brents

For all the talk of culture however, this industry we work in has far too many Brents (as in the indispensable engineer in the Phoenix Project, who is the only person who can fix the problem, but is also the root cause of all the issues). I am often baffled at the irony of the no hero’s mantra that is all too often exposed in the DevOps world, but many of the most talented engineers I believe do crave a hero status. They derive a lot of their self worth from the work they produce and consider themselves a snowflake, even if their servers aren’t. They write complex scripting frameworks in Ruby or Python and are attracted toward complex and powerful tools that they enjoy using, engineering themselves into a position where they derive brent-like satisfaction and create some job security. I’m not necessarily being to critical of such an approach, but I do find it guiling that at the same time believe they are part of a cultural revolution.

But do the engineers know best?

I think it’s hard to argue that, certainly if compared to 10 years ago, that the broader influence of DevOps has not only made software delivery and IT operations a much more exciting and dynamic environment to be working in—but is also delivering huge business value and competitive advantage for those organizations that have embraced it. Was culture and philosophy a key driver to achieving this? Absolutely. But much as Ben Horowitz espouses in the “Hard Thing About Hard Things,” you need a team to take a business to a certain level, and once it has reached a certain level of success it needs to be taken forward by specialists, not generalists who brought it to that point. I believe we have reached that point.

DevOps is now becoming mainstream and may benefit from being subdivided into different areas of specialization. As a startup, there is fun, excitement and a belief that you can change the world. Individuals that thrive on that often enjoy the variety in the work, performing a variety of functions within the organization—maybe some software development, support, pre-sales and marketing. But as an organization grows, specialization is required, there is a marketing team, support team, pre-sales and engineering team. This is a reality of working in a growth organization. There is no longer one team that does everything, but they are split out into specialization, collectively bringing the whole organization to a stronger place. DevOps has grown up—and needs to demarcate specializations to take it to the next level.

So how should the boundaries of DevOps be defined?

I would propose one of two things. DevOps remains the overarching philosophy of how we make the world a better place, underneath it sitting some more defined disciplines which are less related to the philosophy. So we don’t have the concept of a DevOps engineer, but instead they are roles such as automation specialist. Or perhaps, if I’m honest the way I felt when I started writing this blog is that we (and I consider myself part of the DevOps engineering community), now it has become much more mainstream, allow it to be taken forward by specialists disciplines, of which engineering is one, but the cultural, philosophical and management practices are no longer in the startup realm but need to be taken forward by the “grown ups.”

The philosophy and implementation should be separated

Ultimately, I think there needs to be some separation from philosophy of what DevOps is and the constituents parts of it. My primary reason for writing this blog, if I’m honest, was I am becoming bored of the DevOps bandwagon. The whole DevOps concept is is meant to conjure exciting and positive ideas how we can make the world a better place … but spring turns to summer, turns to fall, and successful startups turn from dreamers with passion to having VC backers or being owned by private equity.

This is not meant to be a negative point though—anyone who creates a start up ultimately wants it to go on to become a grown up. And Patrick Debois may be the founder of the startup, but DevOps is now a publicly listed company.

About the Author / Dave Sayers

Dave Sayers is a co-founder and technical services director of MidVision, a provider of Release Automation and Continuous Delivery Software. He works closely with customers and partners on DevOps and Automation initiaitves throughout Europe and North America and is responsible for devising and managing the partner and channel strategy. Connect with him on LinkedIn.

Filed Under: Blogs, Doin' DevOps Tagged With: definition, devops, implmentation, specialization, theory

Sponsored Content
Featured eBook
The Automated Enterprise

The Automated Enterprise

“The Automated Enterprise” e-book shows the important role IT automation plays in business today. Optimize resources and speed development with Red Hat® management solutions, powered by Red Hat Ansible® Automation. IT automation helps your business better serve your customers, so you can be successful as you: Optimize resources by automating ... Read More
« Automation, ChatBots Can Improve DevOps
Webinar: How to Build the Right Automation »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

The ROI of Integration: Must-Have Capabilities to Maximize Efficiency and Communication
Thursday, August 18, 2022 - 11:00 am EDT
Best Practices For Writing Secure Terraform
Thursday, August 18, 2022 - 3:00 pm EDT
Transforming the Database: Critical Innovations for Performance at Scale
Tuesday, August 23, 2022 - 1:00 pm EDT

Latest from DevOps.com

Civo Report Surfaces Growing Cloud Lock-in Concerns
August 17, 2022 | Mike Vizard
Techstrong TV: Styra Declarative Authorization Service
August 17, 2022 | Alan Shimel
A Guide to Sustainable Application Modernization
August 17, 2022 | Bob Quillin
Overcoming Multi-Cloud Management Challenges
August 17, 2022 | Faiz Khan
Contrast Security Adds API Support to Security Platform
August 16, 2022 | Mike Vizard

GET THE TOP STORIES OF THE WEEK

Download Free eBook

The 101 of Continuous Software Delivery
New call-to-action

Most Read on DevOps.com

We Must Kill ‘Dinosaur’ JavaScript | Microsoft Open Sources ...
August 11, 2022 | Richi Jennings
What GitHub’s 2FA Mandate Means for Devs Everywhere
August 11, 2022 | Doug Kersten
Next-Level Tech: DevOps Meets CSOps
August 12, 2022 | Jonathan Rende
The Benefits of a Distributed Cloud
August 12, 2022 | Jonathan Seelig
Cycode Expands Scope of AppDev Security Platform
August 11, 2022 | Mike Vizard

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.