Microservices empower the organization with speed. They allow the organization to respond to the market in a quicker fashion. They improve the productivity, delivery, and, of course, the speed in delivering projects. The challenge in this format is to align your team inside the organization around this architecture efficiently. Microservices don't suit or fit every organization. Implementing microservice architecture can tweak the parameters inside the organization also.
Business capability can be defined as an independent operation service for a particular purpose in business. Business capability in the organization can be defined at each level/domain. The upper management level can have different capability definitions, operations can have different ones, sales can have different ones, technology can have different ones, and so on. So, identify the fine grain business capability and arrange the microservice around them.
Business capability and microservice seem to be the same by definition, but they is not. Running a promotional campaign is a business capability for the marketing department. After identifying this capability, start arranging the microservice component around it, such as email sender service, promotion link generator service, data collector service, and so on. It's a two-step process:
- Identifying the correct business capability.
- Defining the microservice component around it.
Both steps have to be done and fine grained as much as possible. This will help design the architecture efficiently.
Another important factor is communication. Communication is a live wire in any business and in any form. There can be communication between teams, between organization and end user to get constant feedback, communication between different levels of management (upper, middle, lower ), and even communication between components of the software system of that organization. There is a law that relates communication between software components and how communication happens within the organization. The law is Conway's law.
As per Conway's law, Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
This may seem hard to believe or may not be a valid statement to some people initially. Regardless of that, some of the well-known institutions such as MIT and Harvard take it seriously. They have done studies on this law, and compared some code based with the organization structure under which these codes develop. What they found is that this law works! Yes, indeed, 90 percent code bases in different segments, as they picked for their study, aligned perfectly to this statement. To understand it more let's see how it is proven in a monolithic application case. If you have one big developer team that is co-located in the same building, you will end up in a monolithic application. On the other hand, if you have small teams, members of one team should be co-located, but teams may not necessarily be co-located. Then, you will end up having distributed or multi-module application architecture, as in the open source projects. Open source projects have a kind of distributed and modular architecture. They have a number of small teams (even with a single member in a team) rather than one big co-located team. Then, these teams are not co-located. This law doesn't tell us anything about microservices, but it tells us how the team structure or organization structure can affect application design.
As per the law, the application architecture will be a copy of your organizational structure, but there is a high chance that your organizational structure can also have an impact on your application architecture. Team locations and team communication impact the application architecture, which can result in an aligned organization structure.
If an organization has five teams with four team members in each team, we encounter a situation where it is not easy to break down a service to be handled by one team. The joining of two teams could be a solution here. This is basically changing the organizational structure around application architecture.
However, each company has its paradigm, business capabilities and objectives, dynamics, team structure, and communication methods. Implementing microservice architecture can change the organizational dynamics and structure. Any organization should study its own current structure and communication methods so that they can land in the best of their microservice architecture.