Core Domain Chart - Une pratique socio-technique à découvrir à travers un atelier et une étude de cas

Avez-vous entendu parler des pratiques socio-techniques ?

Il s’agit de l’ensemble des ateliers et outils méthodologiques qui permettent de concevoir simultanément une organisation et une architecture technique répondant aux enjeux d’une entreprise.

Le 29 Mars dernier, la Duck Conf accueillait Romain Vailleux pour un atelier sur le “Core Domain Chart” ; les participants ont pu découvrir cet outil et nous vous racontons la session.

Core Domain Chart, kesako ?

Le Core Domain Chart s’inscrit dans la panoplie d’outils du Domain-Driven Design. Il permet de prioriser les Domains, issus par exemple d’un EventStorming Big Picture. Prioriser, c’est-à-dire comprendre quels sont les Domains sur lesquels l’entreprise va devoir investir pour soutenir ses objectifs stratégiques et se différencier et quels sont les Domains qui devront plutôt faire l’objet d’optimisation de coûts et/ou d’externalisation.

Le Core Domain Chart permet d’afficher sur un même plan :

• Les domaines métier/fonctionnels décrivant la chaîne de valeur de l’organisation
• Les assets techniques qui réalisent cette chaîne de valeur
• Les priorités stratégiques de l’organisation
• Les équipes qui prendront en responsabilité chaque domaine
• Les efforts (en ETP) que l’organisation compte investir sur chaque équipe

Évaluer le ratio complexité vs contribution à la stratégie

Le Core Domain Chart se compose de 2 axes :

• Verticalement, la complexité du modèle : il s’agit de l’évaluation du niveau de complexité que va porter chaque domaine ; cette complexité prend en compte toutes les sources de complexité auxquelles une équipe devra faire face lors de la mise en oeuvre des assets attachés à ce domaine : métier, technologique, processus de release, gestion des dépendances avec d’autres équipes ... Plus un domaine est vaste et hétérogène, plus il sera complexe.
• Horizontalement, la différenciation business ou contribution à la stratégie : il s’agit de l’évaluation de la participation d’un domaine à la réussite des objectifs stratégiques de l’organisation.

Une aide à la prise de décision stratégique

Le Core Domain Chart se divise en 3 zones qui aident à la prise de décision sur l’investissement à réaliser pour chaque domaine :

• Core : il s’agit des domaines sur lesquels l’organisation devra investir davantage de ressources internes de façon à gagner en réactivité ou en capacité d’innovation. Ce sont les domaines qui permettent à l’organisation de se positionner sur son marché.
• Supporting : il s’agit des domaines qui mettent en œuvre des solutions spécifiques au marché de l’organisation, ou des solutions génériques qui nécessitent une configuration particulière pour répondre aux besoins de l’organisation. Par exemple, un ERP que l’on devra profondément adapter aux cas de gestion de l’entreprise, ou une solution métier auto-hébergée et opérée en interne. Ce sont des domaines pour lesquels il est important de conserver une bonne maîtrise technique des assets.
• Generic : il s’agit d’une zone où l’organisation va chercher à optimiser ses coûts au prix d’une perte de maîtrise et de réactivité. Ce sont des domaines pour lesquels les solutions techniques sont disponibles sur le marché, et pour lesquels la conservation des compétences n’est pas une priorité.

Le Core Domain Chart amène les organisations à mobiliser leurs capacités sur les domaines qui les propulsent le plus efficacement vers leurs objectifs stratégiques et à optimiser les autres. Au fur et à mesure des évolutions stratégiques, le Core Domain Chart sera revu et adapté.

Délimiter le périmètre d’équipes

Détourer les limites des équipes à partir du Core Domain Chart, c’est résoudre un champ de contraintes qui tiennent en plusieurs axes :

• La loi de Conway : détourer des structures d’équipes qui se calquent sur l’architecture cible du système d’information.

• Les nombres de Dunbar : au-delà d’un certain nombre de personnes (5), l’efficacité d’une équipe décroît rapidement.

• L’équilibre entre efficacité locale (au sein de chaque équipe) et globale (entre plusieurs équipes) : en fonction du type de domaine, choisir où doit être porté l’efficacité locale (petites équipes réactives et véloces) et où l’efficacité globale doit primer (plus larges équipes mutualisant des ressources).

Pour résoudre ce champ de contraintes, nous devrons utiliser une heuristique ; c’est-à-dire une suite d’étapes qui permettent progressivement de tendre vers un optimal.

Heuristique pour tendre vers une organisation optimale

Start :

• 1 domaine = 1 équipe
• Répartir les ETPs disponibles en fonction du ratio complexité / niveau stratégique

Loop :

• Si une équipe < 3 ETPs ⇒ fusionner avec une autre équipe en minimisant la complexité résultante (c’est-à-dire une équipe qui partage des dimensions technique, technologique, méthodologique, métier,...)
• Si une équipe > 7 ETPs ⇒ diviser l’équipe en lui attribuant des sous-domaines cohérents (attention : certaines fois les assets ne peuvent pas être divisés ; les équipes devront collaborer étroitement ensemble)

Le résultat de l’atelier pourrait ressembler à :

L’atelier de découverte du Core Domain Chart

Equipes & participants

Chaque équipe de 5 à 6 participants se retrouve autour d’une table pour dérouler une étude de cas.

Le but de l’atelier

Le but de l’atelier est de découvrir un usage du Core Domain Chart, les conversations qu’il génère, les ambiguïtés soulevées, les tensions à résoudre et les choix à réaliser, en s'appuyant sur les principes socio-techniques.

Le but de la simulation est de concevoir une structure d’organisation ; c’est-à-dire de faire en sorte que les équipes, leur effectif et leur périmètre de responsabilité soient cohérent avec le système technique cible à réaliser et les ambitions stratégiques de l’entreprise.

Matériel requis par table

• 1 description du cas (à imprimer en A2, téléchargeable ici )
• 2 couleurs de post it qui représenteront les domains et les assets
• 1 ou 2 feutres
• 15 jetons (type jeton de poker) dont 10 d’une couleur, et 5 d’une autre
• 1 schéma Core Domain Chart + étapes de l’atelier (à imprimer en format A1**,** téléchargeable ici )
• Mur des débriefings (paperboard)

Déroulé de l’atelier, pas à pas

Durée totale : 1h

• Introduction en quelques mots (15 min)
  • (si besoin) introduction aux concepts/pratiques socio-techniques
  • présentation du cas
  • l’objectif de chaque équipe : concevoir l’organisation permettant de mettre en œuvre l’évolution du système d’information
  • les phases de l’atelier et le timing associé
• Travaux (30 min)
  • Phase 1 : Positionnez les Domains par niveau de complexité (axe vertical du Core Domain Chart)
  • Phase 2 : Positionnez les Domains par niveau stratégique (axe horizontal du Core Domain Chart)
  • Phase 3 : Déterminez le Domain “propriétaire” de chaque asset. Identifiez-vous des “tensions” ?
• Débriefing à mi-parcours : questionnez sur les difficultés rencontrées, répondez aux questionnements
  • Phase 4 : Révélez le layout Core/Supporting/Generic - qu’en déduisez vous ?
  • Phase 5 : Chaque jeton représente 1 Équivalent Temps Plein (ETP), 10 ETP sont internes (couleur 1) et 5 ETP sont externes (couleur 2). Répartir les ETPs et créer des équipes en utilisant l’heuristique pour la création d’équipe
• Débriefing (15 min)
  • sur le Mur des Débriefs, amenez les participants à partager leurs apprentissages et leurs étonnements

Take Aways & prises de conscience des participants

Tout au long de cet atelier, les participants seront mis en situation afin de se poser des questions stratégiques :

• Que faire des assets qui sont détenus par plusieurs Domains ? Quelles sont les conséquences si l’on impacte de conserver une propriété partagée de cet asset ? Faut-il confier la responsabilité de l’asset à un domaine plutôt qu’un autre ? A quelle condition est-ce possible de diviser l’asset en 2 ? Comment cela impacte le choix du contour des équipes ?
• Que signifie le fait qu’une équipe ait en responsabilité des domaines “éloignés” sur le Core Domain Chart ? Quels sont les impacts ? Est-ce souhaitable ?
• Que faire s’il n’y a pas assez de personnes pour appliquer un design d’équipe répondant à l’ambition stratégique ? et s’il y a des ETP en trop ?