Speaking of team topologies, one of the key aspects is setting the boundaries. Ignoring this can lead to problems like poor ownership, disengagement and inefficiency.
Conway’s law tells us that unclear boundaries between teams often reflect in software architectures where there is high coupling between components, forming a monolith.
To apply the reverse Conway maneuver, it’s important to understand the different kinds of monoliths and find the best fracture planes, i.e., the criteria to split architecture components and organize teams.
You might have one or more of these monoliths right behind you without even realizing it. Let’s dig deeper into some examples to help us recognize them, develop a better sense of awareness and then consider how to manage them.
Let’s explore the various types of monoliths we might come across and examine how they affect different layers:
- application: this type of monolith occurs when an application grows large and complex with many dependencies. It’s often used for a variety of needs, making it difficult to manage and maintain. The complexity can lead to slower development cycles and increased risk of bugs
- datastore: when multiple services compete for a database or schema, making it hard to manage the software lifecycle independently. DBAs are typically involved not only in managing the system but also in coordinating changes, which can become a bottleneck, slowing down the development process and increasing the risk of errors
- build: usually derived from an application-level monolith but can also occur when more granular services are built in bulk rather than using mechanisms that account for dependencies. This can lead to longer build times and increased complexity in managing dependencies
- deploy: when a “release” bundles components that could be managed separately to test them all together, including the latest versions of each component. This can happen when there is a team responsible for QA that is isolated and has limited capacity, leading to potential bottlenecks in the deployment process
- semantic: the interpretation of a single domain is forced for data and services that would naturally cross these boundaries. This then imposes limits on the software and data when actors from other domains need to use them, potentially leading to inefficiencies and inconsistencies
- mindset: when there is a tendency to standardize and generalize, fooling oneself that a “one size fits all” approach can simplify management, reduce costs, meet all needs, and survive over time. This limits the feasible solutions and inhibits the possibility of introducing new approaches and tools, and in general, polyglotism, putting a brake on the entire organization. Forcing standardization limits learning and experimentation, stifling innovation
- workplace: when there is confusion between colocation of purpose vs colocation of bodies. It’s surprising how some studies have shown that putting all people in the same place actually decreases interactions in many cases, potentially leading to reduced collaboration and communication
- are there any types of monoliths that you hadn’t considered before?
- how do you plan to tackle them?
- how does your organization handle these different types of monoliths?
Understanding and managing different types of monoliths is crucial for modern organizations to optimize efficiency and foster innovation. Identifying and addressing these monoliths reduces bottlenecks and enhances team dynamics. Clear boundaries and domain-driven design mitigate complexity, while encouraging experimentation and polyglotism stimulates innovation.
