computerwoche.de

Archiv

How To Improve Collaboration with Development and Operations

15.08.2011
IT managers have long bemoaned the tension between "change-the-business" (development) and "run-the-business" (operations) IT teams and their activities. In fact, most organizations suffer this curse, and stereotypes that reflect this animosity abound. Ops people, for example, envision dev people sitting in their ivory towers cranking out code all day and wanting to release applications oblivious to real-world constraints. On the other hand, dev sees ops as cog-turners ensuring that the IT infrastructure doesn't break under the strain of poorly written code. These stereotypes exist because organizational behaviors do exaggerate genuine conflicts, and both parties must act quickly to change.

As IT organizations struggle to deal with the changing IT and business landscapes, the concept of DevOps (i.e. development and operations) has been singled out by many as the way in which infrastructure and operations (I&O) can work more efficiently with other IT silos to benefit the business. More specifically, Forrester defines DevOps as:

A set of processes, methods, and systems for communication, collaboration, and integration among the IT functions responsible for application development, infrastructure and operations, and quality assurance; with the functions working together to produce fit-for-purpose and timely software products and services.

For DevOps to work -- and it must -- I&O teams must accept that 1) the sibling rivalry between app dev and IT ops ultimately hurts the business and 2) IT is now a business expense rather than a business function. While both parties must transform their behaviors, I&O leaders can begin to build a tighter relationship with dev groups by considering the following six actions:

Ops has a reputation for resisting change because everyone -- ops, dev, and the customers themselves -- have come to believe that change is bad. Service failures are often attributed to changes, so if fewer changes are executed, fewer failures will occur. This ridiculous association only tells us that our change management process is flawed, often profoundly.