Skip to main content

Align Architecture with Organizational Structure

Context​

Microservices are being adopted. There are horizontally aligned teams, e.g., a quality assurance team, a development team, a database team, and an operation team.

Problem​

  • The development cycles are slow as there is a hand-off between each of the horizontal teams

Solution​

Align the organizational structure to the software architecture and vice verca. Microservices cut the domain in vertical silos, and so should the teams follow a vertical distribution instead of a vertical one. When organizing all horizontal functions within a team, there is no need of a handoff. This reduction of coordination increases the speed of the development cycles.

The principle behind this technique is known as Conway's Law and its reversal. Organizations tend to produce system designs that reflect organizations communication structures. In its reversal form, the communication structures in the organizations manifest themselves in the system design as well.

In combination with assigning exactly one team as responsible for a microservice, 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​

L4:

  • "business and architecture isomorphism"
    • business and design of your system should be very similar
    • when looking at business, you should see your IT system and the other way around

L6:

  • organizational alignment: org around business capabilities
    • motivates smaller focused teams working on components with smaller codebase

L14:

  • Otto.de used Conway's law
    • started with 4 teams
    • led automatically to vertically decomposed application
    • today 18 teams on 45 applications in 12 so-called "verticals"
  • Organization vertically decomposed (as well as architecture)
    • (+) enables to scale dev capacities according to new requirements

L22:

  • James: Conway's law influenced org structure when building teams
    • might enable to shortcut decisions about integration patterns, tools, etc. at boundary between different org units.
    • cites "Inverse Conway maneuver": "build the organization you want; the architecture will follow kicking and screaming."
  • Nicolai: Conway's law
    • => as soon as discussing use cases/business processes spanning multiple domains
    • => find out about required changes in roles and responsibilities because requirement smells
    • => establish org structures to deal with business domains effectively and efficiently
    • => suited software interfaces emerge by themselves by just letting the structures work
  • You can't win if you fight against Conway
    • => management should not fight establishing org structures

L34:

  • Conway's Law: "Organizations, which design systems are constrained to produce designs which are copies of the communication structures of theses organizations."

L41:

  • Microservice should be developable manageable by exactly one team
  • Conway's law => pay attention to org structure to build modular and loosely coupled design
  • More efficient communication on team level, but also within whole org => improves modularity of design

L53:

  • Team structure alignment (Conway's law)

LN39:

  • Refactoring might lead to altered org. structure
  • cites Conway's Law: orgs tend to produce system designs that reflect orgs communicaiton structures
  • => architecture and organization are indenepdent to some degree, further distinguishes the process from pure code refactoring

LN43:

  • cites Conway's Law: orgs that build microservices need to adapt their communicaiton structure to new style of architecture
    • otherwise: conflict between org structure and the structure of architecture design will cause problems
  • challenge: structure of organization
    • must aligh with structure of application architecture
    • if previously monolithic app with big teams for quality assurance, development, db administration, ...
      • each team is very good in specialized area
      • need to collaborate to deliver business functionality
      • hand-off process before a release => slower development cycles
      • => does not work with microservices
    • if monolithic org. structure, microservices do not work
    • => split big teams into smaller teams that work autonomously
      • more autonomy considering their releases
      • no hand-off process to a third party
      • teams do not need to wait for other teams to complete their changes
      • changes to one functionality (e.g., invoices) requires changes only on the service delivering this functionality
      • reduces need for fain-grained communication

LM43:

  • Context: SLR findings about microservices in DevOps
  • S24 suggests monolithic organizational structure needs to be aligned with architecture of MSA based systems

Interview C:

  • Conway's law: component structure mirror of organization structure and the other way around
  • "Microservice = Component++"

Interview F:

  • experienced Conway's law
    • different suppliers delivered different functioalities that are composed to a product in the end
    • can be projected well on microservices with the boundaries between teams
  • org structure takes influence on service cut => sometimes company politics
    • in their project: data treasury that had to be in one team, others had to have no access
    • grouped the other remaining teams around that where they saw fit to cut other microservices
  • difficulty with orthogonal topics that repeat everywhere
    • classic thinking in departments: proven to work over a long period of time