📇 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
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 ✓
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 ?”
