Carte Context Mapping #12 : Independent Teams

📇 Carte #12 : Independent Teams (Team Relationship)

Vue Rapide

🎯 Objectif : Deux équipes opèrent indépendamment, zéro dépendance

💼 Type de relation : Aucune (autonome complète)

🔗 Nature : Parallèle, zéro couplage

Concept

Deux équipes qui peuvent progresser complètement indépendamment sans se bloquer.

Team A        Team B
(indépendant) (indépendant)
     ↓ ↓ ↓ ↓ ↓ ↓
    (Zéro couplage)

Caractéristiques

Ce qui les Définit

  • ✓ Zéro dépendances : l’une peut évoluer sans l’autre
  • ✓ Contextes distincts : domaines totalement séparés
  • ✓ Données indépendantes : si partage, c’est via batch/events
  • ✓ Autonomie complète : aucune coordination requise

Ce qui les Différencie des Autres

VS. Upstream/Downstream:
  → Upstream/Downstream = dépendance
  → Independent = zéro dépendance

VS. Mutually Dependent:
  → Mutually Dependent = interdépendance
  → Independent = complètement libres

Idéal dans Microservices

Architecture

Service A (Independent)
├─ Own code
├─ Own database
├─ Own API
└─ Owns its fate

Service B (Independent)
├─ Own code
├─ Own database
├─ Own API
└─ Owns its fate

Coordination: Minimal (maybe async events)

Implications Organisationnelles

Avantages

  • ✓ Complète autonomie : pas d’attendre l’autre
  • ✓ Vitesse : chacun va à son rythme
  • ✓ Ownership : claire et motivante
  • ✓ Scaling : ajoute équipes sans syncro
  • ✓ Failure isolation : équipe A crash pas équipe B

Challenges

  • ⚠️ Duplication : chacun implémente sa version
  • ⚠️ Incohérence : les deux ont des approches différentes
  • ⚠️ Outils différents : pas d’unification possible
  • ⚠️ Learning silos : pas de partage de connaissance
  • ⚠️ Onboarding : chacun a sa culture

Communication: Quand Nécessaire

Pattern 1: Asynchronous Events

Team A does something
    ↓
Publishes event (OrderPlaced)
    ↓
Team B picks it up (async)
    ↓
No blocking, no real-time sync

Pattern 2: Read-Only Access

Team A owns data
Team B reads it (if needed)
    ↓
No writes between them
    ↓
Team B can lag behind

Pattern 3: Batch Sync

Team A exports data nightly
    ↓
Team B imports nightly
    ↓
Updates 24h later
    ↓
Acceptable delay

Pattern 4: Complete Separation

Team A: doesn't know B exists
Team B: doesn't know A exists
    ↓
Zero communication

Exemples du Monde Réel

SaaS Platform

Auth Team
├─ Handles user login/security
├─ Owns user DB
└─ Exposes API

Reporting Team
├─ Handles analytics/reports
├─ Owns analytics DB
├─ Reads user data (read-only)
└─ Zero coordination needed

Content Team
├─ Manages blog/docs
├─ Owns content DB
└─ Completely separate

E-commerce

Order Service Team
├─ Orders only
├─ Can scale independently
└─ Publishes OrderPlaced events

Inventory Service Team
├─ Inventory only
├─ Listens to OrderPlaced
├─ Decrements stock asynchronously
└─ No blocking dependency

Analytics Team
├─ Reads events (Order, Inventory)
├─ Processes asynchronously
└─ No impact on live systems

Governance

Decision Making

Team A decides its direction → Done
Team B decides its direction → Done
No vetoes, no blocking

Shared Resources?

If need shared infrastructure:
  → Infrastructure team is independent too
  → Or dedicated team owns it
  → But integration still async/event-based

Conflicts

Conflict between teams?
  → Each goes its own way
  → Or escalate to higher-level alignment

Trade-offs

When It’s Perfect

✓ Service A: Payments
✓ Service B: Marketing/Email
✓ Service C: Analytics

→ These can be completely independent
→ Perfect microservices setup

When It’s Not Possible

✗ Frontend & Backend of same product
  → Too coupled, need Partnership or Shared Kernel

✗ Inventory & Orders
  → Need synchronization, not truly independent

✗ Core Platform & Applications
  → Core is needed by apps, Upstream/Downstream better

Cost Analysis

Infrastructure

Benefit: Can scale each independently
Cost: More infrastructure, more databases
Trade-off: Worth it for high-scale systems

Development

Benefit: Teams move fast, no waiting
Cost: Potential duplication, less sharing
Trade-off: Speed > DRY principle (in microservices)

Operational

Benefit: Failure isolated
Cost: More systems to monitor
Trade-off: Worth it for reliability

Indicators

Independence Healthy ✅

✓ Teams deploy independently
✓ No blocking on each other
✓ Different tech stacks OK
✓ Minimal communication meetings
✓ Each owns their metrics

Independence Problematic ❌

❌ Frequent cross-team meetings
❌ Waiting on each other
❌ Duplication becoming costly
❌ Incohesive systems
❌ Can't deploy independently

When to Choose Independence

Right Fit

  • Small, focused services
  • High-scale systems
  • Different business domains
  • Different maturity levels
  • Different technology choices needed

Wrong Fit

  • Tightly coupled features
  • Need real-time consistency
  • Shared data models
  • Young team (need learning)
  • Not enough scale to justify overhead

Checklist per Independent Teams ✓

  • Completely separate code/data/deployment
  • Communication plan (events, async, batch)
  • Monitoring of each service independently
  • Failure scenarios handled independently
  • No hidden dependencies (audit for coupling)
  • Teams feel autonomous (survey culture)

Transitioning to Independence

From Dependent to Independent

Mutually Dependent
    ↓ (too slow)
Try Partner → Still coupled
    ↓
Extract: one becomes independent
    → Shared Kernel of critical shared data only
    → Events for everything else
    → Now mostly Independent

From Monolith to Independent

Monolith (all one team)
    ↓ (slow to scale)
Strangler Pattern:
    ├─ Extract Service A
    ├─ Service A becomes Independent
    ├─ Extract Service B
    ├─ Service B becomes Independent
    ├─ ...repeat...
    └─ Monolith eventually sunset

Ressources

  • Building Microservices par Sam Newman - Team Topology
  • Team Topologies par Matthew Skelton - X-as-a-Service
  • Release It! par Michael Nygard - Microservice Coordination
  • DDD Crew - Context Mapping

Notes de Facilitation pour l’Atelier

Animation

  • Demandez : “Êtes-vous vraiment indépendants ?”
  • Testez : “Qu’arrive-t-il si Service X casse ?”
  • Documentez : “Quelles sont vos vraies dépendances ?”

Pièges Communs

  • ⚠️ Dépendances cachées : “Pensaient-ils être indépendants, mais…”
  • ⚠️ Trop de duplication : coûteux à maintenir
  • ⚠️ Inconsistences : données divergent
  • ⚠️ Organisation tue architecture : réorgé casse l’indépendance

Questions Provocatrices

  • “Si je change Service A, affecte-t-ça Service B ?”
  • “Combien de personnes doivent se synchroniser ?”
  • “Est-ce vraiment de l’indépendance ou du chaos ?”
  • “Pourriez-vous déployer Service A sans toucher Service B ?”