Tag Archives: does15

Impressions from DevOps Enterprise Summit 2015

Leave a reply

2015-10-21 15.13.19The theme of conference was so nicely summarised by Jody Mulkey from TicketMaster “DevOps is not a technology problem” already in the morning of Day 1.  Most talks covered the cultural aspects of DevOps and what good looks like and what it takes to transform the organisational culture. Some of my takeaways to try at home to shift culture are:

  • Blameless Culture
  • Value Stream mapping
  • Minimal Viable process
  • “Red Tape Removal teams”
  • Internal Conferences/Hack Days and other avenues for informal learning
  • ChatOps as communication channel

The other topic that came up again and again was: Metrics. Everyone is looking for ways to measure progress and justify improvement investment. This certainly validated the efforts of a working group before the conference. The working group put together a paper on measuring DevOps which you can get access to here http://devopsenterprise.io/media/DOES_forum_metrics_102015.pdf I was part of the team and have to thank everyone involved for a great experience and amazing support from the team at IT Revolution.

As part of the Unconference there was a very lively discussion about metrics. I think there was some level of consensus about a few points:

  • There is not one measure to rule them all, you need multiple dimensions for steerage
  • The metrics in focus shift over time
  • You should use the scientific method and drive improvements through hypothesis and validation

There was consensus that DevOps is not a goal – “are we there yet?” is not a valid question. Jason Cox summarised it nicely in his talk: “Keep moving forward with curiosity”. That is the spirit of the conference and the overall DevOps movement.

Technology wise – I think the practice/tool that stuck with me most was ChatOps. This seems to have broken into many organisations and is a tool to change culture and the way collaboration works.

Some highlight talks for me were – and there were so many more (!):

Jason Cox – Disney: Okay as a geek it would always be hard to trump a talk that is full of Star Wars references and shows the latest trailer. But besides this he is just great in giving insights into the Disney org and how to leverage the unique company culture for the DevOps movement.

Adrian Cockcroft – Battery Ventures: A fantastic talk about systems thinking applied to organisations. Fascinating insights into the cultures of companies like Netflix. So many ideas in the talk that it requires hearing it a few times to catch it all.

Damon Edwards – DTO solutions: This talk brought everything together what we heard throughout the conference. The summary slide shows the learning organisation, the measures, the idea of a journey not a goal to reach:devops-kaizen-practical-steps-to-start-sustain-a-transformation-42-638

Jez Humble: This talk one of the most interesting metrics for DevOps progress and success: Number of manhours required outside of business hours for a production deployment – the goal needs to be 0. Overall great talk about the architecture concerns for DevOps. Its an unsung truth that architecture plays a huge role in DevOps and is difficult to change.

Steve Spear – High Velocity Edge: About leading a learning organisation. He demonstrate with examples very well that leaders have to have the courage to lead from the front in regards to learning and acknowledging that they don’t know everything. The other takeaway was the rigorous adoption of the scientific method in all aspects of the organisation and the example of Toyota showcased how such an organisation destroys the competition.

Josh Corman & John Willis: An insightful talk about vulnerabilities in software and the importance of taking this serious, not just to save money, but to save lifes!

Topo Pal – Capital One: Topo’s point of Capital One contributing their tools to open source for the community was a powerful statement. We can all benefit from being more open and sharing more with the community. Thank you Topo.

Rosalind Radcliff – IBM: Educating us on what is possible with Mainframe. One of the few talks about “legacy” and really insightful that modern delivery methods are absolutely possible with the mainframe.

Mark Rendell – Accenture: Talking about the role platform applications play in solving the organisational structure challenge of scaling DevOps.

What did I get most value out of you wonder?

100% the discussions with people in the hallway, with fellow speakers, with all the people who are on the journey with me. Looking forward to make the next steps together and share our stories again next year.

Favourite Quotes:

  • “Motion != Work” Jason Cox & Jez Humble
  • “We cant copy Netflix because it has all those superstar engineers, we don’t have the people” Fortune 100 CTO —- “We hired them from you, and got out of their way” Adrian Cockcroft
  • You are either building a learning organization…or you are losing to someone who is – Andrew Clay Shafer requoted in USPTO session
  • “We are open sourcing our tools because it is the right thing to do.” Topo Pal, Capital One
  • “Buoys, not boundaries.” Ralph Loura, HP Enterprise
  • “Too much planning means you miss out on opportunities to learn and adjust.” Gary Gruver, co-author, “Leading the Transformation”
  • “We have horrible hygiene in our software supply chain” – Josh Corman, Sonatype
  • “I am in this (DevOps) to save lives” – Josh Corman, Sonatype
  • “We had Schroedinger releases – until it was in production we didn’t know whether it was dead or not” – Elisabeth Hendrickson
  • “Project based teams accrue technical debt, product or platform based teams pay it down” – Adrian Cockcroft

What I want to see more of next year:

  • People talking about managing vendors and systems integrators
  • Experiences with learning cultures and how the experiments went
  • Even more discussion on bridging the chasm to the organisational majority

Cultural references/Running Gags:

  • Lots of Star Wars references – aren’t we all looking forward to Christmas? How fitting we had Jason speak again.
  • Volkswagen gags were also popular

DevOps for Systems of Record – A new hope (Preview of DOES talk)

2 Replies

(This post first appeared on DevOps.com – Link)

I am speaking at the DevOps Enterprise Summit later this week and thought I give people a teaser of what I am going to talk about, so that you know what to expect. I am looking forward to share my story – a story of adversity but also of hope – with many of you. ( A recording of it is available here)

So we have all heard about the DevOps and Continuous Delivery stories from our favorite Web companies (Google, NetFlix,…). It is much harder to come across successful case studies with Enterprise-grade Systems of Record. While I cannot provide the 50 times a day deployments for SAP (yet ;-)), I wanted to share my story so far and what I have learned in the journey (both in regards to solve and unsolved issues).

Hopefully this contribution to the discussion helps some of those out there who are looking for a first step. But why should we even deal with COTS and other systems of record? Ultimately for me this comes back to the two gear analogy that I keep using. If you can just ditch your “legacy” applications completely, then congratulations you don’t have to deal with this and can probably stop reading this blog post. For all of you out there that cannot do that, you will be confronted with the reality that even though your digital and custom applications can deliver at amazing speed you are still somehow constraint by your “legacy” applications. Hence speeding up those will help you achieve the ultimate terminal velocity of your delivery organisation. So how do I approach Systems of Record and the DevOps adoption of it

3 Key steps:
1. Look under the hood to find the ingredients
2. Recreate the IKEA manual
3. Understand the path to production

DOES1

  1. Initial Discovery – Let’s open the hood

DOES2Ultimately the two things that I am always looking for are the moving parts of the application and the processes to build and deploy the application. Sounds easy, right? Well it often isn’t as especially COTS application try to abstract those processes away. Look at SAP where you make configuration changes in one environment that then somehow get transported to other environments, but you have little visibility into the underlying process (Ok – my SAP experience is 10 years old, so it might have changed, but you get the gist).

Why do we look for moving parts? Well we want to use the common software engineering practices as much as we can and don’t necessarily want to trust the inbuild features for version control for example. So we look for ways to find the source code files or ways to extract the relevant information in text format (well SQL, XML, etc count as text in my world view), this is sometimes relatively easy (Siebel .sif files are just a type of XML for example) and sometimes it is pretty difficult or impossible. These underlying files is what we will store in source control to make sure we understand at each point in time the configuration of the application.

Once you have found the source code, you will have 3 things to do:
a) Get it out of the proprietary solution
b) Integrate it with your IDE
c) Solve for Merges
(I will explore this further in another blog post later)

Part 2. Recreate the IKEA manual
DOES3Once you have all the moving parts, you need to understand how it all fits together. Custom Application usually require explicit instructions which makes it much easier to define and automate the instruction set. For systems of record packaging and deployment is often done through UIs and there is usually more than one way of doing it. Experienced operators have found their own short cuts and the reliability of the system depends on having the right guy in the operating centre (I have some stories to tell about not having the right guy on go-live weekend).

Your goal needs to be an “Ikea Manual” that creates the system from the moving parts we identified earlier without requiring complex interactions or decisions from human operators. Ideally all instructions work from the commandline or some programming API, but when all else fails a UI driver like Selenium can solve the really tricky parts of creating and automating the manual. Every black-box step should be drilled open so that you understand what is happening within the system and so that you understand the variations that could cause you trouble down the path.

Part 3. Understand the Path to production
does4Speaking of paths…Of course for systems of record the same rules apply as for any other system. You should practice the exact things that you will do to establish the system in production in all previous environments and minimise the difference between configurations. The challenge for systems of records is often the cost associated with production like environments So you might have to look for creative ways to minimise the difference and to parameterise configurations so that you can at least automate for the differences.

So all is good in Mirco’s land of the systems of Record?
Unfortunately not, there are still many challenges that I am working on. The progress we have made so far, allowed for a step change in velocity and reliability, but there are still areas that I want to find better solutions for:

  • Unit test automation
  • Unsupported activities or no API
  • Performance
  • Configuration Management skills – the curse of the configurators
  • Common Objects
  • Operations – the last mile…

I will speak at much more detail about my experiences at the DevOps Enterprise Summit, if you are attending, come say Hi. I am always happy to show you the scars of working with Systems of records and share war stories.

And for two “legacy” technology stacks that I have done extensive work for (Siebel and Mainframe ) I promise to write more in-depth blog posts in the future.