A monolith? No, we don’t have that anymore!

Do a search on monolithic applications in your favorite search engine and chances are the first page(s) of links will all be about converting a Monolithic application to microservices. A large number of these links are articles that are also posted for commercial purposes and invariably end with the offer to help transition from monolithic applications to a microservice landscape.

This is a hotly debated topic for good reason; monolithic applications can bring advantages, but especially as applications grow, the disadvantages will outweigh the advantages.

The application monolith is actually one application, usually with a central database. Especially when it comes to smaller applications, a monolith has many advantages: it is easier to develop, test and put into production, it is uncluttered and management is easy. Once an application starts to grow and more people or teams start working on it, the drawbacks quickly become apparent: the application becomes complex, new features become increasingly difficult to test and release, and as a result, it takes longer and longer for new versions to enter production. It is also increasingly difficult to scale the application for more users and better stability.

So breaking up the monolithic application into a microservice landscape is a logical first step. But, as I wrote in the introduction: there are more variations of the monolith. Variants that arise after an application is split monolithically, as well as variants that are separate from it. Time to add some examples to that.

After a period of hard work, the teams got it done: the monolithic application is split up, each microservices has its own database, new features can be added again. However, the process around development has remained the same: teams develop features, complete them within a sprint, and at the end of the sprint, the features from all the teams are prepared together to be tested and released. Perhaps because existing build and release procedures are still in use, but more often because there are too many dependencies between different microservices or parts of the code. In any case, the result is still not a pure split, and what we see emerging is the monolithic build!

Another common monolith is the monolithic release. Again, dependencies are loosened, but components are ultimately released together. This may be done for process reasons; for example, a QA team needs to test new features or a product owner needs to approve features. The result is still a monolith. There are no autonomous services with independent testing and release processes, and the development team still cannot operate autonomously.

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.

Many organizations are going through the same growth, from monolithic application to a different landscape. Migrating to a different landscape just doesn’t always bring what was expected. It helps to think beyond the application monolith! Is your organization well set up to deal with these changes or do you need to go much further in adapting the way you work?

Actually, it is not so much about the monolith itself, but about the underlying issues. Much more often it is about autonomy and ownership. Teams must be able to make choices independently and have true ownership of their software. Not only when it comes to new features, but also owner of releases, management and user feedback. Autonomy, and with it trust, is so important that even the layout of the workplace can contribute to success.

From thinking about the monolith, you automatically come to other topics. Think Devops, Testing, Software Development, Agile working, etc. If you can’t see the forest for the trees, or just want to exchange thoughts about monoliths, feel free to contact me!

• Team Topologies: Organizing Business and Technology Teams for Fast Flow
• Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations