7 ms·

None of that has really anything to do with systems thinking. That models change, omit information and don't represent reality as such is true for any kind of t

None of that has really anything to do with systems thinking. That models change, omit information and don't represent reality as such is true for any kind of thinking, systems or otherwise. That's just a truism. At its core systems thinking is an antidote to reductionism. The essential feature of a system is that it is an indivisible whole and that its features are more than the sum of its parts. Systems lose their properties when taken apart into components, because their properties are the result of interactions between components, not the sum of the properties of components in isolation. That insight produces the most important practical application of systems thinking, which is that systems always need to be designed from the ground up. People should never try to improve individual metrics, but only improve parts if it improves the whole. That's also what most of the examples in Maedow's book are about that's quoted in the piece. It's also quite funny to bring up a transition to microservices in the piece in this context. I think microservice architectures are almost always the result of ignoring systems thinking lessons. People start to think in terms of the performance of each individual service, start to develop each service on its own terms, and start to ignore the fact that what matters is the interaction between services. It's exactly the kind of silo-ing that systems approaches try to avoid.

varjag 5y ago
Yep, the Uber anecdote sounds more about hubris and inexperience than about systems design.
gumby 5y ago
> At its core systems thinking is an antidote to reductionism. This is a brilliant insight.
- bmitc 5y ago
  It’s a pretty old and well known perspective. More is Different by P. W. Anderson https://cse-robotics.engr.tamu.edu/dshell/cs689/papers/anderson72more_is_different.pdf https://cse-robotics.engr.tamu.edu/dshell/cs689/papers/ander... More and Different by Philip W. Anderson https://www.amazon.com/gp/aw/d/9814350133/ https://www.amazon.com/gp/aw/d/9814350133/
- groby_b 5y ago
  It's also wrong :) Systems thinking incorporates reductionism - you do think about the individual parts as well as the hole. Systems thinking is a synthesis of reductionism and holistic/emergence thinking, and both are necessary. From Meadow's "Thinking in Systems": I start with the basics: the definition of a system and a dissection of its parts (in a reductionist, unholistic way). Then I put the parts back together to show how they interconnect to make the basic operating unit of a system: the feedback loop. It is not an antidote so much as an acknowledgment of the incompleteness of reductionism.
- gumby 5y ago
  Thanks for the references bmitc. Sorry that your comment is dead for some reason -- so I couldn't reply directly.
naasking 5y ago
> At its core systems thinking is an antidote to reductionism. The essential feature of a system is that it is an indivisible whole and that its features are more than the sum of its parts. Systems lose their properties when taken apart into components, because their properties are the result of interactions between components, not the sum of the properties of components in isolation. If this is true, then "systems thinking" = "emergentism".
throwaway984393 5y ago
To expand on that microservices point, there's a particular form of systems blindness that happens when people focus on one part of a system, think they understand that one part, and then ignore all the others, as if all you need to know is what's right in front of you. I see it every day, in every team that I work with. The team works on component A. Maybe they can see that it's supposed to work with components B and C (maybe). So they design for those components alone. Meanwhile, components D, E, F, and G depend on components B and C. But because they don't directly work with each other, team A doesn't know that its design decisions will cause problems for D/E/F/G, and those teams don't learn about the limits of A. And they don't even think to ask. It's really nutty. As a systems veteran, I already know problems are going to happen purely because of not having a deeper understanding of the system. If I ask them to go out of their way to discover the interaction of the whole system, they balk (because "that's not my job"), and upper management doesn't care that nobody knows how the whole system works. It's like this at most places I've worked. We need a revolution in establishing these conventions of building components in a system, the way the 12 factor app redefined building a modern stateless app.
- DelightOne 5y ago
  How are all connections usually tracked, if they are?
  - throwaway458864 5y ago
    Assuming you mean the connections between the components - a hodge-podge of different models, tools, techniques. There is no one way to do it, partly because of how different any given system can be from another. Even within software engineering, it really depends on the industry you're in, the application of the software, the stakeholders, the risks. But generally speaking, most people only track the connections at design time, as an artifact of overall architecture. And this isn't great, because as the system changes (modern software systems change constantly) the entire system development lifecycle is not being re-assessed every time some component changes. So in the best case, with a Waterfall model, you have very well defined connections in design, and you have to pray that your SDLC validates that design. But most people prefer Agile, which in practice means "I don't need a well defined system! #YOLOEngineering". So everything is built ad-hoc and nobody even attempts to figure out the entire picture. And in that case, Operations may be told to figure it out (they're the ones running it all, so they have the best vantage), and they tend to implement monitoring and distributed tracing that enables cobbling together a picture of how things are actually working. But that's not fed back into teams' designs, it's just used for addressing problems after the fact. To be specific: you might use ADRs and manually crafted diagrams to map out the connections, or UML, or some other systems diagramming tool/standard. But often that's created only at a certain level of the system, and doesn't dive deep into component interfaces or tolerances/limits or availability. So the full picture can never be seen from one view, and it's almost never the teams themselves mapping it out.
yourapostasy 5y ago
> I think microservice architectures are almost always the result of ignoring systems thinking lessons. Pretty much. The current hope is This Time It's Different, because of various self-discovery service registries, observability approaches, more orchestration, and so on. We've arguably made some progress; FAANG's wouldn't be be able to operate at their scale if something hadn't been accomplished on that front. But I'd wager there is a lot more systems thinking that goes on in those architectures than is being let on in public. Management is not a substitute for leadership. Throwing together components is not a substitute for systems thinking. There are no silver bullets, whocoodanode? It is curiously ironic to me that we're traveling around to a similar kind of (yet still different) environment as mainframes, with well-published interfaces, inscrutable non-realtime chargeback style billing, vendor lock-in, lots of scrutiny upon fine-grained transaction monitoring, and so on. Somewhere over in a well-earned retirement, probably sits some white-beard, chuckling to themselves as they down another plate of chicken wings and quaff a fizzy umbrella drink.
- Blackstrat 5y ago
  Yep but my beard isn’t completely white yet and I don’t like umbrella drinks. But seriously, my position was “eliminated” just prior to the pandemic, largely because I tried to convince the CIO that a financial company with a million customer target, probably didn’t need a cloud-based, micro services architecture. I was deemed a dinosaur. He wanted the marketing buzz. They still don’t have their new product.
  - yourapostasy 5y ago
    > ...a financial company with a million customer target, probably didn’t need a cloud-based, micro services architecture. Only a million? There aren't hugely many scenarios where cloud-based microservices would beat a monolith at that small scale. Where many such decisions bog down is in re-engineering existing processes into microservices, or cloud, or simultaneously both. If you're starting out brand-new in a white space, then yes, by all means dive into that if you also possess the operational expertise to run it (another area I see a lot of stumbling). Functionally lift and shift strategies into the cloud is still frequently decided upon by well-meaning C-levels even this late into the cloud era, and they are still unerringly shocked at the resultant bills. Those with massive legacy infrastructures get seduced by the promised 10X cost reductions, and overlook the fine print it will cost them 10-100X current total spend as capital spend to get there. The future is always unevenly distributed.

varjag 5y ago

Yep, the Uber anecdote sounds more about hubris and inexperience than about systems design.

gumby 5y ago

> At its core systems thinking is an antidote to reductionism. This is a brilliant insight.

bmitc 5y ago
It’s a pretty old and well known perspective. More is Different by P. W. Anderson https://cse-robotics.engr.tamu.edu/dshell/cs689/papers/anderson72more_is_different.pdf https://cse-robotics.engr.tamu.edu/dshell/cs689/papers/ander... More and Different by Philip W. Anderson https://www.amazon.com/gp/aw/d/9814350133/ https://www.amazon.com/gp/aw/d/9814350133/
groby_b 5y ago
It's also wrong :) Systems thinking incorporates reductionism - you do think about the individual parts as well as the hole. Systems thinking is a synthesis of reductionism and holistic/emergence thinking, and both are necessary. From Meadow's "Thinking in Systems": I start with the basics: the definition of a system and a dissection of its parts (in a reductionist, unholistic way). Then I put the parts back together to show how they interconnect to make the basic operating unit of a system: the feedback loop. It is not an antidote so much as an acknowledgment of the incompleteness of reductionism.
gumby 5y ago
Thanks for the references bmitc. Sorry that your comment is dead for some reason -- so I couldn't reply directly.

naasking 5y ago

> At its core systems thinking is an antidote to reductionism. The essential feature of a system is that it is an indivisible whole and that its features are more than the sum of its parts. Systems lose their properties when taken apart into components, because their properties are the result of interactions between components, not the sum of the properties of components in isolation. If this is true, then "systems thinking" = "emergentism".

throwaway984393 5y ago

To expand on that microservices point, there's a particular form of systems blindness that happens when people focus on one part of a system, think they understand that one part, and then ignore all the others, as if all you need to know is what's right in front of you. I see it every day, in every team that I work with. The team works on component A. Maybe they can see that it's supposed to work with components B and C (maybe). So they design for those components alone. Meanwhile, components D, E, F, and G depend on components B and C. But because they don't directly work with each other, team A doesn't know that its design decisions will cause problems for D/E/F/G, and those teams don't learn about the limits of A. And they don't even think to ask. It's really nutty. As a systems veteran, I already know problems are going to happen purely because of not having a deeper understanding of the system. If I ask them to go out of their way to discover the interaction of the whole system, they balk (because "that's not my job"), and upper management doesn't care that nobody knows how the whole system works. It's like this at most places I've worked. We need a revolution in establishing these conventions of building components in a system, the way the 12 factor app redefined building a modern stateless app.

DelightOne 5y ago
How are all connections usually tracked, if they are?
- throwaway458864 5y ago
  Assuming you mean the connections between the components - a hodge-podge of different models, tools, techniques. There is no one way to do it, partly because of how different any given system can be from another. Even within software engineering, it really depends on the industry you're in, the application of the software, the stakeholders, the risks. But generally speaking, most people only track the connections at design time, as an artifact of overall architecture. And this isn't great, because as the system changes (modern software systems change constantly) the entire system development lifecycle is not being re-assessed every time some component changes. So in the best case, with a Waterfall model, you have very well defined connections in design, and you have to pray that your SDLC validates that design. But most people prefer Agile, which in practice means "I don't need a well defined system! #YOLOEngineering". So everything is built ad-hoc and nobody even attempts to figure out the entire picture. And in that case, Operations may be told to figure it out (they're the ones running it all, so they have the best vantage), and they tend to implement monitoring and distributed tracing that enables cobbling together a picture of how things are actually working. But that's not fed back into teams' designs, it's just used for addressing problems after the fact. To be specific: you might use ADRs and manually crafted diagrams to map out the connections, or UML, or some other systems diagramming tool/standard. But often that's created only at a certain level of the system, and doesn't dive deep into component interfaces or tolerances/limits or availability. So the full picture can never be seen from one view, and it's almost never the teams themselves mapping it out.

yourapostasy 5y ago

> I think microservice architectures are almost always the result of ignoring systems thinking lessons. Pretty much. The current hope is This Time It's Different, because of various self-discovery service registries, observability approaches, more orchestration, and so on. We've arguably made some progress; FAANG's wouldn't be be able to operate at their scale if something hadn't been accomplished on that front. But I'd wager there is a lot more systems thinking that goes on in those architectures than is being let on in public. Management is not a substitute for leadership. Throwing together components is not a substitute for systems thinking. There are no silver bullets, whocoodanode? It is curiously ironic to me that we're traveling around to a similar kind of (yet still different) environment as mainframes, with well-published interfaces, inscrutable non-realtime chargeback style billing, vendor lock-in, lots of scrutiny upon fine-grained transaction monitoring, and so on. Somewhere over in a well-earned retirement, probably sits some white-beard, chuckling to themselves as they down another plate of chicken wings and quaff a fizzy umbrella drink.

Blackstrat 5y ago
Yep but my beard isn’t completely white yet and I don’t like umbrella drinks. But seriously, my position was “eliminated” just prior to the pandemic, largely because I tried to convince the CIO that a financial company with a million customer target, probably didn’t need a cloud-based, micro services architecture. I was deemed a dinosaur. He wanted the marketing buzz. They still don’t have their new product.
- yourapostasy 5y ago
  > ...a financial company with a million customer target, probably didn’t need a cloud-based, micro services architecture. Only a million? There aren't hugely many scenarios where cloud-based microservices would beat a monolith at that small scale. Where many such decisions bog down is in re-engineering existing processes into microservices, or cloud, or simultaneously both. If you're starting out brand-new in a white space, then yes, by all means dive into that if you also possess the operational expertise to run it (another area I see a lot of stumbling). Functionally lift and shift strategies into the cloud is still frequently decided upon by well-meaning C-levels even this late into the cloud era, and they are still unerringly shocked at the resultant bills. Those with massive legacy infrastructures get seduced by the promised 10X cost reductions, and overlook the fine print it will cost them 10-100X current total spend as capital spend to get there. The future is always unevenly distributed.