I've seen a very large company fail due to the very same idea you mentioned. The organization wanted to completely change the technology and architecture without changing the organization's mentality, processes, bureaucracy and way of dealing with change.
The plan was to split a huge monolith into an event driven architecture. Bounded contexts were found, teams were split in capabilities and DDD became the de facto approach. Scrum wanted to be adopted and we religiously practiced it within the teams, but we were not autonomous because above us there wasn't an understanding of it nor a willing to adopt it at an organizational level. A canonical model was given to us as a "solution" attempt to model the whole organization and communicate between domains. This canonical model, of course, didn't satisfy anyone bin an attempt to satisfy everyone, so every capability had their own Anti Corruption Layer and a great amount of effort was put into it with requirements to satisfy output canonical model rather than our own domain functional needs.
We had product owners per capability but there was no real product owner per product, no role had the needed overall view of functional needs so these were being dictated by Enterprise architects and their canonical model, not by business.
We soon found out the business mentality struggled with event driven architectures and asynchronous nature. Business kept pushing functional requirements that didn't fit with the way capabilities were split and eventual consistency started becoming a problem because they refused to design requirements around it. We ended up with requirements that required synchronous communication and coupling needs between capabilities to satisfy things that were not really required but "they were like this in the monolith".
We were building distributed monoliths without the benefits of event driven architectures and with the complexity of distributed systems to provide a global view of all the pieces.
When I left the company the plan was restructure things again around the canonical model, embracing it, and have a more monolithic approach.
Nobody really knows what the exact problem was but most of the devs suspect it was due to an approach at the technical level for which the business was not really prepared to make their respective changes. Their mind was often more around power concerns and how the changes would affect their positions. Of course my view and opinion is biased and the reality might have been more complex, but no one ever asked us and probably it would have been wise to get some feedback and take it into consideration.
I think the story reflects a common case in traditional organizations with hierarchical structures where the decisions of a small committee that act as a single point of failure. Even if cultural changes must be lead by someone, changes need to be done in small steps, guided by a long-term strategy. It's better if those changes are actually driven by teams.
Thanks!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've seen a very large company fail due to the very same idea you mentioned. The organization wanted to completely change the technology and architecture without changing the organization's mentality, processes, bureaucracy and way of dealing with change.
The plan was to split a huge monolith into an event driven architecture. Bounded contexts were found, teams were split in capabilities and DDD became the de facto approach. Scrum wanted to be adopted and we religiously practiced it within the teams, but we were not autonomous because above us there wasn't an understanding of it nor a willing to adopt it at an organizational level. A canonical model was given to us as a "solution" attempt to model the whole organization and communicate between domains. This canonical model, of course, didn't satisfy anyone bin an attempt to satisfy everyone, so every capability had their own Anti Corruption Layer and a great amount of effort was put into it with requirements to satisfy output canonical model rather than our own domain functional needs.
We had product owners per capability but there was no real product owner per product, no role had the needed overall view of functional needs so these were being dictated by Enterprise architects and their canonical model, not by business.
We soon found out the business mentality struggled with event driven architectures and asynchronous nature. Business kept pushing functional requirements that didn't fit with the way capabilities were split and eventual consistency started becoming a problem because they refused to design requirements around it. We ended up with requirements that required synchronous communication and coupling needs between capabilities to satisfy things that were not really required but "they were like this in the monolith".
We were building distributed monoliths without the benefits of event driven architectures and with the complexity of distributed systems to provide a global view of all the pieces.
When I left the company the plan was restructure things again around the canonical model, embracing it, and have a more monolithic approach.
Nobody really knows what the exact problem was but most of the devs suspect it was due to an approach at the technical level for which the business was not really prepared to make their respective changes. Their mind was often more around power concerns and how the changes would affect their positions. Of course my view and opinion is biased and the reality might have been more complex, but no one ever asked us and probably it would have been wise to get some feedback and take it into consideration.
PS: very interesting article! Thank you
Thanks Diego for your feedback and the story!
I think the story reflects a common case in traditional organizations with hierarchical structures where the decisions of a small committee that act as a single point of failure. Even if cultural changes must be lead by someone, changes need to be done in small steps, guided by a long-term strategy. It's better if those changes are actually driven by teams.
Thanks!