Event Observations From DevOps Enterprise and Bank Of America / Merrill Lynch Technology Innovation Summit

October 24, 2014

by Evan Powell

This week’s DevOps Enterprise Summit 2014 (#DOES14) and Bank of America / Merrill Lynch Technology Innovation Summit (#BofAMLTech) have both been great experiences for StackStorm. In this blog I’d like to share a couple of observations that may be of broad interest.

1. Soft stuff being addressed:

DevOps is about much more than tools. It is fundamentally about a better way of designing, building and operating technology. It all comes down to people working better together as a team. That much we all know.

So I was not surprised when many speakers mentioned the above points. I was, however, somewhat surprised that Bank of America, Barclay’s, Target and many other organizations said they are successfully addressing both the quality of their teams in terms of training and expertise and the ways that they are being convinced or at least encouraged to adopt a better way of working. In the case of Barclay’s, Owen Gardner did a great job speaking about the need to get thousands of teams working in a more agile, DevOps friendly way and how this ruled out a just incremental approach since if you trained 50 teams a week you’d never get there. In their case they engineered an ingenious process to basically “infect” (my summation) the teams with DevOps.

I see the up front confrontation with people issues as the strongest possible confirmation of DevOps’ growing maturity, as it is always the people issues that stand in the way of real adoption. So it is a great sign that relatively conservative organizations have already encountered, embraced and started to address the tough soft issues of DevOps transformation.

2. Aspiration still far exceeds execution with DevOps approaches.

On the other hand – both Owen Gardner from Barclay’s, Steve Brodie of Electric Cloud, and many others pointed out that there is a real difference between where enterprises think they are and where they really are in the transformation. For example, almost every organization says they are doing agile development – but are they really? Do they actually sprint to a delivery to a user? Perhaps there is even a greater divergence between those that say they are doing Continuous Delivery and those that are actually continuously delivering or deploying software.

In short – if we don’t define success upfront and rigorously evaluate our progress versus objective benchmarks, we risk claiming success well before actually reaching the finish line.

3. DevOps is becoming a dirty word

Along those lines, Target and other impressive organizations talked about how their progress in getting adoption accelerated once they stopped calling what they were doing DevOps. I am not sure what to think about this. Should we as a community call it DevOps anyway, even if the most conservative in our organizations will fight us even stronger? Or should we do whatever it takes to get adoption and not worry about “free riding” on the community by using their best practices without giving them credit? What are your thoughts?

So those are a few highlights.

I’m also really, really excited about a bunch of new StackStorm users who got excited thanks to conversations over the last couple of days. There is clearly a need to better “wire together the legos.” And our approach is resonating with some amazing operators.

Gene Kim (@RealGeneKim) and the entire group that put on DevOps Enterprise deserve a lot of credit for a solid program that did have substance and lessons learned in it as well as being really “about the horses” as opposed to just the unicorns. I will link to the talks once they are published here. Many will be worth reviewing.

Finally, I tweeted a few trenchant observations from Gene’s talk at the SF DevOps meetup last night. It was a blast to see him and many other practitioners at the meetup which was also an after party for Enterprise DevOps. You can see my slides – expedited ignite format – here; yes, they are supposed to be a bit funny and without delivery they are lacking something. However they are intended to give you some idea as to why StackStorm thinks there is a screaming need for yet another DevOps tool. I’ll talk more about that as we get closer to open sourcing November 3rd.

B0rrPyyCUAAmKTe