Monoliths vs Microservices is Missing the Point-Start with Team Cognitive Load - Team Topologies
ฝัง
- เผยแพร่เมื่อ 7 ก.ค. 2019
- DOES19 London - The “monoliths vs microservices” debate often focuses on technological aspects, ignoring strategy and team dynamics. Instead of technology, smart-thinking organizations are beginning with team cognitive load as the guiding principle for modern software. In this talk, we explain how and why, illustrated by real case studies.
Monoliths vs Microservices is Missing the Point-Start with Team Cognitive Load
Matthew Skelton, Author, Team Topologies: Organizing Business and Technology Teams for Fast Flow
Manuel Pais, Author, Team Topologies: Organizing Business and Technology Teams for Fast Flow
Matthew Skelton has been building, deploying, and operating commercial software systems since 1998. Head of Consulting at Conflux (confluxdigital.net/), he specialises in Continuous Delivery and operability for software in manufacturing, ecommerce, and online services, including cloud, IoT, and embedded software.
Matthew curates the well-known DevOps team topologies patterns at devopstopologies.com and is co-author of the books Continuous Delivery with Windows and .NET (O’Reilly, 2016) and Team Guide to Software Operability (Skelton Thatcher Publications, 2016). He is also co-founder at Skelton Thatcher Publications (skeltonthatcher.com/), a specialist publisher of techniques for software teams.
Matthew founded and leads the 2300-member London Continuous Delivery meetup group (londoncd.org.uk/), and instigated the first conference in Europe dedicated to Continuous Delivery, PIPELINE Conference (pipelineconf.info/). He also leads the CodeMill digital skills initiative in the North of England (codemill.tech/), and is a Chartered Engineer (CEng).
Manuel Pais is an independent IT consultant and trainer, focused on team interactions, delivery practices, and accelerating flow. Manuel is co-author of the book "Team Topologies: Organizing Business and Technology Teams for Fast Flow" (IT Revolution Press, 2019). He helps organizations rethink their approach to software delivery, operations and support via strategic assessments, practical workshops, and coaching.
Also InfoQ lead editor. Answers by @manupaisable on Twitter and Medium.
DOES19 London
DOES 2019 EUR
DevOps Enterprise Summit
events.itrevolution.com/eur/ - วิทยาศาสตร์และเทคโนโลยี
The concepts outlined in this book have been eye opening and have allowed me to see in hindsight why our teams are struggling. Our teams were high performing years ago but as the systems they built grew and increased in complexity the team design never matured along with the system growth. We quickly outgrew the team’s cognitive load. Thank you for writing this book!
Thank you for the feedback!
For managers setting up these teams: please pay attention to the up and downsides of specialisation, job enlargement and job enrichment.
This concept has changed my life, mind and ways of thinking about organisations. This was a missing element for me. I'm really grateful you used that clickbait title!! :D
hello IT Revolutions. Thanks for this. I am just, as of now, starting my journey on building teams...I am taking your framework and contextualising it into my business (pharma space) It seems straight forward. I will be in touch in a few years once it plays out...and perhaps along the way. Thank you for your insights and clear communications. I will shortly be buying the book.
Exactly the explanation of all the teams who're applying microservice/DDD/Cloud-native/Kubernative designs.
At 26:29, you explain how the team separated into smaller teams aligned around single domains. What were those news teams' interaction modes with each other? Collaboration, x-as-a-service, or enabling?
Good question Jon! Between the new teams there is collaboration when there are changes or issues that cross the boundaries of the small teams (for e.g. test automation in the CI/CD pipeline). If necessary, they would create temporary "mini-teams" to solve a specific problem that might take a bit longer. On the other hand, all of these new teams are mostly interacting in facilitating or X-as-a-Service fashion with the end product-focused engineering teams (their customers).
If only we could make developers worry less about the intrinsics (creating a table, adding a class etc) and take structure and tech for granted. I have been in many teams where requirements directly are translated into tech in discussions. I believe that those implementation details distract us from what we are going to achieve. I do admit that higher-level and abstract thinking is a skill that don't easly develop. I have been working on my own projects, becoming so accostumed to the tech, structure, and pattern that they matter less in my thinking. The translation is instant. Thinking about the use case. "I need to store X and send an email after that". That it is a database with tables and columns matter less. I'm after all using an ORM.
that’s what the first two parts of the DDD book or Clean Architecture are about most people miss: start with the domain.
build a domain/entity layer which models the business domain (data and functions).
then an application/use case layer which describes how the users will interact with the domain model. and on top of that a user interface which contains no further domain or application logic.
make the code clean in it’s meaning to domain experts, ux, etc. so that they can read or even write code in the layer important to them.
have a domain expert (navigator) pair with a developer (driver).
have a co-located, cross-functional team which has people from functions like domain, qa, ux, … instead of a team were devs perform most functions.
(if you can’t get customer, build one aka. persona/po.)
e.g. the whole reason of a library like hibernate is to keep the database out of the domain and application layer. just tell it which parts of the model to persist and forget about it. or mvc/mvvm: remove state from the view and place it in the application model. (which may e.g. have rules to use the color red for negative numbers, or to have a button disabled unless some data has been entered.)
that was the idea of Alan Kay‘s team: build a computer normal people could program by providing them a layer of abstraction they can use to change the system. And when OOP/Smalltalk made it‘s way from Xerox to Tektronix, people like Ward Cunningham (Design Patterns, Wiki, …) and Kent Beck (XP, TDD, JUnit, Clean Code, …) picked it up and realised that this architecture also needed a different way of working which is now known as Agile.
the trouble is that this body of knowledge got lost.
plus that the demand and pay for software developers is so high that education is lacking.
it’s a bubble waiting to burst. and when 3 out of 4 developers have lost their job, the rest will have the incentive to build manageable systems again. 😅
Is this explanation of cognitive load right? When I look at Jo Pearce's slides, as well as academic papers on cognitive load, it would seem that "intrinsic" is the complexity of the task at hand (i.e., the problem you're trying to solve), where "germane" cognitive load is actually positive and are things like existing known concepts that help you understand the problem, as well as spaced repetition and context variation. Maybe (most likely haha) I'm misunderstanding.
OMG finally, someone focused more on the actual cognititve implications. PA3CA4SA2RAVA3CA2SA
How do we add freshers to this mix?