8 years into DevOps, automation, cloud computing etc, it's time to accept that DevOps is a specialism and a function that companies - especially big ones - need to put into place in order to adopt the principles.
See here for further thoughts - https://devops.com/im-happy-devops-engineer-job-title/
Back then we called this "systems administration". But we were most definitely working with developers and running the SDLC across silos.
It's nothing new, it's just got a label.
System Administrators used to blame developers. Developers used to blame System Administrators. Devops is in part an attempt to mediate between "silos".
therego...
He's not saying that chef and puppet are different because they're new; he's saying that using chef and puppet and docker all day long is a different job than debugging CSS and JavaScript or implementing REST api in scala all day long.
In any case, of course the name doesn't cause buy-in to happen, just like hiring an "Engineer" doesn't mean the person will do a good job engineering.
You're not saying that we should avoid a term meant to evoke the idea that cooperation is expected, because it might not happen, are you? I can only see rightness in trying to be clear about what's expected and naming roles to suggest positive cooperation is part of the job. If "DevOps" is meant to suggest buy-in and cooperation, you've convinced me that it's a better description than whatever it was called before.
The entire thing was brought in to remove the silos between SysOps and Dev. If you have people in the "DevOps" role, then you've just created a new silo, which means you just have traditional SysOps with a new and fashionable, but less meaningful name.
Which of course is title inflation and title overloading. Now if they'd just overload the salaries, we'd be set.
Can you name a profitable organization that has successfully eliminated ops/devops? I've yet to find any example of this.
At a certain level of scale, silos can be a very beneficial thing.
However for me, "DevOps" is more than just CI/CD and tech automation, it's about not working in silos and having empathy for others in the team (and the customer!). This is a culture and mindset that everyone in the team needs to have.