In today’s fast-paced, ultra-competitive business environment, an IT department’s ability to successfully deliver business outcomes is intrinsically tied to product selection and its partnerships with vendors.

But when it comes to development and operations projects (DevOps for short) the requirements are amplified further still as success in this regard relies on reinvention across numerous other spheres, including IT culture, organisational structure, process automation, software development, and team collaboration.

Simply put, it’s a more complex scenario than a traditional technology project. This is a critical point in understanding why traditional product selection strategies should change when dealing with DevOps products.

IT executives and professionals recognise that transformation through DevOps practices should transcend mere product features; indeed, DevOps practices triggers transformation across people, process, culture, and organisational structure to drive improvements in business speed, quality, and the customer experience.

To reap the benefits of DevOps, IT executives and their teams must reinvent their product selection strategy by extending their analysis to include potential value that may reside beyond the capabilities of the product in question. And in line with this approach, the three best practices for mitigating vendor risk and increasing the rate of DevOps success.

The first of these best practices revolves around the fact that DevOps forces a continuous improvement cycle. As such, IT executives should analyse product capabilities from that point of view, asking questions such as: How will the tool integrate with legacy and new tool architectures? Will it support and enable the measurement and attainment of the technology and business metrics? What feature enhancements are planned for the future? How does the product work with security, operations, and development tools? And can it create a new integrated DevOps process?

Rather than considering product capabilities from a single functional domain, DevOps requires cross-functional thinking. This requires products that can be integrated with other functions and are capable of sharing multiple data sources and streams with multiple IT roles.

Features such as dashboards, interfaces, security, and IT operations integrations must all be carefully examined, while it is critical to consider how flexible the product is to changes in development or deployment cycles.

It is also important to recognise that DevOps processes often align with multiple functions across a development or operational domain, and can bring tremendous synergies for the business when collaborative planning occurs. To this extent, having a deep understanding of the customer persona can help shape how the improvement cycle might look over the short and long term.

The next best practice identified by IDC requires IT professionals to determine how a product can assist in accelerating changes in organisational culture, as this is a key motivation of the DevOps principle. Key questions to ask during product selection include: What business and technology processes will the product impact? Does the product require team collaboration across functions?

How does the product assist in driving sharing and reporting across teams and time zones? Does the integration drive deeper analysis and team building? Is there a single source of truth that the product can deliver and use to help identify or solve problems? Can both IT executives and staff teams view dashboards?

Cultural change requires a sense of urgency, strong leadership, and an understanding of both why people should change and what they stand to gain from doing so. A strong set of cultural traits across areas such as teamwork, collaboration, performance-based metrics and measurement, trust, and empathy are critical to any successful DevOps project. But what’s often left out of the picture is the linkage between the cultural traits and the products chosen to assist in driving the change that is required.

There should be a cultural undercurrent that supports the notion of delivering organisational impact through meaningful work, assisted through the use of new DevOps tools. A DevOps culture should exude high levels of patience, trust, ethics, and empowerment, while forcing a limit on waste and slow-moving processes that lack feedback mechanisms.

The third and final best practice for DevOps product selection requires IT executives to define the customer persona and gain assurances that the product can deliver on clearly defined and measurable business metrics: Who is the customer and what do they expect? How will the customer experience improve based on the product’s capabilities? Which processes impact the customer experience? How will the product deliver on business metrics?

Having a deep understanding of what impact DevOps projects will have on customers is a critical success point for each project. Defining the right metrics — for both business and technology — and assessing how each metric will impact the customer experience is critical. Products must be able to deliver on the required metrics in order for DevOps value to increase over time as more teams and processes become integrated.

By understanding who the customer is, DevOps teams can make a stronger business case by aligning the proper metrics that will deliver value in line with what matters most to the customer.

While there are many other criteria to consider when selecting a DevOps product, the above best practices enforce some of the foundational principles that the DevOps movement espouses — continuous improvement, IT cultural change, and a focus on the customer.

— The columnist is group vice-president and regional managing director for the Middle East, Africa and Turkey at global ICT market intelligence and advisory firm International Data Corporation (IDC) He can be contacted via Twitter @JyotiIDC