IT managers have long bemoaned the tension between "change-the-business" (development) and "run-the-business" (operations) IT teams and their \n\nactivities. In fact, most organizations suffer this curse, and stereotypes that reflect this animosity abound. Ops people, for example, envision dev \n\npeople sitting in their ivory towers cranking out code all day and wanting to release applications oblivious to real-world constraints. On the other \n\nhand, dev sees ops as cog-turners ensuring that the IT infrastructure doesn't break under the strain of poorly written code. These stereotypes exist \n\nbecause 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 \n\nbeen 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 \n\nbusiness. 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 \n\ndevelopment, infrastructure and operations, and quality assurance; with the functions working together to produce fit-for-purpose and timely \n\nsoftware products and services.For DevOps to work \u2014 and it must \u2014 I&O teams must accept that 1) the sibling rivalry between app dev and IT ops ultimately hurts \n\nthe 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 \n\nbegin to build a tighter relationship with dev groups by considering the following six actions:\n\n1. Change your change management\nOps has a reputation for resisting change because everyone \u2014 ops, dev, and the customers themselves \u2014 have come to believe that \n\nchange is bad. Service failures are often attributed to changes, so if fewer changes are executed, fewer failures will occur. This ridiculous association \n\nonly tells us that our change management process is flawed, often profoundly. However, if you can prove the seemingly contradictory goals of discipline and speed, dev professionals will come to respect your ops group as \n\ntheir partner, not an annoying impediment. As noted, many ops groups have change management in place. Ensure that the process is being executed \n\nconsistently. Any changes performed outside the process should be identified and rectified immediately. Without execution compliance at or very \n\nnear 100 percent, changes will continue to be risky and dev discontent with ops will persist.\n\n2. Communicate more often with the app dev group to increase its knowledge of operations\nTo improve understanding, reduce prejudice, and improve perceptions, IT teams need to get better at communicating successes to the business and \n\nto other IT groups. Aim to adapt work practices to ensure greater exposure between IT silos and greater collaboration on new IT initiatives. This \n\ncollaboration not only helps gain buy-in, but also improves the quality of the solution. App dev to IT ops integration benefits, but so does the \n\nbusiness because delivered IT services are far better. \n3. Educate app dev on the evolution of I&O as a services-centric organization\nI&O leaders should extend ITIL and IT service management education and training to app dev and enterprise architecture in the context of why it's \n\nimportant to them and to the business service life cycle as a whole. With the 2007 introduction of ITIL v3, the framework is no longer ops-centric. It \n\nexplicitly accounts for all phases of the service life cycle, including those driven and fulfilled by dev. This isn't intended to be brainwashing, but more \n\nof an introduction into modern thinking around IT delivery to meet business needs. The right approach will compel dev to desire a role in ITIL and not \n\nfeel they're being forced into it.\n\n4. Consider app dev as "service dev"\nWhile a shocking and likely offensive statement from some app dev perspectives, the development of applications is ultimately a subcomponent of \n\nthe overall IT service. Sitting alongside service design activities, any written code is ultimately part of a more broadly defined IT service that gets \n\ndelivered to the rightful consumers of that service. I&O execs should therefore build on the aforementioned educational activities to position the \n\nsomewhat isolated app dev role into a more central service dev role. Instead of isolating dev group members as the narcissistic "them" who look \n\ndown on "us," embrace this team as partners in providing relevant services to your joint customers. Key service metric monitoring and liberal use of \n\nfeedback mechanisms will need to be in place to ensure that mindsets, and resulting behaviors, are actually changing.\n\n5. Understand and manage the diversity of views on IT delivery\nThere are reasons why some of us love to work in app dev and why others gravitate to the logical demands of programming. However, this isn't an \n\nexcuse for not working together for the good of the business. Senior management needs to ensure that there is a better mix of skills and \n\npersonality types within IT functional groups. Review people management and development processes and frameworks in conjunction with HR. This \n\nwill identify issues and gaps in IT people and their knowledge, skills, and development. \n\n6. Integrate I&O's mission statement with the business\nStop repeating the IT-to-business alignment mantra and get on with making IT a crucial business enabler and a valued strategic partner. IT doesn't \n\nalign with the business; IT is the business! To this point, IT functional groups need to explicitly understand how their work fits in with the broader \n\ngoals of the business. Start by abandoning the nebulous and ill-conceived alignment and become integrated. Revisiting the original 20-year-old \n\nmission statements (if you still have them) will also be an eye opener in terms of how far I&O has evolved in the last two decades. There should be \n\nno I&O employees, just employees of and contractors to the business that provide technology-enabled capabilities to the business.Stephen Mann and Glenn O'Donnell are senior analysts at Forrester Research, where \n\nthey serve Infrastructure and Operations Professionals. They will both be speaking at Forrester's upcoming Infrastructure & Operations Forum, November 9-10, in Miami, \n\nFL.