Simon Rohrer
@simon.bvssh.com
#BVSSH, Modern Enterprise Architecture, Agile, DevOps, lean, product design
Currently down a Viable System Model rabbit-hole
Contributor to @itrevolution.bsky.social Sooner Safer Happier
Currently down a Viable System Model rabbit-hole
Contributor to @itrevolution.bsky.social Sooner Safer Happier
Reposted by Simon Rohrer
It’s not precise to say:
“If you cannot deal with monolith, microservices won’t work for you!”.
The actual phrase should be:
"If you can’t deal with modularity, then neither monoliths nor microservices will work for you."
3/
“If you cannot deal with monolith, microservices won’t work for you!”.
The actual phrase should be:
"If you can’t deal with modularity, then neither monoliths nor microservices will work for you."
3/
April 14, 2025 at 6:54 AM
It’s not precise to say:
“If you cannot deal with monolith, microservices won’t work for you!”.
The actual phrase should be:
"If you can’t deal with modularity, then neither monoliths nor microservices will work for you."
3/
“If you cannot deal with monolith, microservices won’t work for you!”.
The actual phrase should be:
"If you can’t deal with modularity, then neither monoliths nor microservices will work for you."
3/
Happy to chat more (SSH Slack?) – we use the Backstage service catalog to locate components and their code and docs including ADRs. High level guidelines otherwise pretty much as above, detailed guidelines evolving (eg what C4 diagrams to use), what’s mandatory, what’s advised
January 28, 2025 at 2:10 PM
Happy to chat more (SSH Slack?) – we use the Backstage service catalog to locate components and their code and docs including ADRs. High level guidelines otherwise pretty much as above, detailed guidelines evolving (eg what C4 diagrams to use), what’s mandatory, what’s advised
We have a dual strategy of transient docs in Confluence and long-lived docs in Markdown displayable in Backstage. Lowest level docs are in the teams’ own git repos so they can change whenever they want. Higher level (system-of-systems docs) are in an enterprise architecture repo as internal o/s
January 15, 2025 at 11:37 AM
We have a dual strategy of transient docs in Confluence and long-lived docs in Markdown displayable in Backstage. Lowest level docs are in the teams’ own git repos so they can change whenever they want. Higher level (system-of-systems docs) are in an enterprise architecture repo as internal o/s
Reposted by Simon Rohrer
But consensus isn’t always progress. It often leads to what the Dutch famously call “polderen”—a compromise where no one really gets what they want. The result? Solutions that look fine on paper but lack real buy-in. And without that, implementation stalls, leaving teams frustrated and momentum lost
December 17, 2024 at 7:59 AM
But consensus isn’t always progress. It often leads to what the Dutch famously call “polderen”—a compromise where no one really gets what they want. The result? Solutions that look fine on paper but lack real buy-in. And without that, implementation stalls, leaving teams frustrated and momentum lost
Reposted by Simon Rohrer
No disagreements here on those two, but I do wonder if there's a *third* value of software, and that is WHAT WE LEARNED FROM CREATING IT. And, you might not surprised to hear, I think that might even be the *most* valuable thing.
December 10, 2024 at 10:49 AM
No disagreements here on those two, but I do wonder if there's a *third* value of software, and that is WHAT WE LEARNED FROM CREATING IT. And, you might not surprised to hear, I think that might even be the *most* valuable thing.
Reposted by Simon Rohrer
I have been referred to someone called “The Beard”
Not even kidding.
Not even kidding.
December 9, 2024 at 7:57 PM
I have been referred to someone called “The Beard”
Not even kidding.
Not even kidding.
Here you go bsky.social/about/blog/4...
How to verify your Bluesky account - Bluesky
Here's how to verify your Bluesky account by setting your website as your username.
bsky.social
December 1, 2024 at 1:32 PM
Here you go bsky.social/about/blog/4...
Also here also here systemic2016.wordpress.com/variety-engi...
and here thevsmtest.org/VSM-Guide/in...
and here thevsmtest.org/VSM-Guide/in...
Variety Engineering
Any organization for it to be viable it must be capable of dealing with the complexity of its environment. Organizations are not able to create the same amount of complexity internally as their en…
systemic2016.wordpress.com
December 1, 2024 at 1:29 PM
Also here also here systemic2016.wordpress.com/variety-engi...
and here thevsmtest.org/VSM-Guide/in...
and here thevsmtest.org/VSM-Guide/in...
I promised you more @ccombe.bsky.social so might as well do it in public here! I've found this reading list incredibly useful stream.syscoi.com/2020/05/06/a...
In particular this drive.google.com/file/d/1s0TT...
and this drive.google.com/file/d/10DdK...
In particular this drive.google.com/file/d/1s0TT...
and this drive.google.com/file/d/10DdK...
A very rough and partial draft systems thinking reading list
Shared for a friend of a friend Draft systems thinking reading list Benjamin.taylor@systemspractice.org www.linkedin.com/in/antlerboy www.twitter.com/antlerboy Intro A very partial and incomplete l…
stream.syscoi.com
December 1, 2024 at 1:29 PM
I promised you more @ccombe.bsky.social so might as well do it in public here! I've found this reading list incredibly useful stream.syscoi.com/2020/05/06/a...
In particular this drive.google.com/file/d/1s0TT...
and this drive.google.com/file/d/10DdK...
In particular this drive.google.com/file/d/1s0TT...
and this drive.google.com/file/d/10DdK...
Reposted by Simon Rohrer
And
Brian Marick: 'In the 80's, Robert Glass analyzed bugs in fielded avionics software. Found faults of omission most important. I liked his characterization of them: "code not complex enough for the problem''
Jabe Bloom: "Sounds like Ashby's Law."
Brian Marick: 'In the 80's, Robert Glass analyzed bugs in fielded avionics software. Found faults of omission most important. I liked his characterization of them: "code not complex enough for the problem''
Jabe Bloom: "Sounds like Ashby's Law."
![Page with the quote in the post, as well as:
Ashby's Law: Address Variety with Variety Of course, our systems exist in complex contexts, with (generally) complex demands.
"In colloquial terms Ashby's Law has come to be understood as a simple proposition: if a system is to be able to deal successfully with the diversity of challenges that its environment produces, then it needs to have a repertoire of responses which is (at least) as nuanced as the problems thrown up by the environment. So a viable system is one that can handle the variability of its environment. Or, as Ashby put it, only variety can absorb variety." - John Naughton
Jabe Bloom: "The quickest way to explain Ashby's Law is as follows: If I am a fencer and I have 3 ways of thrusting at people, and everybody else has three ways of parrying those thrusts, it will be an even game. [.] I will be as in control as I can be. If someone else figures out another thrust, I will then be required to learn another parry otherwise I will always lose." Implication: The more different kinds of customers your business has, the more complexity you will need to absorb, in order to respond to that.](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:x6y4qbknc3mrsytkcs426i2q/bafkreifbwjbgxrobl4nila7foz4i7jnz42sk4457i72k2ctz55ygsq3y54@jpeg)
November 29, 2024 at 2:44 PM
And
Brian Marick: 'In the 80's, Robert Glass analyzed bugs in fielded avionics software. Found faults of omission most important. I liked his characterization of them: "code not complex enough for the problem''
Jabe Bloom: "Sounds like Ashby's Law."
Brian Marick: 'In the 80's, Robert Glass analyzed bugs in fielded avionics software. Found faults of omission most important. I liked his characterization of them: "code not complex enough for the problem''
Jabe Bloom: "Sounds like Ashby's Law."
Reposted by Simon Rohrer
Summary slide here:
November 28, 2024 at 10:59 PM
Summary slide here:
Reposted by Simon Rohrer
Let me share my take-aways.
1. He borrows from Martin Fowler (a lot) - I like the idea of a conference talk titled "Martin Fowler talked about this 20 years ago!"
1. He borrows from Martin Fowler (a lot) - I like the idea of a conference talk titled "Martin Fowler talked about this 20 years ago!"
November 28, 2024 at 10:59 PM
Let me share my take-aways.
1. He borrows from Martin Fowler (a lot) - I like the idea of a conference talk titled "Martin Fowler talked about this 20 years ago!"
1. He borrows from Martin Fowler (a lot) - I like the idea of a conference talk titled "Martin Fowler talked about this 20 years ago!"
Reposted by Simon Rohrer
This principle matches @ruthmalan.bsky.social and Dana Bredemeyer's "minimalist architecture". More on this in this great article by @esilva.net: esilva.net/tla_insights...
Less is More with Minimalist Architecture, Ruth Malan and Dana Bredemeyer
Independent consulting & resources on sociotechnical systems, architecture, and leadership modernization → scaling sustainable fast flow of change.
esilva.net
November 28, 2024 at 8:27 AM
This principle matches @ruthmalan.bsky.social and Dana Bredemeyer's "minimalist architecture". More on this in this great article by @esilva.net: esilva.net/tla_insights...