Waves of Centralising and Decentralising

Presentation given at the Study of Enterprise Agility conference about the moves to centralise and decentralise both teams and technologies. Part literature review, part amateur economics and lots of devops ideals.

Transcript

1. (without introducing more risk) Centralising and Decentralising Puppet Gareth Rushgrove Waves of change in technology and teams
2. (without introducing more risk) @garethr
3. (without introducing more risk) Gareth Rushgrove
4. (without introducing more risk) What we’ll cover This talk
5. - Modern software architecture - Modern software organisations - Reasons for the current zeitgeist - Science and literature Gareth Rushgrove
6. Centralise /ˈsɛntrəlʌɪz/ concentrate (control of an activity or organisation) under a single authority. Gareth Rushgrove
7. Decentralise /di:ˈsɛntrəlʌɪz/ to distribute the administrative powers or functions of (a central authority) over a less concentrated area Gareth Rushgrove
8. Gareth Rushgrove Talking of centralisation goes back a way
9. Gareth Rushgrove Talking of decentralisation is more recent
10. (without introducing more risk) The technology story Modern Software Architecture
11. Gareth Rushgrove From Mainframe to Microservices
12. From app servers to embedded servers Gareth Rushgrove
13. Gareth Rushgrove From WORA to polyglot programming
14. Gareth Rushgrove From ESB’s to adhoc HTTP services
15. Gareth Rushgrove From SOAP to REST
16. Gareth Rushgrove From data warehouse to data lake
17. Gareth Rushgrove From SQL and schemas to NoSQL
18. Gareth Rushgrove From rules engines to machine learning
19. The current direction of travel is to more decentralised systems Gareth Rushgrove
20. Pushing responsibility from singular technologies to individual components Gareth Rushgrove
21. And from upfront decisions to determinations made closer to the data or users Gareth Rushgrove
22. Gareth Rushgrove
23. Most of these technology changes have been driven bottom up, by virtue of adoption by individual software developers Gareth Rushgrove
24. (without introducing more risk) The organisation story Modern Software Teams
25. From outsourcing to insourcing Gareth Rushgrove
26. From waterfall to agile Gareth Rushgrove
27. Gareth Rushgrove “Expecting one of the usual greetings like "pleased to meet you," I was surprised that the first thing he said was "I think that architects are obsolete Joseph Hofstader, Microsoft Software Architect, Architecture Journal 2008 From ivory towers to no architects
28. Gareth Rushgrove You build it, you run it Werner Vogels, Amazon CTO From operations to devops “
29. From specialists to generalists Gareth Rushgrove
30. Gareth Rushgrove From specialists to generalists full stack engineers
31. Spotify Squads, Tribes and Guilds Gareth Rushgrove
32. Again, the current direction of travel appears to be to more decentralised teams Gareth Rushgrove
33. (without introducing more risk) Context for the current direction Why Decentralise Anyway?
34. Gareth Rushgrove State of DevOps Report
35. (without introducing more risk) 30x Gareth Rushgrove More frequent deployments Faster lead times than their peers 200x 2015 State of DevOps Report
36. (without introducing more risk) 60x Gareth Rushgrove Change success rate Faster mean time to recover 168x 2015 State of DevOps Report
38. (without introducing more risk) It’s not all about decentralising Counter Examples
39. Gareth Rushgrove “Platforms”
40. - Orchestration - Logging - Configuration - Self-healing - Storage Gareth Rushgrove - Load balancing - Service discovery - Scaling - Batch workloads - Lots more
41. Is Agile in practice really a centralising or decentralising force? Gareth Rushgrove
42. Gareth Rushgrove
43. Gareth Rushgrove Scaled Agile Framework
44. Gareth Rushgrove “I consider the need for some level of centralised control the main reason for using SAFe Thomas Karlsson http://agile-management.com/wordpress/when-to-use-safe-scaled-agile-framework/
45. Gareth Rushgrove
46. (without introducing more risk) Gareth Rushgrove Dev SRE Ops From http://web.devopstopologies.com/ by Matthew Skelton
47. Gareth Rushgrove Monorepos
48. Gareth Rushgrove
49. (without introducing more risk) A current example of the zeitgeist Containers as a Microcosm
50. Gareth Rushgrove Is Docker centralising or decentralising?
51. Decentralising the act of packaging software Gareth Rushgrove
52. Centralising the unit of running software Gareth Rushgrove
53. Facilitating the decentralisation of software development teams Gareth Rushgrove
54. By centralising the platform on which all software runs Gareth Rushgrove
55. (without introducing more risk) Some of the underpinning theory From Taylorism to Sociotechnical Systems
56. Gareth Rushgrove
57. A production efficiency methodology that breaks every action, job, or task into small and simple segments which can be easily analysed Gareth Rushgrove
58. Gareth Rushgrove - Separates execution of work from work planning - Separates direct labor from indirect labor - Replaces rule of thumb productivity estimates with precise measurements - Introduces time and motion study for optimum job performance and cost accounting
59. Sidebar Who thinks I just described Agile? Gareth Rushgrove
60. Gareth Rushgrove - Aims to achieve maximum job fragmentation to minimise skill requirements and job learning time - Makes possible payment-by-result method of wage determination
61. Sidebar Who thinks I just described the gig economy? Gareth Rushgrove
62. Taylorism has been widely discredited, but influences a great deal of management theory and practice Gareth Rushgrove
63. Gareth Rushgrove
64. Scientific Management is a system that is excellent for achieving highly efficient execution of known, repeatable processes at scale Gareth Rushgrove Team of Teams: New Rules of Engagement for a Complex World “
65. Gareth Rushgrove Team of Teams: New Rules of Engagement for a Complex World “Efficiency is no longer enough
66. Complexity produces a fundamentally different situation from the complicated challenges of the past Gareth Rushgrove Team of Teams: New Rules of Engagement for a Complex World “
67. Complexity means that, in spite of our increased abilities to track and measure, the world has become, in many ways, vastly less predictable Gareth Rushgrove Team of Teams: New Rules of Engagement for a Complex World “
68. Gareth Rushgrove Team of Teams: New Rules of Engagement for a Complex World “ Developing resilience, learning how to reconfigure to confront the unknown, is a much more effective way to respond to a complex environment
69. Gareth Rushgrove
70. (without introducing more risk) The field of Sociotechnical Systems suggests that all human systems include both a technical system and a social system Gareth Rushgrove https://en.wikipedia.org/wiki/Coevolution#Technological_coevolution
71. (without introducing more risk) Better outcomes are usually obtained by a reciprocal process of joint optimization, through which both the technical system and the social system change Gareth Rushgrove https://en.wikipedia.org/wiki/Coevolution#Technological_coevolution
72. (without introducing more risk) Gareth Rushgrove Conway’s Law as a classic example Organisations which design systems ... are constrained to produce designs which are copies of the communication structures of these organisations
73. Gareth Rushgrove
74. (without introducing more risk) If all you remember is Conclusions
75. Do we build distributed systems because we seek decentralised teams? Gareth Rushgrove
76. Or do we desire decentralised teams so we build distributed systems? Gareth Rushgrove
77. You’re probably centralising and decentralising different things at the same time Gareth Rushgrove
78. Beware local optima Gareth Rushgrove
79. To be an agile enterprise you need to be conscious and transparent about where you are centralising and decentralising Gareth Rushgrove
80. - Team of Teams General Stanley McChrystal - The New Kingmakers Stephen O’Grady - Designing Delivery Jeff Sussna - Antifragile Nassim Nicholas Taleb Gareth Rushgrove
81. Gareth Rushgrove Team of Teams: New Rules of Engagement for a Complex World “Surprisingly, that change was less about new technology than it was about culture – in other words, our approach to management
82. (without introducing more risk) Questions? And thanks for listening