DevOps is designed to remove the silo mentality that limits the effectiveness of business IT. But does it go far enough? We look at what BizDevOps means, why it is gaining traction and the crucial lessons to ensure a project delivers results.
DevOps is a very important topic for business technology professionals, arriving at a time when they are under great scrutiny to deliver value and connect their actions to corporate objectives. DevOps amalgamates several ideas that grew up around the same time – such as Agile and Lean – and just like those approaches, it attempts to fundamentally alter how IT is delivered into the business.
What is DevOps?
As the name suggests, DevOps encourages the typically disparate business IT functions of Development and Operations to work as a collaborative whole. The idea is simple. Developers build IT tools and services which IT Operations then have to run and maintain and business operations use. However, if Operations isn’t consulted during the development stage, IT is often not fit for purpose or Operational issues such as capacity, performance and security have been badly considered.
By encouraging communications, building a feedback loop and encouraging a culture where both parties work together for mutual gain, IT becomes more effective at giving the business what it needs.
It is this final point that underlines the importance of DevOps as an initiative. DevOps, if managed correctly, helps unify IT with the business. However, there is a crucial element missing from most interpretations of DevOps: involvement with business strategy.
Why is DevOps misunderstood?
Most definitions of DevOps you will find online primarily focus on the connection between those building/deploying technology (development) and those running, maintaining and using it within the business (operations). These definitions quite rightly encourage feedback between both parties. If handled correctly, this will lead to improvements in the IT being delivered. It will reduce wasted projects, improve future development and deliver more useful business technology.
But how do we ensure the work carried out is contributing to the ultimate aims of the business? Where do these definitions mention the strategic outcomes of the business? At what point – if any – are those deciding the future direction of the business and tackling the “big picture” problems consulted in DevOps?
In other words, DevOps’ apparent critical flaw is that it omits the business strategy from its equation. This is a contentious point. For some people, notably Gene Kim in his article “Three Principles Underpinning DevOps” understand that delivering business outcomes is perhaps the defining principle of DevOps. However, many others have failed to make this connection, and it’s easy to understand why.
Firstly, the name ‘DevOps’ itself is part of the problem, because it only highlights two areas of the business. Secondly, DevOps has understandably been introduced in small increments. DevOps is a massive cultural shift for IT. It paves the way for IT to become seamlessly ingrained with the business. But this ‘big bang’ approach is unrealistic, to change the culture and mindset that is required must start gradually and at a manageable size, which can then be scaled up as it becomes accepted. In this respect, thinking of DevOps on a small scale is the ideal starting point. However, this reductive thinking has tarnished the idea and led some people to believe it isn’t expansive enough.
Why we need BizDevOps
It is these apparent shortcomings that have led to the creation of a new term: BizDevOps. BizDevOps, as the name suggests, explicitly promotes the idea that the ‘business’ must be part of the process. By including decision makers, CIOs, business unit leaders and strategy makers in the feedback loop, BizDevOps moves us further towards total convergence of IT and the business.
So in answer to the question: do we need to rename DevOps as BizDevOps? While we probably shouldn’t have to, we should use the term if we want misunderstandings to end and clarify the primary aim of DevOps.
Organisations have tried to break down barriers between IT and the business for years. There are multiple reasons why these attempts have failed. But the biggest problem is that these initiatives start and stubbornly remain within IT. DevOps is in danger of falling into the same trap. It’s all too easy to build a service, ask the business community for feedback which is then ignored and call it DevOps. Or for developers to ask department heads if there are any major issues that need resolving and call that DevOps.
By including ‘Biz’ in DevOps, we offer a constant reminder to include the business in every aspect of the process. BizDevOps has the potential to fully converge IT with the business but it must be taken seriously. There’s no value to be found in paying lip service to the concepts of DevOps, neither should it remain forever as a small scale project. If while in conversations we explain how BizDevOps will transform the way IT is deployed by taking into account both operational and strategic aims, we set high expectations and pique interest. While this may be ambitious, IT professionals with this bold attitude will be those ensuring that IT will finally give the business exactly what it needs.
If you would like to find out more about BizDevOps, download our Beginners Guide here.