Is organizational unpreparedness a dark matter force?

microservice architecture   architecting   dark energy and dark matter   Microservices adoption   anti-patterns  

---

These days I write and talk a lot about the dark energy and matter forces and how they shape a microservice architecture. The dark energy forces encourage decomposition whereas the dark matter forces resist decomposition. The five dark matter forces are technical in nature and include Prefer ACID over BASE and Minimize runtime coupling. However, based on how many organizations struggle to adopt microservices, I’m wondering whether there is a sixth dark matter force: Organizational Unpreparedness. In other words, if an organization is not willing or able to use the microservice architecture properly, it might be better off sticking with the monolithic architecture.

There are several obstacles that an organization must overcome to successfully adopt microservices:

• Microservices require rigorous design skills
• Adopting microservices requires a learning culture
• Microservices require the rest of the success triangle

Let’s look at each one in turn.

Microservices require rigorous design skills

Software design is difficult. It’s something that many developers struggle with. Unfortunately, the microservice architecture requires rigorous design skills. And to make matters worse, it’s much less forgiving of bad design decisions than a monolith architecture.

For example, the consequences of two tightly design-time coupled packages in a monolith is not as severe as two tightly coupled microservices. A monolith has a single code base and so changing two packages simultaneously is relatively easy. It’s a single commit. But in a microservice architecture, each service has multiple code base and is deployed independently. Consequently, changing two microservices is much more difficult and expensive. You often have to evolve APIs and carefully coordinate the release of changes.

To avoid poor design, a microservice architecture requires a much higher level of rigor than a monolith architecture. An organization that wants to adopt microservice architecture must be prepared to honestly assess its developers’ design skills. And, if they are lacking, be prepared to invest in training and mentoring.

Adopting microservices requires a learning culture

Adopting microservices is, by definition, doing something new. But to do something new, an organization needs to have a culture that embraces change and tolerates failure. Unfortunately, many organizations have a culture that is the opposite of this: a culture that is risk averse and intolerant of failure. Since it’s inevitable that mistakes will be made, such a culture can be a significant obstacle to adopting microservices.

The solution is, of course, for an organization to change its culture to a Westrum generative culture.

Microservices require the rest of the success triangle

The microservice architecture is 1/3rd of the success triangle. In order to benefit from the microservice architecture, you must almost always adopt the other two elements of the success triangle: DevOps as defined by the DevOps handbook; and an organization structure consisting of small, loosely coupled teams, as described by Team Topologies.

Unfortunately, many organizations struggle with adopting team topologies and DevOps, since they involves changing how people work. Adopting Team topologies requires an organization to break down traditional silos, which can be difficult. Organizations also struggle with DevOps for the same reasons that they struggle with Agile: a mismatch in culture; difficulty embracing empowerment and autonomy; and confusion about about what it actually is. For example, a common misconception is that DevOps is a role, when in fact it’s a set of principles and practices for delivering software rapidly, frequently, and reliably. It’s common for an organization to hire DevOps engineers who are responsible for infrastructure automation.

The solution, for course, is for an organization to commit to properly understanding and adopting DevOps and Team Topologies.

Summary

In order to use the microservice architecture properly an organization must be prepared to do the following:

• Ensure through training and mentoring that its developers have rigorous software design skills
• Have, or be willing to have, a generative culture that embraces change and tolerates failure.
• Adopt the other 2/3rds of the success triangle - DevOps and Team Topologies - in order to benefit from microservices

If an organization is unwilling or unable to do these things, it might be better off sticking with the monolithic architecture.

What do you think?

I’m curious to hear what you think. Please let me know.

Need help migrating to microservices?

I’m available to help your organization adopt microservices. I provide consulting and workshops.