DevOps is one of the key topics currently in the world of IT. However, it is also relevant for businesses and enterprises. We are living in a very disruptive economy nowadays and every company needs to have a plan in place on how to deal with such disruption. This applies to companies in each and every industry.
There is a lot of buzz going on and every giant software vendor proposes its own methodology around DevOps. Basically, it comes down to delivering faster, with better agility and continuous productivity gains while improving delivered quality.
There is also a lot of smaller companies and startups working to help with this endeavor. The community is quite open and flexible and constantly coming up with new tools and ideas.
I found this article quite interesting since it covers some of these topics and shares information on how others approached this challenge: https://blogs.technet.microsoft.com/devops/2016/06/13/devops-dimensions/
What “DevOps in the enterprise” actually meant in 2016
The 2016 conversation was shaped by two things. First, The Phoenix Project and The DevOps Handbook had landed and given enterprise leadership a vocabulary — flow, feedback, continuous learning — for what high-performing software organisations were doing differently. Second, the first State of DevOps reports were starting to publish numbers around deployment frequency, lead time, MTTR and change failure rate, which gave CIOs something concrete to compare against.
The actual hard part was almost never the toolchain. Picking Jenkins vs. TeamCity vs. TFS Build was easy compared to changing an org chart that had separated dev and ops for twenty years, or untangling a release process that required a change advisory board signoff for every production deployment. Most enterprise transformations followed the same arc: start with one or two pilot teams, prove the model on a non-critical product, then slowly extend governance and platform support to make it the default for everyone else.
How it evolved
What we called “DevOps” in 2016 has since branched into several more specific disciplines. Site Reliability Engineering codified the production-ownership side. Platform Engineering picked up the “internal developer platform” thread and turned it into a product discipline of its own — building golden paths so application teams don’t each rebuild the same Kubernetes cluster, observability stack, and CI/CD pipeline from scratch. GitOps formalised the idea that the desired state of infrastructure lives in version control and is reconciled by automation rather than applied by humans.
The four DORA metrics from those original State of DevOps reports — deployment frequency, lead time for changes, change failure rate, and time to restore service — are still the cleanest way to measure whether an enterprise transformation is actually working, regardless of which framing you put on top.