You are here

What's behind the identity crisis in dev and ops teams?

public://pictures/Sachin-Ohal .jpg
Sachin Ohal, Sr Manager-Technology Office, Cognizant , Cognizant Technology Solutions

There's a lot of talk about how a DevOps approach to the software development and deployment cycle can help you run your IT organization more effectively and efficiently. From blog posts and online forums, to conferences and seminars—everyone is talking about DevOps. There are even enterprise IT consultants that can give you lessons on how to use DevOps to improve communication between your development and operations teams, fix defects in earlier phases of development, deliver on a continuous basis, and so on.

DevOps is finding its greatest success in smaller organizations where teams of people focused on smaller, one-off IT projects, rather than the enterprise as a whole. These teams tend to stick to themselves and work on sequential projects, and their projects don't scale up to the enterprise stage because they don't have to.

But these smaller organizations aren't where DevOps adoption will make a huge difference. That difference will be most pronounced in larger organizations, which compete daily for customers with increasingly fast software release cycles. These organizations need more clarity regarding team roles, better communication, and the willingness to break old habits that only cause confusion in the faster, agile-infused delivery cycle.

[ Get Report: The Journey to Enterprise‐Scale DevOps: Becoming DevOps Determined ]

Who's dev and who's ops?

Today, every company is an IT company, no matter the type of business. Whether you run a data-driven market analysis system or you build Android apps, you're an IT company. Banks, for example, with their increasing dependence on technology, employ far more IT staff members than they do financial analysts.

Development teams are under enormous pressure, thanks largely to the principles of agile development. The intense focus on constantly releasing products to market means that development teams have a limited understanding of enterprise operations and a limited concept of risk, causing them to act like operations and throw themselves into a never-ending release cycle. The concepts of validation, long-term strategy, and the business vision are ultimately shuffled off to the sidelines. This results in teams that can become so focused on the day to day that even major technological shifts can pass them by.

Meanwhile, the operations teams in these companies begin to act like development teams. They begin suggesting changes to the enterprise architecture and the production process based on issues they observe on a routine basis. Quick fixes are often applied based on this hasty input, only to have a rollback or hotfix take place the following day, when the solution that was just implemented is revealed to be the wrong one. The process repeats itself and generally gets worse over time.

In both cases, the development and operations teams are simply responding to what they see as part of their daily grind. There's nothing wrong with that on the surface; this "heads-down" mentality is something we all tend to fall in to as the pressure of daily deadlines starts to mount. But for these teams, the release landscape is something they begin to understand only from this daily development and testing perspective. In these IT organizations, there's rarely a risk assessment when projects are undertaken, and no change management capabilities when project requirements need to be altered.

[ Partner resource: Take Security Journey's first two white belt modules for free. ]

Beyond the dev and ops firefighting

Before we can see how DevOps can help a larger enterprise meet its goals, we need to see how the confusion described above affects other teams beyond the core of development and operations.

In the typical DevOps enterprise that has adopted agile methods, web app and mobile app releases take place on a daily basis, or on an hourly basis in some cases. The development team pushes hard. They become the example for other teams to emulate. But are these other teams ready to adopt this fast-paced mentality? Can your enterprise architecture team really release on an hourly schedule? How about the network infrastructure team? Or the security team?

Many companies are proud to say they utilize best practices to ensure this kind of crunch and squeeze doesn't take place, but my suspicion is that an honest assessment of these teams would prove otherwise.

It's easy enough to find out. Ask the members of your security team how many times the development and testing team involved them in the early stages of product development and asked them to verify code or validate application logic from a security standpoint before the product was released. Similarly, ask the networking team when it was last involved in the development process at this stage. Most of you will find that these teams have never once been involved in the early stages of development, or at best they've had minimal involvement in only a handful of projects.

Poor assumptions

The reason for this is that the development team makes the (often wrong) assumption that the code being produced is acceptable to all IT stakeholders. When operations validates the code, it simply tests the scenarios that the development team has laid out. The two groups feed off each other, which causes a vicious circle to develop inside a vacuum where the rest of the organization is excluded.

Consequently, the security, networking, and other critical teams have no idea what's going on until the product is released. At which point they start receiving emergency calls from the network operations center (NOC) and service desk to troubleshoot a product they had no hand in developing.

DevOps is about true collaboration

The solution is obvious, albeit not easy: Get development and operations teams—the very literal definition of DevOps—to work together more efficiently.

How? It starts with a vision from the top and requires creating a dynamic infrastructure that improves collaboration. Here's a three-step process on how to start heading in that direction.

  • Leadership must set the tone. Managers have to set the stage from the business unit level. Managers must connect their business units on broader topics: What are the big ideas or problems the company wants to take on? What is the overall business strategy? When managers collaborate on big ideas at a high level, this shows a serious commitment to the cross-functional concepts of DevOps and encourages that kind of collaboration at lower levels of the company.
  • Develop real-time communication capabilities. Everyone watches cable news tickers, but organizations never seem to have capabilities like this that allow for instantaneous information dispersal. How does information get disseminated within a company in real time? Having a tool or process for this is essential in a successful DevOps environment, even if you have to create one from scratch.
  • Employees must take ownership of quality. Every business may be an IT business, but in reality many businesses contain multiple IT departments that function as independent silos. These groups need to take broader ownership and responsibility, something you can help facilitate by empowering them. How? Trust your employees to make good decisions. Give them open access to the resources and knowledge they need, and then hold them responsible for those decisions.

The benefits of DevOps are greatest where large development and operations teams need to improve communications while focusing on their core strengths. Instead of colliding in confusion in their rush to achieve rapid release cycles, well-defined dev and ops teams work effectively not only with each other but also with security, testing, infrastructure, and other teams. Ideally, this new approach will be driven by strong leadership that recognizes DevOps as a key ingredient in their company's competitive future.

[ Webinar: Paving the Last Mile to Production: Putting the "O" in DevOps ]