Having been in the software development business for 25 years now, it is truly amazing to see how many old ideas are brushed off, polished up, and re-branded as something new. Or taking a “new” concept that begins to take off and broadly applying it to other things. DevOps is great example.
DevOps, at its foundation, is a set of guiding principles that you can apply to the collective SDLC (software development lifecycle) to achieve some real benefits. At its roots, DevOps is all about breaking down the silos between development and operations (see Systems Thinking in The Phoenix Project). All good. Not rocket science, but something worth striving for. But how new are the concepts, really? One of the websites I frequent (DevOps.com) uses the phrase “helping finish what agile development started” as a subtitle. I love that sentiment. Agile development provided new ways of looking at software development to achieve better results. Much to the contrary of some managers I have had, agile is not rocket science. The biggest hurdle for some to get over was simply that it was different. DevOps is again doing the same thing.
In today’s DevOps “market”, you can most likely find tools and processes across the SDLC that have been re-branded as part of a DevOps solution. IBM is a master of this and rightly so. Re-branding is a tried and true way of re-inventing offerings to make them appealing to a new audience. But let’s not get caught up in the hype. Implementing a change management solution is still a good thing to do, regardless of whether it falls under the DevOps umbrella or not. Automating builds has always been and will continue to be a good thing, even when the next buzz-word craze comes along.
The great thing about this DevOps wave to me is that it has simply refocused the spotlight on some areas of the SDLC that have traditionally been under the radar and under appreciated. There were always the guys that could make it happen, that wrote and maintained the magic scripts, and that utilized special skills that no one else had. The Phoenix Project helped to highlight the fact that these guys can be heroes and also the bad guys when it comes to mission critical deployments. How to properly utilize “Brent” to take advantage of his knowledge but not to make him a bottleneck is an important lesson to learn. Every organization has a few Brents, and the DevOps wave (and thanks to the book) have helped to elevate the need to capture Brent’s knowledge into repeatable automation. A continuous delivery solution like IBM UrbanCode Deploy can make many Brents who are available 24/7.
So be prepared for the onslaught of marketing campaigns that now re-brand every software development tool and process to be “Your DevOps Solution”. But speaking as a former “Brent”, I am glad to see the Brents of the world being in the spotlight.