Carte Context Mapping #11 : Upstream/Downstream Teams

📇 Carte #11 : Upstream/Downstream Teams (Team Relationship)

Vue Rapide

🎯 Objectif : Une équipe fournit services à l’autre - asymétrique

💼 Type de relation : Hiérarchie implicite (qui dépend de qui?)

🔗 Nature : Dépendance unilatérale

Concept

Une équipe upstream fournit services à une ou plusieurs équipes downstream.

Upstream Team
    ↓ (provides services)
    ↓
Downstream Team(s)

Les caractéristiques:

  • ✓ Upstream ne dépend PAS du downstream
  • ✓ Downstream dépend d’Upstream
  • ✓ Asymétrique et clair

Différentes Configurations

1. One Upstream, One Downstream

Payment Service (Upstream)
    ↓
Order Service (Downstream)

Payment peut évoluer indépendamment.
Order attend Payment.

2. One Upstream, Many Downstream

Product Catalog (Upstream)
    ↓ ↓ ↓ ↓ ↓
Pricing | Inventory | Search | Recommendation | Analytics
(Downstream services)

Catalog ne connaît pas ses utilisateurs.
Tous dépendent de Catalog.

3. Tiered Upstream/Downstream

Infrastructure (Upstream 1)
    ↓
Core Platform (Upstream 2)
    ↓
Business Services (Downstream)

Patterns Possibles dans Upstream/Downstream

Selon la relation, différents patterns:

Conformist:
  Downstream adopte le modèle upstream
  
Anticorruption Layer:
  Downstream crée une couche de traduction
  
Published Language:
  Upstream publie un langage public
  
Customer/Supplier Development:
  Upstream et Downstream co-designer

Implications pour Upstream

Responsabilités

  • ✓ Stable interface
  • ✓ Support downstream
  • ✓ Communiquer les changements
  • ✓ Backward compatibility

Avantages

  • ✓ Influence : tu es un goulot!
  • ✓ Control : tu décides de l’interface
  • ✓ Scale : peux servir beaucoup de downstream

Risques

  • ⚠️ Responsabilité : tu bloques downstream
  • ⚠️ Evolution lente : devoir négocier avec downstream
  • ⚠️ Blame : si ça casse, c’est ta responsabilité

Implications pour Downstream

Responsabilités

  • ✓ S’adapter à l’interface upstream
  • ✓ Tester l’intégration
  • ✓ Planifier autour des dépendances

Avantages

  • ✓ Quelqu’un d’autre maintient la plateforme
  • ✓ Peut focuser sur ton domaine
  • ✓ Partage de responsabilité

Risques

  • ⚠️ Bloqué par upstream
  • ⚠️ Changements upstream = impacte toi
  • ⚠️ Moins de contrôle sur l’interface

Signaux d’Alerte

Upstream Débordée

Too many downstream demanding features
    ↓
Upstream peut pas maintenir
    ↓
Dépendances cassent régulièrement
    ↓
Solution: 
  - Publish à Published Language
  - Ou aider downstream créer ACL

Downstream Frustrée

"Upstream change trop souvent"
"On n'a pas le control"
"On voudrait faire X mais upstream dit non"
    ↓
Solutions:
  - Negocier via Customer/Supplier Development
  - Ou créer Anticorruption Layer
  - Ou Separate Ways (duplication)

Power Imbalance

Upstream abuse de son pouvoir
    ↓
Downstream veut se rebeller
    ↓
Possibilités:
  - Escalation au management
  - Créer alternative (Separate Ways)
  - Formal governance process

Governance Patterns

Democratic

Important changes:
  → Downstream reps consulted
  → Majority vote
  → Implemented by consensus

Dictatorial

Upstream decides
  → Downstream adapts
  → Minimal consultation
  
Risque: Downstream insatisfait

Shared

Upstream: decides architecture
Downstream: decides how to integrate
Both: regular sync

Exemples du Monde Réel

E-commerce: Catalog → Many Services

Catalog Service (Upstream)
├─ Inventory queries
├─ Pricing queries
├─ Search indexing
├─ Recommendation feeds
└─ Analytics queries

Chaque downstream:
  - Respecte l'interface Catalog
  - A sa propre logique
  - Si besoin spécifique: crée ACL

Architecture: Infrastructure → Applications

Infrastructure Team (Upstream)
├─ Database
├─ Networking
├─ Monitoring
└─ Security

Application Teams (Downstream)
├─ Order Service
├─ Payment Service
├─ User Service
└─ chacun dépend de l'infrastructure

Métriques de Santé

Pour Upstream

  • Time to respond to downstream issues
  • Breaking changes frequency
  • Downstream satisfaction (NPS)
  • Time downstream waits on upstream

Pour Downstream

  • Time blocked on upstream
  • Incidents caused by upstream changes
  • Support quality
  • Ability to meet own deadlines

Transition & Evolution

Scaling Pattern

When many downstream appear:
  Upstream/Downstream (simple)
    ↓
  Published Language (many downstream)
    ↓
  Specialized interfaces (some Conformist, some ACL)

Reversal Pattern

If contexts become more equal:
  Upstream/Downstream
    ↓
  Partnership (mutual ownership)
    ↓
  Shared Kernel (code partagé)

Checklist pour Upstream/Downstream ✓

  • Direction claire : qui dépend de qui?
  • Interface bien documentée
  • Support process pour downstream
  • Versioning/Deprecation strategy
  • Communication plan pour changements
  • Monitoring de la dépendance

Ressources