At the very time that the IT department’s contribution to enterprise business goals is increasingly being questioned, more and more conflicts between IT operations and application development teams are surfacing.

While such conflicts are certainly nothing new, they are becoming both more frequent and more intense as organisations increasingly ramp up their critical investments in the sort of emerging software technologies that are now essential for driving competitive advantage.

One new source of conflict is the rising number of agile implementations that IT teams are employing in an attempt to reduce the delivery time of software applications, using larger numbers of small changes in deployment to production.

Unfortunately, it’s no surprise that this approach within the deployment life cycle also creates unexpected disruptions to the stability and reliability of existing IT infrastructure, which inevitably leads to conflict.

If IT exists to advance business goals, and the IT department’s raison d’être is to get new technology and business automation into action faster and more efficiently, then resolving the conflict between IT operations and development teams becomes a business imperative.

It is with one eye on alleviating the potential for these conflicts to arise that many organisations are increasing their focus on development and operations (DevOps) as a viable application design and development process.

But that is not the only reason. Indeed, growing corporate mandates for IT departments to decrease costs, reduce staff, increase efficiency and innovation, and align more closely with the business have all contributed to the emergence of the DevOps movement. And while DevOps can accelerate the application design and development process, it also accelerates application delivery through collaboration with the people, processes, and tools responsible for IT infrastructure.

DevOps methodology involves the efficient repetition and automation of development, testing, and operational IT tasks. But at IDC, we recommend that IT departments focus less on defining how DevOps is different from the status quo and more on identifying the principles of DevOps that can accelerate the delivery of meaningful business results in a measurable and lasting way. Simply put, DevOps should increase the volume, rapidity, and value of new business applications — as perceived by the business decision maker, not the IT department.

To this end, effective DevOps requires all essential personnel — both IT and business — to connect effectively at the earliest design stage and stay focused on the application’s contribution to the business through delivery, maintenance, and code optimisation within the organisation’s overall IT infrastructure. That’s because the key point of DevOps is that all stakeholders must be trying to achieve the same thing the delivery of top-quality, reliable software solutions that facilitate tangible business benefits for those who use them.

This approach represents a significant change, but it is necessary in order for IT departments to move forward, survive, and become the IT service providers of choice for their business customers. And while this kind of cultural change can be initiated from a bottom-up approach, true success requires not only the CIO’s theoretical support but also his/her active encouragement, sponsorship, and monitoring.

The considerable buzz we are seeing around DevOps has created an emphasis within the IT industry on the critical need for collaboration and automation of code and infrastructure deployment. Unfortunately, in the rush to break down the wall between development and operations, the third (and most crucial) perspective — business value — is in danger of getting short shrift. Indeed, IDC research shows that 35 per cent of IT projects fail because business executives change priorities or don’t have stakeholder ownership in IT projects. Unfortunately, that’s the inherent risk of inappropriate DevOps implementations.

To insure against that threat, IDC believes there must be a greater focus on ensuring that business users become a third, and stabilising, leg of the DevOps foundation of achievement, sitting alongside the development and operations teams as equal partners from the earliest possible stage. Without this third leg, the DevOps effort will become yet another IT project or process that becomes mired in technology jargon and accountability metrics that are not understood or accepted by the business community.

IT teams must also remember that the vast majority of their customers (ie, the business end users) simply don’t care about how the IT department does its job; they just care about how technology can have a positive impact on business outcomes. Indeed, business unit heads are typically only interested in how technology solutions can help them to generate revenue, increase profit margins, improve customer relationships, drive sustainable competitive advantage, reduce distribution costs, or enhance supplier contributions.

And just as a sales executive doesn’t want to hear the marketing department’s excuses for poor-quality lead generation, the business executive doesn’t want to hear the issues that prevent IT development or operations from delivering reliable, innovative technology solutions to business problems in a timely fashion. Implemented properly, DevOps removes that discussion from the table, helping to build a bridge between IT development and operations that will ultimately benefit the business as a whole.

— 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