Why DevOps May Be Wrong for Your Organization 

When organizations see that a new methodology, sales channel or technology is doing well for a competitor or in the industry at large, there is often a desire to incorporate this into their own business. After all, if it works for others, why can’t it work for them?

The wide success of agile as a way to improve transparency and delivery is a great example of a better way of working that seemed to be making a real and positive change to organizations that were correctly embracing it. Similarly, the adoption of cloud services as a place to build new, highly scalable solutions was a “no brainer” for organizations looking at what other successful companies were doing. However, not all agile adoption was successful and not all cloud migrations went off without a hitch. Trying to get your legacy, waterfall based organization to be agile overnight was never going to be an easy ride, in much the same way as migrating in-house legacy systems onto a cloud provider comes with a number of practical challenges. With all these popular trends, it pays to research and assess your own readiness to adopt and adapt to the change that is being considered. DevOps is no different. While I’m personally an advocate of the many benefits that DevOps can provide to an organization, there are also scenarios where I think its adoption is likely to be too challenging to offer a practical solution in the short term.

Four Examples of Challenging Situations

These four examples highlight areas that would make the implementation of DevOps challenging, often for very understandable reasons. These challenges do not mean that DevOps should be dismissed out of hand. Rather, they help set an expectation of the difficulties that may arise and provide some thinking for how issues might be considered to achieve the best outcomes.

Command and Control Organizations

Looking at agile as a starting point, the value of trusting your teams to do their best, goes a long way to achieving the desired outcomes. That doesn’t mean trust in the sense of blind faith, but rather in building trust based off of successful deliveries. As the culture of DevOps is strongly aligned to the values of agile delivery, an organization should have a healthy level of trust in the people who develop and operate their systems if they expect DevOps to be successfully adopted. Ideally, you want your business to benefit from the “group thinking” that comes from clever technical people working together to improve delivery—through automation, baking in quality control and improving time to deliver. It is difficult to achieve this in a traditional top-down environment where a single person (or small group) is responsible for telling everyone else what to do. If this describes your organization, then expect to have some wider challenges and costs in terms of widening the decision making to get the best benefits of DevOps.

Thinking that Tools = DevOps

There is no shortage of amazing innovation in the tooling to support DevOps at the moment. From the ways in which code can be deployed, to the ways in which environments can be built and managed, there are dozens of really outstanding technologies to help digital engineers. The key here is that those tools facilitate the implementation of a good DevOps delivery. More important than any tools is a process that starts with the people doing the job. It may be that the tools themselves are a key reason why you were first alerted to DevOps, however, tooling by itself will not give you a DevOps culture. Instead, start with a problem that needs to be solved or a process that can be improved upon. Look at the engineers in the team who are asking these questions and those who are engaging in answering them. Next, try carving out some time for them to research and test their lines of enquiries and see where this goes. It may be that no new tools are required. It can also be that you find something perfect that doesn’t have the hype or marketing budget that other vendors are pushing behind their tools. Promoting collaboration, engagement and feedback loops creates a much better foundation to build your DevOps culture around.

EBOOK

The IT Manager's Guide to Continuous Delivery

Continuous Delivery allows you to get new features and capabilities to market faster and more reliably. This ebook helps managers understand the principles behind Continuous Delivery, explains the transition to a Continuous Delivery organization, and gives practical advice on how to start benefiting from the dramatic improvements Continuous Delivery provides.

Bureaucratic Organizations

As mentioned earlier, DevOps works well in work environments that promote and support healthy trust and empowerment as part of their broader culture. In highly regulated or controlled environments, regardless of the trust, the adoption of DevOps may be difficult and less beneficial where it doesn’t also come with empowerment. If the needs of the wider business put in controls that hinder, or actively limit, the ability for the IT function to be as effective as it can be, many of the speed related benefits of DevOps will be reduced. In turn, the benefits of adopting DevOps are likely to feel marginal. There may be very good reasons for having such controls, checks and balances in place, especially in highly regulated industries or those where security is a key focus in their offering. In these scenarios you may want a separation of interest between environments to fire gap different teams and functions. There may still be ways that DevOps thinking and the related tools can help, but the overall benefits will again be diminished.

Disconnected Delivery Teams

The very name “DevOps,” is a mix of development and operations, and promotes a culture that recognizes the benefits in allowing for these capabilities to work together much more closely to the benefit of the wider IT delivery. In situations where an organization has broken these into distinct units and has structured itself to continue working that way, DevOps is unlikely to deliver effectively. This may be especially true for larger enterprise organizations, where specialist capability (or technical) teams have evolved around large, business critical systems. Areas where this can be observed include complex ecommerce package implementations, workflow heavy asset management systems and monolithic backend packages. Often the specialist way in which these systems need to be configured and customised mean that they are not good candidates for integrating within a broader DevOps culture. Similarly, large organizations may have outsourced or partnered with a third party for part of a delivery or for the operations of their system(s). The nature of such contractual agreements means that it is difficult to promote cross-team collaboration without wrapping it in protective terms and controls.

Closing Thoughts

The fact that implementing DevOps in your organization may be difficult shouldn’t be a reason not to consider it. Instead of being put off by the challenges of implementing DevOps at scale across the whole IT function, consider where it can be effectively introduced. Over time, systems change, policies evolve and people move on. Starting small means that even marginal improvements can make a big difference to the effectiveness of the IT delivery function and establishes DevOps as something to be prioritized when the organizational appetite (or need) for change improves.