At the recent DevOps Enterprise Summit #DOES14 (http://devopsenterprisesummit.com) I was surprised to hear so little about the challenges and opportunities of working with systems integrators. Reality is that most large organisations work with system integrators and their DevOps journey needs to include them. With this blog post I want to start the conversation about it and let you in on my world, because I think this is an important discussion if we want DevOps to become the new normal, the “traditional”…

Let’s start with terminology – I think you will struggle with the culture change if you call the other party system integrator, outsourcer, vendor, 3rd party. I prefer the term delivery partner. Anything other than a partnership mindset will not achieve the right culture that you need to establish on both sides. I will talk about the culture aspect later in the post, but terminology can make such a difference, consider the difference between the terms tester and quality engineer.

A bit of my personal history to provide some context – feel free to skip to the next paragraph if you are after the meat of this blog post.
I have been working for a large system integrator for many years now and have been part of DevOps journeys on both sides – as the delivery partner (notice the choice of words ;-)) and in staff augmentation roles dealing with my own company and other delivery partners as a client. To use the metaphor used at #DOES14 – I am more of a horsewhisperer than a unicorns handler. And I wouldn’t want to have it any other way. That means my DevOps journeys deal mostly with Systems of Record (think Mainframe, Siebel, etc.) and yes once in a while I get to play with the easier stacks like Java and .NET. So my perspective is really from a large enterprise context and while it is sometimes tiring to see the speed we are moving at, it is a fascinating place to be in and gives you such satisfaction when you have success. Together with passionate people on both the client side and on my team, we have saved one client over 5000 days of manual effort per year or reduced deployment times from over 2 days to less than 3 hours at another client. This is amazing to see and I cannot wait to tackle each new challenge. One item on my bucket list is to drill open SAP and “DevOps-ify” it, just need to find the right organisation that is willing to go there. But enough about myself.

Working with Delivery Partners who develop applications for you
The elephant in the room is probably setting up the right contract with your delivery partner. This is not easy – Agile coaches will tell you that Fixed Price is evil, but if you go for a T&M model your delivery partner has no incentive to reduce manual labour as he gets paid for each manual step. I have seen both types of contract work and not work, so clearly it’s not the type of contract that makes the difference. But what is it then? The relationship and alignment of incentives and priorities will be important. I will talk about culture separately, so let’s look at incentives. One of the concepts that work reasonable well is if you can create a performance based incentive (e.g. measure the efforts for “DevOps service” baseline and then create an incentive for improvement, like sharing the benefit across both organisations. The SI will be happy to increase margin and the client saves money. A true Win-Win commercial construct.)

Another important aspect is culture. Don’t forget in your DevOps journey to consider the culture of your delivery partners and of the way your own organisation treats the partners. Too often outsourcing partners are not involved in the cultural shift, are not getting the communications or being invited to culture building activities. Try to understands what drives them, connect their DevOps champions with yours, give them the opportunity to provide inputs. And last but not least celebrate together!

The third aspect to consider is technical skills. It is not necessarily true that your delivery partner has the required technical skills available. Remember that you probably for a long time incentivised your partner to find staffing models that support a very low daily rate. this doesn’t change quickly and if you want to shift this you will have to address the need for technical skills and either create a structured up-skilling program or provide technical coaching from your side. Don’t just make it their problem, make it a joint problem and address it together including any required updates to the commercial arrangements. And as is true for managing your own team: assume positive intent and work from that basis.

Of course, if you don’t think the culture of the SI is DevOps aligned (and you as one client will not be able to change that easily, trust me) then you should look for a partner who is in it with you. Going in the DevOps direction is not always easy so you rather choose the right partner for the tricky path ahead of you. This is true for your Agile adoption and certainly is true for your DevOps adoption as well.

When to work with an SI in the DevOps team
Besides working with SIs who develop and maintain applications, there is also a case to be made for getting help from an SI to implement DevOps in your organisation. This is what I do for a living and I do think we can add real value. First of all, I don’t think you can outsource the DevOps implementation completely (at least I would advise against it), but you can create really mutual beneficial partnerships. What I enjoy about being an SI (okay that sounds weird), by working for an SI (that’s better) is that I have a huge internal network of people with similar challenges and with solutions for them. If I want to find the best way to automate Siebel deployments I have many colleagues who have been there before or who are doing it right now. Having access to this network and the associated skills can be very beneficial for clients. And if you setup the partnership right, both organisations can benefit. I have helped organisations setup the team, the processes and the platform and enabled them to operate it going forward. And nowadays with offshoring we can also be a long term part of the team to help with ongoing improvements. Reality is not everyone has the in-house capability to build this capability and getting a bit of external help can go a long way. If you want to do it all in-house you can grab a couple of coaches to augment, but if you want someone with skin in the game find a really good SI partner for your team.

I will stop here although there is more to be said. In one of my next posts I will focus on the inside view of an SI. What does it take to transition towards DevOps if you are fully dependent on your client in regards to process, flow of work etc. Is there something that can be done? I will tell you about one of my projects to give you an idea and to further the understanding of the role of an SI in the DevOps world.

Update 2016:
I have seen a bit more conversation about this now, the below links are worth reading if you want to know about a few more perspectives:
– Will DevOps kill outsourcing?
– The Year of Insourcing
– DevOps – The new outsourcing