As the pace of change in our world accelerates, businesses must be agile to adapt to these changes. This requires an application landscape that is equally flexible to cater to these needs. While one popular idea is to break down applications into smaller services to enable teams to react to changes quickly and independently, simply breaking down the application into smaller services does not necessarily result in more agility.

The reason for this is that breaking an application down into smaller services merely changes the application from a single monolith to a distributed monolith. To have a real impact on agility, it is essential to understand what kind of monoliths exist out there. “Team Topologies” by Matthew Skelton and Manuel Pais is a great resource on this topic, and the book mentions seven types of monoliths.

While all of these monolith types are important to understand, I have encountered the first four in the projects that I have worked on at various points in time:

1. Application Monolith:

A single, large application with many dependencies and responsibilities that may expose many services and/or different user journeys.

2. Joined-at-the-Database Monolith:

Composed of several applications or services, all coupled to the same database schema, making them difficult to change, test, and deploy separately.

3. Monolithic Builds (Rebuild Everything):

Uses one gigantic continuous-integration (CI) build to get a new version of a component.

4. Monolithic (Coupled) Releases:

A set of smaller components bundled together into a “release.”

To achieve true agility, it is important to understand the type of monolith you are dealing with and adopt the right approach accordingly. While breaking down an application into smaller services can be a step in the right direction, it is not a guarantee of increased agility. By understanding the kind of monolith you are dealing with, you can ensure that your application landscape is not just flexible but also optimized for your specific needs