Microservice Managed by One Team
Context
Microservices are being adopted. There is a shared responsibility of the microserices between teams. Each team can contribute to the microservice they need to evolve to implement their assigned feature or fix their assigned bug.
Problem
- Comprehending all microservices is too demanding or not possible for the developers
- Finding consense how to evolve a microservice is slow as it requires coordination across teams
- Persons responsible for the overall system have become the central point of contact for everything
Solution
Assign the responsibility if each microservice to exactly one team.
By each team focusing on their owned microservice(s), the scope of the system they need to comprehend is reduced to their microservices and their interactions with other microservices. Further, the clear responsibility allows steering the evolution discussions on a microservice more easily, especially if they given responsibility to act autonomously. Having clearly aligned responsibilities will further relieve coordination efforts of the persons responsible for the overall system as the microservices and their teams will gain better visibility and become the first point of contact to related topics.
As a consequence, teams need to coordinate among each other to avoid fixing other teams' problems in unrelated microservices.
In combination with pushing more responsibilities to the microservice teams, the organizational structure implicates each team has to aggregate the knowledge necessary to manage a microservice through its full lifecycle from requirements engineering to operation. This can be facilitated by cross-functional teams.
Maturity
Proposed, to be evaluated.
Sources of Evidence
L3:
- each team should be responsible for its own services
- functionally separated teams can't benefit from increased comprehensibility of code
- and easier assimilation of new team members that system decomp requires
L8:
- microservice developers need better coordination structures and models that
- promote team autonomy
- take into account system- and org-wide requirements and goals
- => to mitigate risk of situations
- adoption of infrastructure is hard to communicate and reuse across services
- creation of a conflict-avoidance culture where team locally fix probelms in other teams' responsibility
L14:
- team organization is vital for success
- MSA allo assigning responsibility for all concerns of business capabilities (=microservice) to individual teams
- from requirements to operation
- responsibility plus open-source development => yields team's empathy for "their" microservices
- architecture and organizational structure are vertically decomposed
- => enables otto.de to scale development capacities according to new requirements
L17:
- delegation of team responsibilities
- microservices do not have external dependencies => can be developed by different teams independently
- reduces communication overhead and need for coordination among teams
- maintain independent revisions and build envs based on their needs
- distribution of clear and independent responsibilities among teams allows splitting large project team into several small and more efficient teams
L32:
- person who was responsible for a system that migrated to microservices:
- people used to call him for many things
- now they call the person responsible for the relevant microservice directly
- probably because microservice has higher visibility
- because service is developed, released, and operated by an autonomous team
- shorter communication path helps to shorten cycle times
L41:
- common practice: single service can be developed and managed by a single team
- to build system with loosely coupled design => pay attention to org. structure and comm. patterns
- directly affect the produced design (Conway's law)
- if create org with each team working on a single system
- => makes communication more efficient on team level and within whole organization
- => improves the resulting design in terms of modularity
- to build system with loosely coupled design => pay attention to org. structure and comm. patterns
L45:
- Context: DSL metamodel for microservice-based systems
- Team is componsed of one or more developers
- Each microservice is owned by one and only one team
L52:
- responsibility for all developmend and operation activities of microservice is assigned to one team
- expand agility and flexibility for business and IT systems
- fits better to small sized integrated systems and vital in age of digital transformation
L59:
- each microservice is assigned to a development team which monitors it, fixes it, and releases improvements whenever they are ready