Tag: startup devops

 A large enterprise has institutionalized an incredible number of processes. Their fundamental approach to IT has been built over years if not decades of experience. Their leaders may have grown up with these methodologies and approaches.

In this article I wanted to continue the thread I started in my last article about how different organizations adopt DevOps differently. The focus of this article will be on how enterprises adopt DevOps. I will also contrast it with how startups adopt DevOps, which was the focus of the first part of this article.

To recap the first part of the article, we discussed how startups are adopting DevOps. We stated that adoption occurs organically because of the nature of startups. Because they only start with a few people and they have little to no process, DevOps starts through the addition of tools. The founding developers or CTO will find tools to solve the practical problem of automating different aspects of their development, QA, or operations functions.

With so few resources, automation is critical. As a startup grows they add more people to the team and process becomes more critical. So, they extend Agile into other areas of their product development process. They become more intentional with developing a DevOps oriented team.

As the company continues to grow, DevOps is embedded into the culture. Hiring decisions are made based on whether a candidate understands how to be a part of a team practicing DevOps. The rest of the company starts to beat to the drum of rapid iteration, cross-functional integration, and increased automation. DevOps adoption in startups follows the tools, process, and then culture sequence.

Enterprises follow a different path, and so usually take a contrasting trail to DevOps adoption for a variety of reasons. A large enterprise has institutionalized an incredible number of processes. Their fundamental approach to IT has been built over years if not decades of experience. Their leaders may have grown up with these methodologies and approaches. Further, their entire business is beating to a certain IT drumbeat. Changing the beat throws everybody in the organization off.

There are also other major issues to DevOps adoption within an enterprise. Institutional resistance and inertia is a significant one. Change is always difficult to people. Some groups handle change better than others, but in any organization – especially a large enterprise – change needs to be orchestrated and worked effectively. Change in large organizations takes time and perhaps nothing takes longer than bringing people on board with a new approach. In addition to the personnel aspect, the organization has built strong, existing processes. Those have been over many years. Changing complex processes doesn’t happen overnight. Those processes have been built with internal and external customers in mind. Those customers expect their “solutions” delivered in a specific manner and timeframe. Accelerating that though DevOps may be great, but not if they aren’t on board and can accept the increased pace.

DevOps impacts the entire system of an organization. The system has been tuned to a certain speed and level of quality. Increasing the front end of the process will not necessarily increase overall throughput unless the rest of the organization can increase their speed in concert. In a startup, that system is generally small and contained. Most of the individuals, systems, and processes are contained and when the pace increases, the rest of the organization can react quickly or better yet the entire organization has been built with those expectations in place. Not so for a large enterprise.

 The startup approach of adopting DevOps through adopting tools, changing processes, and embedding into the culture, will be easily rejected by a large enterprise. Even if the IT organization can deliver much faster and does, the rest of the organization won’t know what to do with the completely different approach. Perhaps the rest of the organization will even continue operating at their pace while IT operates at a different one. While not catastrophic, it is not helpful either. As larger organizations think about the best way to adopt DevOps understanding this perspective aids in adoption. Enterprises have a much harder uphill climb when it comes to adoption, however, the rewards can also be monumental.

An enterprise’s journey into DevOps – if it is to be successful across the entire organization – starts at the cultural level. And, as we all know, cultural change in a large organization is perhaps the hardest step. Clearly the positive here is that the organization adopting DevOps will have an opportunity to perform far more effectively. Cultural change starts with the key stakeholders at the senior level creating a commitment to adopt this new methodology. Then that commitment needs to be evangelized through the organization. A top down edict doesn’t work just as a grassroots movement without senior level support doesn’t. It should be reasonably straight forward to bring those two groups together to build a shared commitment to moving to DevOps (or not). Note that large organizations can adopt and test DevOps in one of their divisions or smaller groups to understand how different the approach will be from their previous business methodology.

Once a shared vision is reached, some of the detail work can begin. As discussed earlier, a different pace of product development needs to be matched by a different pace of distribution, sales, and marketing too. Updating and changing processes is the step that makes this happen. How will development processes change? And, how do those changes impact existing customers both internal and external? Can the same approach to quality be taken or do new processes in development require new processes in QA? Security? Operations? All of these downstream impacts will need to be matched, reviewed, and changed. Changing processes that are upwards of decades old is also fraught with risk. Many of those steps exist for a reason. Altering them may have consequences that aren’t known to all. This is yet another reason why DevOps adoption doesn’t happen overnight at large enterprises.

Finally, as processes are updated and the cultural shift is largely underway, the IT organization can turn its attention to finding better tools. These tools need to match the processes built and, of course, the cultural style of the organization. This is why large organizations would be better served by deeply understanding their newfound processes before diving into tool selection or even purchases. Only after they understand their needs is it worthwhile to embark on deep tool selection.

As we said in the last article as well, we’ve shown this to be a serial process, and, of course, it is never so cut and dry, especially, in a large organization. There will be overlap, there will be things that happen out of sequence, there even may be areas that jump far ahead, but largely, the adoption approach takes on the character of culture first, process second, and tools third. DevOps can be transformational for a large organization with some even going so far as to say that a DevOps culture is a predictor of stock performance. Understanding how DevOps takes shape at a large organization will help those in other large organizations as well as the vendors and consultants supporting their efforts.