Each month, through our partnership with Harvard Business Review, we refresh our resource library with five new HBR articles we believe CIOs and IT leaders will value highly.
What is BizDevOps?
Is BizDevOps the next evolution of the DevOps movement? In fact, some DevOps teams could already call themselves BizDevOps. Consider the hallmarks of this type of team
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?
[ Need to explain key DevOps terms to others? Get our cheat sheet: DevOps Glossary. ]
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.
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.
[ Some common DevOps wisdom falls flat. Read 7 pieces of contrarian DevOps advice. ]
Hallmarks of a BizDevOps 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.
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:
- The team makeup: Business team and/or application owner, development team members, and operation team members form a single team; focus could be a product your company delivers, or a business process, business component, or business service.
- Integrated value and flow of processes: You have integrated business leaders, developers, and operations folks who all are working on a streamlined flow from your company’s strategy to the deployment and ongoing operations of the product, service, or component. You understand the value stream or you are working on, and you understand the customer journey end-to-end, including all key value chain components.
- Existence of key performance metrics: You have jointly established key performance indicators, which include customer-centric metrics – e.g., user behavior and feature adoption to DevOps metrics such as time-to-business-impact and speed of remediation.
- Automation toolchain: You are leveraging a variety of automation platforms that allow you to collaborate and automate across the different process and data items.
Meet SecOps, DevSecOps, and NoOps
BizDevOps is by no means the only evolution of the DevOps movement that began 10 years ago. Here are a few more terms you may hear along your own DevOps journey:
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.
[ DevSecOps bakes security into the start of the software lifecycle. Dive deeper on this topic: Why DevSecOps matters to IT leaders ]
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.
Whatever you call it, let the metrics guide you
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.
[ Culture change is the hardest part of digital transformation. Get the digital transformation eBook: Teaching an elephant to dance. ]