Rawpixel - Fotolia
DevOps is fine -- in theory. Many organizations, however, have tried to implement DevOps only to find that it leads to more problems -- rather than fewer.
In the majority of cases, this comes down to an organization understanding DevOps as a development or operational issue, one meant to speed the delivery of code from one group to another. This perception of DevOps, though, misses a couple of important areas.
The first, as I wrote about a while back, is the need to have security baked into the whole process in the form of DevSecOps. The second, and possibly even more important, is the need to have the business leaders involved from the get-go, as in BizDevOps -- sometimes referred to as BusDevOps as well.
BizDevOps will ensure that the right focus is on the end-to-end processes required for a successful DevOps for business strategy.
Why DevOps for business matters
Everything the IT team does must be in the business's best interest. Anything the DevOps team does -- from the introduction of new functionality or the complete movement of a function to a new platform such as cloud -- should be driven by business gains. You don't implement DevOps to make the IT team's life easier or because it's a nice technical challenge that will look good on a few people's résumés when the time comes.
This means that the starting point for any DevOps project can't come from IT directly -- it must be driven by the business. IT may identify a business need and take it to the business as an idea, but IT cannot be the sole driver behind any project. There must be business involvement right from the start. This may be difficult. Many lines of business (LOBs) see themselves as the division that makes a decision and then passes down what they believe needs to be done with IT -- as a sort of Jean-Luc Picard/Star Trek command of, "Make it so." At this point, it is rather late for IT to turn around and say, "Ah, but …"
BizDevOps in practice
The DevOps team must fight to have a seat on important business meetings, especially if they want to have a say on technical issues. In those meetings, IT can then raise any issues and also discuss different ways to address a business problem. This may require IT to change its approach: There is little point in saying to an LOB, "Well, we could do that, but it is likely that the latency across to a NoSQL database on AWS could be a bit of a problem." Everything needs to be termed in language the business can understand -- and in a way that gives the business the capability to make an informed decision. Explain how it could be done this way (at this cost and risk) or that way (at this cost and risk). Then ask which approach best fits the business's immediate needs.
And choosing an approach is not the end of the issue. DevOps for business must still follow Agile concepts. You need to introduce feedback loops across the whole process. Through continuous development, the development team can go back to the LOB with mockups and early-stage prototypes, to ensure the project still meets requirements.
Even when the code moves into the operational environment, you need adequate and speedy capabilities for users to provide feedback -- either directly through the application or through the help desk with requests for functional improvements or changes. The development team should prioritize work based on business need, rather than by technical challenge or ease of work. By responding rapidly to actual business needs, IT will be appreciated by the business and not seen as a constraint on progress.
BizDevOps can, when implemented correctly, be one of the most effective approaches in how an IT team can support a business in a flexible and responsive manner. However, it is easy to get wrong -- and, when done wrongly, DevOps can bring a business to its knees. Make sure that the business is involved throughout and that information security is covered. That way, BizDevOps can be a means to provide massive competitive advantage.