September 09, 2019
In 10 years, DevOps has grown from a few people spearheading the movement to a worldwide trend towards agility, speed, and ways to effect meaningful change in the delivery of software. DevOps adoption ranges from use on single projects (43 percent) to enterprise-wide adoption (19 percent).
It is, in the simplest terms, a mashup of development and operation. If I am pressed to describe DevOps in more detail, I would say it is a “cultural movement where both key stakeholder groups (developers and operations) agree that software is not really adding any value until it is used by somebody – a customer, client, employee, etc. Due to this, both teams ensure that software is delivered with speed and quality.”
But both of these definitions leave something out: Where is the business?
DevOps is mostly about breaking down the boundaries between the development and operations teams. To take it further, the existing strive towards digitalization across verticals requires additional elimination of boundaries. One key boundary exists between IT and the business. That’s where BizDevOps comes in.
Some applications and services are mission and business-critical and require continuous change.
Before exploring this further, it is important to understand that not all applications and systems need to be changed at the same speed. Some applications and services are mission- and business-critical and require continuous change. Others belong to the systems of record and don’t have the same change and velocity objectives. For example, changing the way customers interact with a financial institution via a mobile device requires a new development or continuous changes to already existing applications or services.
Most importantly, when taking a BizDevOps approach, both IT and the business must decide together which application or service they want to change and why. Discussions on improvements (e.g., time to market), questions on the impact or achievements of the changes or new capabilities (quantified business benefits), and the cost and savings (both indirect and direct) are good starting topics for the united business and IT team.
It does not matter if an organization calls its journey a DevOps or BizDevOps journey. What matters is that all key members within the value chain of a service or application agree on delivering in accordance with business value and objectives. Teams must agree on the priorities of the projects they are undertaking to ensure that competing challenges and objectives are eliminated ahead of time.
These teams have business domain owners participating from the start.
In fact, some DevOps teams could already call themselves BizDevOps. These teams have business domain owners participating from the start, they use Kanban and scrum (plus more), and are leveraging past learnings to eliminate waste. Some other hallmarks of a BizDevOps team include:
BizDevOps is by no means the only evolution of the DevOps movement that began 10 years ago. Here are a few more terms you
SecOps is a different approach to bridge the gap between security operations and IT operations. The goal of SecOps methodology is to ensure that all systems meet performance and availability goals while they are secure and compliant. This means a SecOps team must share accountability, processes, and tools to observe and act upon threats together. A study by Ponemon in June of 2018 found that 55 percent of IT operations and 60 percent of IT security respondents believe that differing priorities cause tension between these two functions.
DevSecOps inserts security into the DevOps team. It can be a win-win for all, but mostly for the customer and the business teams. As the rate of software delivery ranges from hourly to daily to weekly, according to the Accelerate State Of DevOps survey, DevSecOps ensures that security is an integral part of the development workflow and therefore a natural evolution of DevOps.
For the term NoOps, I must thank my former fellow analyst at Forrester Research, who coined this term. In 2011, Mike Gualtieri felt that DevOps was a step backward. Considering that he belongs to the role of developers, his goal for the future was to improve the process of deploying applications. To do that, he thought there should be NoOps. That means that operations goes away when configuration and deployment are completely automated or part of the developer’s workflow. Adding admin and observing applications and infrastructure via managed cloud services would make a no-operations team possible.
Unfortunately, IT enterprises are still mired in on-premises legacy infrastructures. A move to the cloud may help pave the way, but until everything is in the cloud, NoOps will have to wait.
What truly matters to an organization is what influences the velocity and quality of software delivery. Increasing customer experience and business agility is only possible if your application is available, and your goal from there should be to continuously, securely, and efficiently add capabilities and enhance value.
Now, whether you call this DevOps, BizDevOps, SecOps, DevSecOps, or NoOps, you must have a team comprised of members who together focus on key metrics and continually break down boundaries between them in order to meet the goals of your organization and demands from your customers. This is the business value of DevOps.