Team Topologies, Software Architecture & Complexity • James Lewis • GOTO 2022
Вставка
- Опубліковано 12 чер 2024
- This presentation was recorded at GOTO Amsterdam 2022. #GOTOcon #GOTOams
gotoams.nl
James Lewis - Principal Consultant & Technical Director at Thoughtworks @thoughtworks
RESOURCES
/ boicy
/ james-lewis-microservices
ABSTRACT
Recent research summarised in the book points to a set of practices that lead to high software development organisation performance. Simultaneously, research from the Santa Fe institute on Complex Adaptive Systems over the last 20 years seems to point to a grand unified theory of organisational design.
So have we cracked it? Do we now have the answer to the question: how do we create and scale high performing software and organisations?
In this talk, James explores the relationships between team structure, software architecture and the emergent phenomenon of complexity science. [...]
TIMECODES
00:00 Intro
03:42 Team Topologies & complexity
05:52 What is value?
08:04 Team Topologies
10:25 Software architecture & complexity
14:17 Complex adaptive systems
23:05 Complex adaptive systems are everywhere
24:15 Corporate metabolism
28:54 Sidebar: Identifying the signs of ageing
32:54 Scaling complex adaptive systems
37:39 Outro
Download slides and read the full abstract here:
gotoams.nl/2022/sessions/1605...
RECOMMENDED BOOKS
Henney & Monson-Haefel • 97 Things Every Software Architect Should Know • amzn.to/3pZuHsQ
Matthew Skelton & Manuel Pais • Team Topologies • amzn.to/3sVLyLQ
Forsgren, Humble & Kim • Accelerate: The Science of Lean Software and DevOps • amzn.to/3tCz1xO
Michael Jackson • Software Requirements and Specifications • amzn.to/3ql2T14
Geoffrey West • Scale • amzn.to/3eKMbpc
Fred Brooks Jr. • The Mythical Man-Month • williamgibsonbooks.com
Donald G. Reinertsen • The Principles of Product Development Flow • amzn.to/3hJ2Ye2
Murray Gell-Mann • The Quark & the Jaguar • amzn.to/3v3ifJK
/ gotocon
/ goto-
/ gotoconferences
#Complexity #SoftwareEngineering #JamesLewis #Programming #ProgrammingAnarchy #Tech #SoftwareDevelopment #SoftwareTechnology #SoftwareCycles #ProgrammingCycles #DesignPatterns #TeamTopologies #SoftwareArchitecture #Microservices #Scale #Thoughtworks #ScaleDown #SelfSimilarity #SelfOrganization #Emergence #CorporateMetabolism
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ua-cam.com/users/GotoConf... - Наука та технологія
This guy’s scarey smart and he communicates extremely effectively. Wow.
A big like 👍 Thanks for sharing this 🙏
Great like would love to know more about how to build organization based on social network
Interesting line of thought. 37:35 James Lewis asks the question of why Amazon's growth is accelerating with time whereas most other companies' growth decelerates with time. That's the difference between marketplaces where the winner takes all most of the time, and product/services businesses.
And flywheel effects. Monetizing costly achieved data, customer relations, marketing / word of mouth etc etc. Marketplaces are just an overarching echelon of those principles.
@@dinoscheidt Right. In addition to its marketplace business, Amazon also has AWS which is a platform business, and platforms also show flywheel effects. If you have petabytes of data stored on AWS and your software is dependent on AWS services, you are unlikely to move onto another cloud. Also you are more likely to find hires who are skilled in AWS vs other clouds. In addition, Amazon and AWS have received a lot of VC money, which helps when it comes to marketing and execution capability.
Also at 11:45 he wondered why each new employee was bringing in more money. I think an even easier way of explaining this is just 'economies of scale'. Yes the interactions between the teams are vital to enable this over the long term but I think the general behaviour is well understood and not that surprising
Yes, I thought James glossed over Amazon's monopolistic & monopsonistic behaviours.
Law of diminishing marginal utility is a universal principle.
Good talk. Would of loved to spend more time on real world examples
what does it mean by building organization like social network? How?
I'm sure the software architecture and organisation structure is a big part of it, it seems like some of the super-linear growth of Amazon could be explained by it's monopolistic & monopsonistic behaviours. The flywheel that Doctorow and Giblin talk about in "Chokepoint Capitalism".
It seems like a huge big emission to talk about getting bigger making getting bigger easier without mentioning that they're so big that we can't approximate their share on the markets as zero, like we could with a small company in a highly competitive market. In some ways that should make it harder for them to get bigger as they've already captured the market and there's less space to grow into, but it also makes it easier as they're able to make it hard to operate competitors and they benefit from network effects.
Thank you for the lecture, quite fascinating and informative.
what is the next big thing wrt organisational design / structure after Team Topologies? What to inspire next?
So many scary facts laid out so clearly... and orgs still insist in change requests board, hierarchical leadership styles, org wide policies and rules for developers...
Things seem to be getting worse with often multiple cloud platforms and multiple CI/CD systems per startup not to mention anti-patterns like a FaaS per every http endpoint in effect.
That would all be fine, if those would have contract testing. If you have a schema that says email: optional, address: optional - but the business logic says it needs at least one method to contact a user = the trouble starts. But lets not kid ourselves… most startups today have trouble to not use php, rust, python etc for a simple website. Let alone system design.
A great Thoughtworks commercial - a lot of bolting together of much more elegant thought leadership (methods/concepts/practices). Good try, though, muddy thinking, especially around complex adaptive systems and flow. Relying on the early days of what used to be a good reputation for thought leadership.