What is DevOps 2.0?
DevOps 2.0 is the extension of DevOps practices through the entire organization, beyond development and IT ops. DevOps 2.0 aims to break down silos and foster communication and cooperation between all groups -- technical and non-technical -- involved in the conception, production and maintenance of software. A DevOps 2.0 process includes development and operations, quality assurance and security, HR and legal, and on through the organization.
When the DevOps movement started in the late 2000s, early adopters sought to increase collaboration between developers and IT ops most of all. That was the key to removing information silos and achieving continuous delivery.
The DevOps journey then began in earnest with The Phoenix Project in 2013, and organizations started to adopt the DevOps approach to Agile software development -- building quality software faster through developer and IT ops collaboration.
Principles of DevOps 2.0
Now, collaboration doesn't end with developers and IT ops. Organizations have come to understand DevOps as a practice that integrates all parts of the organization into the software delivery process.
DevOps first expanded as a concept with BizDevOps, in which DevOps teams brought business management into their continuous integration process. With real-time analytics and API tools, executives can monitor and engage with software as it moves from idea to working code.
DevSecOps likewise expanded the idea of DevOps by bringing the security team into the collaborative mix. While DevOps 2.0 and BizDevOps are often used interchangeably, DevOps 2.0 actually encompasses a digital transformation in a broader and more holistic sense.
In most cases, DevOps 2.0 means encouraging continuous communication and collaboration among all divisions in an organization to help speed software delivery and increase software quality.
DevOps 2.0 uses
DevOps 2.0 requires quality control engineers and IT security teams to be part of the continuous delivery process. In DevOps 2.0, a team monitors IT infrastructure even after it has launched an application. HR and legal departments are expected to actively support engineers working in a continuous software development lifecycle.
Where applicable, DevOps 2.0 also encourages various organizational units to embrace the same DevOps tools; for example, the alerting and monitoring tools that IT ops uses to maintain infrastructure might also be used by developers so they are aware of application problems faster. At the same time, a PR department might also have access to those tools, so it will know quickly about customer-impacting software problems and prepare a response.
Advantages and disadvantages of DevOps 2.0
When DevOps teams are on the same page, organizations can make software that's more flexible than its waterfall counterparts. With containers and feature flags, DevOps teams have the tools to launch, update and monitor applications as different features are functional ready instead of in one timely and expensive monolithic operation.
In DevOps, though, there's always an initial strain on developers, who not only have to code -- and be fluent in different languages and tools -- but be involved in all aspects of production. DevOps will stress IT ops as well, who must now be familiar with code. Burnout is a real threat in DevOps environments.
DevOps 2.0 requires a significant culture shift to work. Instead of bridging just one silo, organizations adopting DevOps 2.0 must bridge all silos. That requires long-term executive buy-in and leadership in what will be a lengthy transformation.
See also: rugged DevOps
