Conway stated this law in 1967, but its power was appreciated only when micro service-based architecture became mainstream. Since communication structure is organization structure, people were stunned when they saw how closely service architecture resembles org charts.
Like the uncertainty principle, this law is fundamental and does not depend upon tooling advancement.
There have been various attempts to change organizational structure to meet technology needs, especially in the name of agile self-organizing teams. It's futile and breaks the core premise of technology to serve the business and not the other way around.
Domain Driven Design: Celebrating the Constraints
Organizational constraints exist because that's the effective way to operate.
For example, when I worked for a bank, the production database's unapproved look-up of celebrity account information was subject to immediate firing. I am sure this rule was the same when this bank had mobile branches on a stagecoach in the nineteenth century.
In DDD, these clusters, where everything is aligned to a specific function, are called domains. A service (or a set of services) only has meaning when looking from the perspective of a domain; therefore is called bounded context. Each bounded context can be a fiefdom with its own rules and model.
Business vs. Engineering
At the aforementioned stagecoach bank, I noticed another interesting dynamic. The engineering and business teams were like water-tight compartments despite being on the same floor. In addition, in all my working experience, I experienced the most organized requirements with minor scope creep there.
This puts into question the idea of self-organizing teams, an agile tenet that sometimes is taken too far. Within a domain or, even more specifically, within a bounded context, self-organizing teams work like a charm. When you cross those boundaries, technology needs to align to respect those boundaries.
How to overcome established boundaries between product managers and software engineers with the power of ephemeral environments and preview URLs
One boundary which needs to be navigated skillfully here is between product managers and engineers. Product managers typically either have to sit next to developers (breaking the natural boundaries) or wait for the release to happen before they are able to give feedback.
The Roost platform solves this problem.
It provides product managers the ability to provide live feedback on a release with the power of preview URLs. It's done during the critical path of a release rather than asynchronous process.