Enterprises with internally sourced IT operations typically struggle with typical tensions associated with siloed application and infrastructure organizations. They are characterized by finger pointing and an inability to restore operational capabilities under complex conditions that span both application and infrastructure configurations. These tensions often are used to characterize the need for a DevOps movement, which focuses on organizational, process and cultural changes needed to bring about a more fluid IT delivery that embodies higher quality and greater overall agility.

Large- and mid-sized enterprises that have multi-sourced IT environments also struggle with these same tensions, but they are magnified by the fact that IT outsourcing contracts written in the past 15 years barely scratch the surface for how vendors should work together in the face of failures or broad-sweeping changes. At least for in-sourced IT groups it is understood that any impact to business operations could very well be met with severe penalties including job loss. In the case of outsourced IT, as long as the vendor is operating within contractual boundaries and meeting service levels agreements, penalization becomes much more difficult.

Hence, practicing DevOps in multi-sourced IT environments should be a fundamental driver of Service Integration and Management (SIAM) activities. Yet, it seems that the majority of SIAM implementations focus on continuance of traditional tower-based (read siloed) approaches to IT delivery highlighted by managed communications handled through controlled gateways characterized by a loosely-federated group of ticketing systems and limited collaboration across the towers. In other words, the exact opposite of what DevOps prescribes as the cure to limited agility and low-quality delivery within IT.

In a fully-realized DevOps multi-sourced IT environment service levels should encompass responsibilities to participate in “cross-tower” activities oriented toward restoration of services as well as planning and deployment of new services. For example, if Vendor A is responsible for application development and Vendor B is responsible for infrastructure then Vendor B should actively participate in design and planning of the application with Vendor A exactly as would be expected of in-sourced IT departments delivering these same responsibilities.

There is some thinking that as Vendor B starts to deliver infrastructure-as-a-service that continued non-integration of towers will become less problematic. After all, if infrastructure is sourced from Amazon or Microsoft, then it is assumed that these vendors would not be a responsible party in the activities associated with failure or insufficient capacity.

This thinking is flawed in situations where a vendor is providing privately-hosted IaaS as part of an outsourcing agreement unless the expectation is that all responsibility for ensuring availability, security and other –ilities for the application are being pushed left onto Vendor A. Yet, even in this case, Vendor B could not deliver an economical privately-hosted IaaS solution without limiting oversubscription on capacity, which would require that they are an active participant in the capacity requirements in advance of demand.

Moreover, in the case of private IaaS, the enterprise would want some assurances in the face of a failure of the infrastructure, which has occurred to all major IaaS vendors, which would be too high of a risk for an outsourcing vendor to sign up to without pricing the service at a point that would make it an untenable choice.

Physical infrastructure is only one example to be considered as many organizations also multisource database and middleware operations to one vendor, Vendor C, and application delivery to other vendors. Here again, we have seen how Vendor C limits agility of the application delivery by forcing activities to go through the SIAM layer to addressed. For example, the application delivery team may want to create a test environment that would require Vendor C to configure and setup application infrastructure. Since most SIAMs focus more heavily on operations than development and test, these requests are given lower priority, and thus, the process of making the environment available could take weeks instead of hours. This has a dramatic impact on the enterprise’s ability to leverage continuous delivery as a competitive differentiator.

In conclusion, SIAM that is not aligned with DevOps philosophies and continuous delivery as passé before they even get implemented. Enterprises that engage in multisourced IT delivery need to re-evaluate their contracts to ensure that there are identified responsibilities as part of their service levels for working with other vendors to ensure continuous delivery metrics established at the SIAM level. This is going to require a whole new level of collaboration and communications that go far beyond ticket-based systems and that ultimately limit the potential to develop strong multisourced collaborative efforts.