Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

The truth about "You build it, you run it!"

4.156 visualizaciones

Publicado el

In this slide deck I try to explore the meaning of the often misinterpreted sentence "You build it, you run it". Starting with its origin in a 2006 interview with Werner Vogels and a short description of the misinterpretation of that phrase that can be seen quite often these days in companies that try to pick up concepts like DevOps without really getting the idea behind it, I then start a bit longer journey.

It starts with the history and evolution of markets and IT. Based on that I dive deeper into the effects of uncertainty which these days is often predominant for companies facing narrow and highly dynamic markets. I try to approach from a financial point of view as well as from a risk management point of view (yes, even if we have become agile, managing risk and financial aspects have not gone away).

The basic result is that we need to go faster (in terms of cycle times) without compromising quality. I also add a quick litmus test to figure out where your own company currently is located as reality never is as simple as a slide deck - to avoid turning a thought model that should support reasoning into a dogma.

Having the task set and understanding that IT must support going faster without compromising quality, I look at DevOps as it targets exactly the same goal. After a short explanation of what DevOps actually means (we face a perfect confusion of ideas when talking about DevOps) and what the effects are if you do it seriously, I focus on the effects for the process organization.

The traditional process organization - while usually being set up nicely for cost efficiency - is very poor in terms of cycle times. In order to shorten cycle times those organization will eventually become cross-functional, autonomous teams with end-to-end responsibility. And while those teams have all skills and the full authority for all their activities, they also need to take over the full responsibility for their actions - their is no one left to blame ;)

And this naturally leads to "(You decide it,) you build it, you run it" which in the end is a required organizational prerequisite for going fast in a DevOps way.

There is a lot left out in the slides that would also be worth talking about (after all it is just a 60 min talk) and of course the voice track is missing, but I still hope that those slides are of some value for you.

Publicado en: Tecnología
  • Sé el primero en comentar

The truth about "You build it, you run it!"

  1. 1. The truth about “you build it, you run it” Reframing the context Uwe Friedrichsen – codecentric AG – 2014-2017
  2. 2. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com
  3. 3. “You build it, you run it!” Where it comes from
  4. 4. ACM Queue, May 2006
  5. 5. “The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.” -- Werner Vogels in “A conversation with Werner Vogels” in ACM Queue, May 2006
  6. 6. “You build it, you run it!” How it is often misused today
  7. 7. Developer
  8. 8. “We finally found the ultimate weapon …“
  9. 9. “... to control you $%@&! developers“
  10. 10. “You build it, you run it!“
  11. 11. “You are so screwed!“
  12. 12. “Bwuahahaharrr!!!”
  13. 13. They got it plain wrong and have no idea what “You build it, you run it” actually is about
  14. 14. “You build it, you run it!” What it actually is about
  15. 15. tl;dr: “You build it, you run it” is about uncertainty, moving fast and risk management
  16. 16. “Woot?“ “Woot?“ “Woot?“ “Woot?“ “Woot?“ “Woot?“
  17. 17. Time for a bit of background …
  18. 18. Evolution of economy & markets
  19. 19. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamichigh dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. The “bathtub” curve Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13
  20. 20. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamichigh dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. Pre-industrial era Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13 Tailor-made solutions “Mastery is key to success”
  21. 21. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamichigh dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. Industrial era Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13 Cost-efficiently scale production “Get more done with less people is key to success”
  22. 22. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamichigh dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. Post-industrial era Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13 Continuously respond to changing demands “Continuous customer communication is key to success”
  23. 23. Key drivers Industrial era •  Cost-efficiency •  Scalability •  Repeatability •  Stability •  Efficiency & scale Post-industrial era •  Cycle times •  Adaptability •  Flexibility •  Resilience •  Effectiveness & speed
  24. 24. Evolution of IT
  25. 25. 1960 1970 1980 1990 2000 2010 2020 Complicated (Business functions) Complex (Business processes) Highly complex (Business nervous system) Software crisis Software engineering PC LAN Internet Business Support of IT Selective Holistic Complicated Complex “Moore’s law” Mobile IoT
  26. 26. 1960 1970 1980 1990 2000 2010 2020 Complicated (Business functions) Complex (business processes) Highly complex (Business nervous system) Software crisis Software engineering PC LAN Internet Business Support of IT Selective Holistic Complicated Complex “Moore’s law” Mobile IoT We are here …
  27. 27. 1960 1970 1980 1990 2000 2010 2020 Complicated (Business functions) Complex (business processes) Highly complex (Business nervous system) Software crisis Software engineering PC LAN Internet Business Support of IT Selective Holistic Complicated Complex “Moore’s law” Mobile IoT … but we still base most of our decisions on that We are here …
  28. 28. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamichigh dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. Remember the bathtub curve? This adds an additional twist …
  29. 29. 1960 1970 1980 1990 2000 2010 2020 Complicated (Business functions) Complex (business processes) Highly complex (Business nervous system) Software crisis Software engineering PC LAN Internet Business Support of IT Selective Holistic Complicated Complex “Moore’s law” Mobile IoT … but we still base most of our decisions on that We are here … Business is very different today … … than it was back then
  30. 30. Business Market IT today is a … … Nervous System … Medium … Product … Differentiator Disruptive Technologies Business Support Systems Continuous Conversation Digitization
  31. 31. What can we learn from that?
  32. 32. 1 We live in an age of uncertainty
  33. 33. Understanding uncertainty
  34. 34. t Money A project – CFO’s point of view Launch
 (End of project) Representation heavily inspired by a presentation of Gregor Hohpe
  35. 35. t Money The problem with uncertainty Launch
 (End of project) We have no clue if this line is correct The line could have any slope and we do not know it upfront
  36. 36. Why can’t we predict the revenue curve?
  37. 37. Uncertainty breaks the linear relation between output and outcome
  38. 38. “Woot?“ “Woot?“ “Woot?“ “Woot?“ “Woot?“ “Woot?“
  39. 39. Internally controlled Externally controlled Output Effort spent (Units produced) Industrial thinking Outcome Value created (Units sold) Certainty (linear relation) We are looking for this Due to the linear relation
 of output and outcome it is sufficient to predict output
 in order to predict outcome
  40. 40. Output Effort spent (Units produced) The effect of uncertainty Outcome Value created (Units sold) Too many influencing factors outside of control You can only measure it when it happens You cannot predict it reliably upfront No longer suitable to predict outcome Internally controlled Externally controlled Uncertainty breaks linear relation ?
  41. 41. Internally controlled Externally controlled Output Effort spent (Units produced) The effect of uncertainty Under uncertainty you cannot predict upfront which kind of performance you are going to produce Idle performance Value-adding performance Value-reducing performance Support performance Creates value (Outcome) No effect Destroys value
  42. 42. Uncertainty means that
 every new feature you deliver is a bet against the market
  43. 43. t Money Revisiting the CFO‘s point of view Launch
 (End of project) There is a lot of money at stake (a high bet against the market) The project runs for a long time which under uncertainty reduces the probability of creating value A hazardous bet (very high risk)
  44. 44. How can we do better?
  45. 45. Dealing with uncertainty •  Do small bets •  Measure outcome of each bet •  Cut idle performance features •  Cut value-reducing features •  Develop value-adding features
  46. 46. t Money Creating a different value curve Money on stake (risk) is a lot smaller Money spent (effort) Money earned (revenue) Break-even line ? Value creation
 (revenue) starts a lot earlier Idle and value-reducing
 performance avoided by cutting
 it immediately after detection Original launch
 (End of project) Investments mostly unchanged Break even before launch of original project
  47. 47. Under uncertainty you do not maximize revenue by cutting costs but by avoiding idle and value-reducing performance
  48. 48. 2 We need to move fast
 and learn all the time
 to succeed in the face of uncertainty
  49. 49. But, know where you are!
  50. 50. A little litmus test
  51. 51. Take the “real magic triangle” …
  52. 52. Good Fast Cheap Optimizing for quality and cycle times will result in higher costs Optimizing for quality and costs
 will result in long cycle times Optimizing for cycle times and costs will result in reduced quality
  53. 53. ... and pick the two properties
 that are most important for you
  54. 54. You may pick two Good Fast Cheap Industrial IT Deliver large batches at minimized costs
 towards slow markets Post-industrial IT Quickly adapt to ever-changing needs of dynamic, fast-moving markets Startup IT Test hypotheses and pivot as fast as possible to discover a product-market fit This is the domain
 of uncertainty This is the domain
 of certainty
  55. 55. 3 IT today is a key success factor to survive in a post-industrial market
  56. 56. 4 The traditional IT “best practices” are counterproductive because they solve
 a completely different problem
  57. 57. And now?
  58. 58. In a nutshell, we need to … •  Figure out how to go fast in IT •  Continue delivering high quality •  Avoid counterproductive “best practices” A good first step is to check if there are already
 concepts available that embrace those ideas
  59. 59. Enter DevOps ...
  60. 60. But, what is DevOps?
  61. 61. Perfect confusion of ideas
  62. 62. Let’s check the “DevOps bible” http://itrevolution.com/books/phoenix-project-devops-book/
  63. 63. The 3 ways of DevOps Systems thinking Amplify feedback loops Culture of continual experimentation & learning http://itrevolution.com/the-three-ways-principles-underpinning-devops/
  64. 64. •  Maximize flow (minimize cycle times) •  Optimize for global goals (holistic view) •  Never pass defects downstream •  Limit work in progress •  Build systems and organizations that are safe to change Ops Dev Business IT value chain Customer Holistic optimization Systems thinking
  65. 65. •  Facilitate constant flow of fast feedback from right-to-left •  Create quality at source (provide knowledge where needed) •  Create shared goals and shared pain for everyone involved •  Implement fast automated test suites •  Pervasively measure outcome (customer value), not output Ops Dev Business IT value chain Customer Amplify feedback loops
  66. 66. •  Create a culture that fosters two things •  Continual experimentation, taking risks and learning from success and failure •  Understanding that repetition and practice is the prerequisite to mastery •  Allocate at least 20% of available cycles to non-business requirements •  Constantly reinforce that improvements are encouraged & celebrated Ops Dev Business IT value chain Customer Continual experimentation and learning
  67. 67. Sounds good, but how does it work?
  68. 68. Cross-functional teams (organized by business capabilities) Autonomy (incl. E2E responsibility) Decentralized control Microservices Continuous Delivery Heterogeneity Cloud and Containers Resilience Operations automation Craftsmanship & mastery Outcome-driven Beyond budgeting Feature flow Lean EAM Continuous improvement T-Shaped people (being empathic) DevOps Quick feedback loops Curiosity
  69. 69. Cross-functional teams (organized by business capabilities) Autonomy (incl. E2E responsibility) Decentralized control Microservices Continuous Delivery Heterogeneity Cloud and Containers Resilience Operations automation Craftsmanship & mastery Outcome-driven Beyond budgeting Feature flow Lean EAM Continuous improvement T-Shaped people (being empathic) DevOps Quick feedback loops Curiosity In the end, DevOps has a lot of effects …
  70. 70. Cross-functional teams (organized by business capabilities) Autonomy (incl. E2E responsibility) Decentralized control Microservices Continuous Delivery Heterogeneity Cloud and Containers Resilience Operations automation Craftsmanship & mastery Outcome-driven Beyond budgeting Feature flow Lean EAM Continuous improvement T-Shaped people (being empathic) DevOps Quick feedback loops Curiosity ... but we want to focus on those effects
  71. 71. How does DevOps affect the organization?
  72. 72. Customer Idea Traditional IT organization Operational structure Organizational structure … Subject matter expert Handover Activity (process step) Manager (Non subject matter expert) Reports to
  73. 73. Customer Idea Traditional IT organization Operational structure Organizational structure … Subject matter expert Handover Activity (process step) Manager (Non subject matter expert) Reports to Many (often manual) steps result in long cycle times and cause defects which introduce additional approval steps Lots of handovers cause information loss and increase cycle time Problems in process execution often need to be escalated which increases cycle time
  74. 74. Reducing cycle times •  Reduce activities and handovers •  Automate everything •  Observe and tackle wait times •  Push decision authority at execution level * •  Create feedback loops at execution level * •  Improve continuously * requires shared goals and pain
  75. 75. New (ideal) IT organization (1/2) Idea Customer Operational structure Organizational structure Manager Reports to Massive automation increases quality, shortens cycle times and removes need for additional approval steps Handovers replaced by collaborating team working towards a shared goal and creating feedback loops as needed A A A A A A A T-shaped expert (Handover) End2end value creation A Automation Organizational structure rot required anymore for problem escalation
  76. 76. New (ideal) IT organization (2/2) Idea Customer Operational structure Side note: The distribution of ideas to teams should be pull-based and is by far not as simple as it looks here A A A A A A A A A A A A A A A A A A A A A A A A A A A A … Organize in many small teams, each team responsible for a dedicated business capability or value delivery flow in order to minimize cross-team dependencies
  77. 77. Properties of the teams •  Clearly defined value delivery goal •  Shared across all team members •  Autonomous •  All required skills for E2E value delivery •  Full decision authority •  (Mostly) independent from other people •  Full accountability for value delivery •  No one else to blame … ;)
  78. 78. … which naturally leads to „You decide it, ...“ “You build it, you run it!”
  79. 79. tl;dr: “You build it, you run it” is about uncertainty, moving fast and risk management
  80. 80. „You build it, you run it“ is about tackling uncertainty, not about control
  81. 81. Wrap-up •  Misconception of “You build it, you run it” •  Evolution of markets and IT •  Understanding and tackling uncertainty •  Knowing your position •  Goals and effects of DevOps •  How DevOps affects the IT organization •  Actual meaning of “You build it, you run it”
  82. 82. We live in an age of uncertainty
  83. 83. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

×