Skip to main content

Thematic Boards for Decision Making

Context​

Microservices are being adopted. There are multiple teams, each responsible for their certain microservice(s).

Problem​

  • Information is not flowing across the teams in certain roles.
    • E.g., there is a marketing campaign upcoming that might increase the load on the system, but only a few teams are aware of it.
  • There is no process for global decision making
  • Global decisions (e.g., architecture) lack the backing of the teams, are questioned over and over, or are even partially even ignored.

Solution​

Build horizontal communication structures between teams that connect certain roles of the cross-functional teams with the same roles of other teams.

The tasks of those global boards can be:

  • keeping an overview of their topic (e.g. architecture),
  • dispersion of information regarding their topic across teams,
  • making critical decisions in their topic (e.g. introducing standards), and
  • managing shared capabilities regarding their topic (e.g. routing in edge server).

For decision-making, teams send their representative to a global decision-making board where upcoming and urgent global topics are discussed and decided. There can be a chairman for the meetings (e.g. the system architect in the architecture board) who prepares and moderates the meeting and might even have the final decision power. However, the representatives of the teams should at least be heard because building forming a consensus from within the teams will increase the acceptance of the changes.

In parallel to these global board meetings, there is the need for local coordination as well. For example, detailed API decisions only affecting 2 teams should be done via ad-hoc communication. The decision criteria for relevant topics in the global board meetings is whether there is a global interest in the topic or if it affects only a minority of teams.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

L3:

  • Figure 5 shows cross-functional teams
  • and one "core team" made by representatives of different roles of the teams
    • responsibility: shared capabilities
    • overview overall view over architecture
    • critical architecture decisions
    • handles interservice refactoring (moving functionality from one service to another)
    • updates rules in edge server

L17:

  • need to coordinate high-level and technical decisions among teams
  • other technical decisions (different internal structure, different technologies) can be decided within teams

L22:

  • need for generalists dealing with cross-cutting aspects in distributed systems
    • cross-domain solution development
    • cross-domain testing
    • cross-domain service fulfillment
    • => should be part of the new culture

Interview B:

  • Each team sends architecture affine representative to architecture board
  • Responsibilities
    • What is done in gateway
    • What does the service mash sidecar

Interview C:

  • Need for an interface committee
  • Each team sends microservice-specific architect to global architecture meeting
    • Sending all does probably not work
  • In project beginning more time required
  • In parallel: local agreements where others have no need to participate
  • Overlay structure often seen in connection with background knowledge and culture
  • Need for at least informal network between people of same roles
    • example: business people need all to know about starting marketing campaign which might lead to load spike

Interview D:

  • Architect and product manager can be a role and not only a single person
  • For standardization: send representatives of each team to a macro-architecture meeting
    • Goal: come to a consensus quickly

Interview E:

  • Context: style guide for common look & feel of UI
    • Two ways to emerge:
      1. guild system (design guild) that manages the style guide
        • Makes sense if there are design affine people. Avoids having a revolution. Psychological advantage that everyone contributed to the solution
      2. UX expert defines style guide and consults teams
        • Makes sense if teams don't want to think about it, glad to have some guidelines. Seems to be especially the case with UX
  • Context: standards
    • Usually not a democratic process, but a central team has responsibilitiy and makes the decision
    • Sometimes people are invovled
      • Feeling that they contributed
      • Sometimes people also really interested in their thoguhts
    • Top-down has advantage to avoid personal issues
    • Architect-team often decides with having in mind that they need to be able maintain the decision over time

Interview F:

  • Context: how do standards like how lists in API are handled emerge?
  • Either demanded by customer
  • Or decided by lead architect
    • usually planned ahead, had an overview what was upcoming
    • had a team of people that assisted (architect-role of each microservice as representative)
  • Making sure that standards are met?
    • Used audits that they had anyway (documentation, processes,...)
    • Incrementally added standards with milestones stating what has to be implemented until when
  • Responsibilities of architecture gremium
    • Interfaces between teams and services
    • Also sequence of interactions
    • Where data is goverened => data privacy
    • How data is deleted after logout etc.