Monthly Archives: October 2014

DevOps and Outsourcing: Are we ready for this? – A view from both sides

At the recent DevOps Enterprise Summit #DOES14 ( 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”…

connect-316638_1280Let’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

Impressions from the DevOps Enterprise Summit 2014

I spent the last 3 days at the DevOps Enterprise summit here in San Francisco and wanted to share my thoughts with those that couldn’t come over here. Overall it was a great conference, especially if you consider that this was the first time this conference was organised. A few glitches, but that just made it more likeable. And I am sure it will be even better next year. And I have to admit that I hope not hear about horses and unicorns for a few days…

So what did I take away from the conference? Here are a few of the themes that were pretty common through the 3 days:

  • DevOps Teams – While there were certainly exceptions (most notably from Barclays), most organisations that spoke seemed to have a dedicated shared services DevOps team to focus on the tooling, governance and support of their DevOps platform. This is certainly my preferred approach as well and it was good to see that many organisation have made positive experiences with this. But it was also good to hear positive stories from organisations that have chosen a more federated approaches and to learn how they approached it successfully.
  • DevOpsSec – While obvious in hindsight, the frequent mentioning of information security as a critical element in the DevOps journey really brought this home for me. And as some of the speakers highlighted the ability to automated the compliance to regulations and policies is so powerful, that information security can actually be your ally in the DevOps journey and not a blocker. Great change of perspective for me personally.
  • Balance of Culture and Technical Practices – Not surprisingly a lot was being said about culture change and also about technical practices for DevOps. I think this balance is important and is good for us to keep in mind in our day-to-day as we sometimes get to focussed on only one side of the equation.
  • Internal Conferences – So many companies use internal conferences to spread the word and share experiences across the organisation. This is fantastic to hear and I am glad they are able to get the support for it as it can be hard to make a quantifiable business case for those as I know from experience.
  • Servers are cattle not pets – A lot was being said about the importance of having environments that are commodity and consistent, so that you can replace servers easily and reliably. Quite a few of the tool vendors were from a server monitoring, configuration management drift detection space as well. This clearly deserves more focus going forward.
  • Tooling – A completely non scientific impression is that certain tools are much more prolific than others in the DevOps toolkit, examples are: Jenkins, Atlassian tools, Git.
  • Measuring everything – Not really a new thought, but interesting to see how many of the organisations had good data to support their story. So important to get this right and use it to drill down on bottlenecks and cost sources.
  • Scaled Agile Framework – SAFe got a lot of positive mentioning by the speakers, seems to be widely adopted at large enterprises.
  • A few smaller takeaways:
    • Impact Score of Releases – I like the idea of measuring the impact of releases by measuring the sum of (number of Defects x severity). Brilliant.
    • Inverse Taylor Manoeuvre – Such a good name for self-enabled teams
    • Inverse Conway Manoeuvre –  A great name for addressing the architectural challenges that many of us face with existing architecture
    • Release notes as blog – Such a good idea to not send notes around but rather use a blog to document all release changes
    • Sprint Plan review meeting – A meeting after the sprint plan to get all relevant stakeholder across the plan (like Ops, InfoSec, Business). Great idea to test.
  • Favourite Quotes:
    • “Branches are evil”
    • “There is a right way to develop software (and DevOps is it)”
    • “We geeks don’t just like SkyNey – we want to build it”
    • “Cease dependence on mass inspection to achieve quality”
    • “Just talking nicely to each other does not delivery software”
    • “Time does not make software better”

A few things could be improved going forward in my opinion:

  • Many of the Enterprise Scale organisations were talking about their Web presence or Digital space, and only a few talked about the DevOps transformation for their Systems of Record. A better balance would be nice, to not only hear the positive stories and learn from the really difficult cases
  • One aspect that was only mentioned as a sidenote and by 2 or 3 speakers is the reality of working with many different vendors and systems integrators. How do you enable this multi-party setup for DevOps practices? Having been on both sides of that story, perhaps I should share my experiences next year…
  • The sessions were pretty much back-to-back and there was little time for Q&A and to ask informal questions. Perhaps a short break in between sessions or a more formal way to socialise with the speaker right after the session would be good. I have seen this very successful at other conferences.

And last but not least a shout-out to some of the outstanding speakers from the conference, if you get a chance check-out the recordings later in the week when they are available on the conference website at
– Gary Gruver
– Em Campbell-Pretty
– Jason Cox
– Mark Schwarz
– Owen Gardner
– Carmen DeArdo
– to highlight just a few, there were many more that are worth listening to if you have the time