Having this kind of organization is not so easy. But it is a good way to have different teams that keep developing features following the stop-starting, start-finishing principle. In addition, if any difficulty emerges, the team has all the necessary skills to handle it independently.
Communication is easier. There is less stress. Quality and performance increase.
Know-how and skills: without them, the feature team struggles to collaborate
It is fundamental to know the business context and to have technical skills for a good team’s collaboration.
We know how difficult it is to be a real full-stack developer. What is important is that there is a specialization but with different skills that allow easily moving within a given situation. This is the T-shape model: verticalization on one competence but the ability to move horizontally on all the others.
If know-how and skills are missing, the team can’t be autonomous and ends up organizing itself into components rather than features. The organization in components is risky, because the components may not correctly fit together and lead to interdependencies which can generate the waiting lines we were talking about at the beginning.
The Conway’s Law
According to Conway’s law, the corporate organization and how the areas communicate with each other are reflected in the company’s IT system.
If a company is organized in silos, the organization will produce monolithic designs. IT will have monoliths. By defining how departments interact with each other, I will have IT systems that converse the same way.
So, let’s try to build from scratch our IT system, first of all thinking about business aspects instead of architectural design.
Let’s go back to our e-commerce with a series of features to implement: product availability, catalog, pricing, customers, logistics, reviews and customer care, communication engines, billing, etc.
If we take these features and divide them among our teams, each of them will have its own responsibility for the set of features.
So let’s see how, starting from a business domain, we can build IT architectures that reflect the organization and, therefore, how the microservices architectural style can facilitate the work of feature teams.
It is important to refer to architectural style rather than design pattern when we talk about microservices because just as artistic styles are interpretable, the design used for microservices is also interpretable and must be contextualized as appropriate.
Nobody will tell how big a microservice should be, how granular, and how it should communicate. It always depends on the specific case.