I love the balanced discussion of the different options, and how you started with the story of how the problem develops over time.
We often read solutions that are focused on showing "the perfect solution" (tm), but in the end ignore the fact that code, architecture, team structure, all evolve over time, and what is a great solution today, won't be tomorrow!
But I miss something fundamental. It's not core to your article, but by not talking about how the organization affects architecture choices I think you are missing a key piece that is key for managers wanting to keep their architecture appropriate over time (not just find "the perfect solution" (tm)).
You don't discuss Conway's Law and how the choices we make in organization affect the architecture that the code ends up manifesting.
In other words, your article is missing the people+organization aspect of the very same problem. And I think it will inform your proposed solution, but also validate some other solutions depending on the context of the reader.
Yes, I intentionally left Conway's Law outside the article to make it super long. If we add the people+organization dimension, I wouldn't be able to emphasize enough the stream-aligned teams as XaaS combination consequences.
Even though I think you can infer some consequences of each collaboration between teams, and how it can affect architecture, and vice versa.
Hope it makes the cut in a future article. People thinking Tech (architecture in thia case)is the only dimension for decision making is a huge obstacle to growth in our industry, and a cause of many misunderstandings.
Your blog is a great resource! I always find your discussions about API testing helpful. Recently, I focused on API mocking, and using EchoAPI has allowed me to simulate responses seamlessly, which has significantly improved my development process.
I love the balanced discussion of the different options, and how you started with the story of how the problem develops over time.
We often read solutions that are focused on showing "the perfect solution" (tm), but in the end ignore the fact that code, architecture, team structure, all evolve over time, and what is a great solution today, won't be tomorrow!
But I miss something fundamental. It's not core to your article, but by not talking about how the organization affects architecture choices I think you are missing a key piece that is key for managers wanting to keep their architecture appropriate over time (not just find "the perfect solution" (tm)).
You don't discuss Conway's Law and how the choices we make in organization affect the architecture that the code ends up manifesting.
In other words, your article is missing the people+organization aspect of the very same problem. And I think it will inform your proposed solution, but also validate some other solutions depending on the context of the reader.
Thank you for your comment, Vasco 😄.
Yes, I intentionally left Conway's Law outside the article to make it super long. If we add the people+organization dimension, I wouldn't be able to emphasize enough the stream-aligned teams as XaaS combination consequences.
Even though I think you can infer some consequences of each collaboration between teams, and how it can affect architecture, and vice versa.
Hope it makes the cut in a future article. People thinking Tech (architecture in thia case)is the only dimension for decision making is a huge obstacle to growth in our industry, and a cause of many misunderstandings.
Your blog is a great resource! I always find your discussions about API testing helpful. Recently, I focused on API mocking, and using EchoAPI has allowed me to simulate responses seamlessly, which has significantly improved my development process.