The aforementioned monoliths are often the result of application monolith splitting. However, there are other variants not directly related to this.
The monolithic model assumes a single domain language and representation (single view of the world). For smaller organizations, this will probably still work but for larger organizations with different user groups, it will have major limitations. Eric Evans’ book Domain Driven Design explores this in depth, how to create software that better reflects reality, the importance of domain language and splitting up different domains.
Organizations often try to standardize components, such as making build and release scripts reusable. Anything to take as much work off teams’ hands as possible and reduce the “cognitive load,” as also frequently described in Team Topologies. However, this monolithic thinking also creates many obstacles. Engineers are no longer challenged to do what they do best – solve problems with the best techniques and technologies. Monolithic thinking can lead to decreased motivation, less experimentation, poor solution choices and other problems as also described in Accelerate.
A final, perhaps surprising variation is the monolithic shop floor. Everyone is familiar with the office garden, large spaces where everyone works through, by and with each other. It often looks nice and sounds effective on paper. But in practice, it often works differently. As also described in Team Topologies, from research
found that face-to-face interaction is decreasing by more than 70% while digital communication is increasing. The idea is not to put all people as close together as possible (the monolith) but rather to think about getting people to cooperate and communicate purposefully. Team Topologies even includes specific chapters on “team-first” office layout and various forms of team interaction.