DevOps processes flounder if old business models don’t change

Source – theserverside.com

Many of the mental models often used for thinking about DevOps processes came from the manufacturing industry. But if you ask Mirco Hering, the Asia-Pacific Agile and DevOps lead at Accenture and author of DevOps for the Modern Enterprise, he’d say a different mindset is required to make DevOps processes work for enterprises today.

Hering asserted that the fundamental problem lies in thinking about DevOps processes as part of a transformational model that runs for only three to five years. Once a DevOps program gets to an end state, the organizations reduces its resources and begins to accrue technical debt. The cycle then repeats. “Companies like mine make a lot of money doing this,” Hering said.

Better DevOps processes
A much better approach lies in thinking about DevOps as a move to an ongoing process. Developers and managers need to realize that the tools and methodologies they’re using today will be replaced when better ones come along. This thinking can lead to a more gradual evolution of enterprise performance that’s stable.

When organizations can appreciate that there is no finish line, this changes the way developers and managers think about the architecture and tools. Hering suggests companies should pursue a strategy of anti-transformation transformation. “Agile or DevOps is not something you can do. It is a journey,” Hering said.

The three dimensions of DevOps
Software development managers need to consider three interlocking dimensions when adopting DevOps processes:

technology architecture
organizing and managing knowledge work in IT
ecosystem of vendors and applications

Changes need to be made to the technology architecture in a way that accounts for the holding costs and transaction costs of using both existing and new applications and infrastructure. The transaction costs in software development relate to everything involved in releasing new apps, including governance processes, environment and testing. Many companies are pursuing smaller batch cycles, but are doing so with a governance process built for nine-month release cycles. “You need to think about everything that goes with transaction cost so that you can reduce that over time,” Hering said.

Governance costs are a thorny issue. Many development teams still create PowerPoint documents for management. In larger organizations, these get filtered and edited down for upper-level management, to the point where these refined status reports don’t give management insight or value.

A much better approach lies in using data about software projects to automatically generate real-time reports tuned to the different layers of management. This means normalizing the data to some standard metrics that can be used across projects to make it easier to view outliers. This makes it easier to identify projects that management needs to consider.

Developers are humans, not just resources
When adopting DevOps processes, it is also important for everyone in an organization to understand how these efforts are improving overall software development agility and quality. Hering observed that many software developers build apps as designed, which doesn’t ultimately provide business value. To address this problem, organizations need to bring people together from across the software development lifecycle to talk about business challenges. This can give developers the right context to build features that are in better alignment with business goals.

It’s also important to think through the economic implications of automation. It’s much easier to automate simple IT processes like password resets and deployments, which are typically done by more junior and less expensive IT workers. This has the net effect of increasing the ratio of creative work done by more experienced and expensive IT workers.

Where do human factors come in though? DevOps processes can affect metrics that have been used to measure software development and remediation performance. For example, a metric like “mean time to restore services” may go up with a more efficient process. Automation is much easier and more commonly used on the kinds of problems that developers could quickly fix. As a result, more time is left for the more creative and time-consuming problems that are difficult to automate. But these kinds of problems end up increasing the mean time to resolution, even though the overall software infrastructure is failing less frequently.

Bringing DevOps thinking to partnerships
Enterprises need to consider the ecosystem of products and services that support their DevOps processes. The danger is that business and technology managers will pursue relationships that hamper DevOps strategies. A true DevOps strategy requires a willingness to experiment, and some experiments will fail. But vendors are often penalized for failures.

“The contracts in place prevent people from trying new things,” Hering said. “To address this challenge, managers need to develop a relationship with partners that allows some kinds of failures that don’t kill the business.”

One of the big problems in vendor selection today has been a focus on overvaluing features and undervaluing engineering. Software development managers need to place more emphasis on ensuring solutions support capabilities for autoscaling, self-healing, monitoring and changeability. And that really is the key. If organizations want their new DevOps processes to work, they need to be prepared to abandon the old business models that weren’t working and embrace new strategies for continuous delivery, continuous integration, automation and DevOps principles.