Voir la source de Patterns de Core Domain

[[Category: Portail Product Owner]]
[[Category: Rôle du Product Manager]]
Auteur : Nick Tune<br/>
Source : [https://medium.com/nick-tune-tech-strategy-blog/core-domain-patterns-941f89446af5 Core Domain Patterns]<br/>
Date : 19/01/2020<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 12/05/2023<br/>
----
Traduction :<br/>
<br/>
Le temps et les ressources sont limités. La manière dont nous passons notre temps et utilisons nos ressources lorsque nous développons des systèmes logiciels est probablement le défi le plus important et le plus difficile à relever. Parmi toutes les choses que nous pourrions faire, que devrions-nous faire et quel degré de qualité et de rigueur devrions-nous consacrer ?<br/>
<br/>
La tendance naturelle des développeurs logiciels est de se tourner vers les défis les plus intéressants d'un point de vue technique. Je peux le confirmer à partir de mon expérience personnelle, même si ce n'est pas toujours le cas.<br/>
<br/>
Les développeurs qui suivent une approche de conception pilotée par les domaines disposent toutefois de moyens de contrebalancer cette tendance. Un concept connu sous le nom de "Core Domain" (domaine central). Le(s) domaine(s) central(aux) sont les parties du système dont le retour sur investissement est le plus élevé pour l'entreprise.<br/>
<br/>
En tant que développeurs, nous devrions rechercher les "Core Domains" pour nous aider à nous concentrer sur l'impact le plus important et ne pas être attirés par des fonctionnalités techniquement intéressantes mais à faible ROI.<br/>
<br/>
Les "Core Domains" sont accompagnés de "Supporting Domains" (domaines de soutien) et de "Generic Domains" (domaines génériques). Les "Supporting Domains" sont des éléments nécessaires à l'activité de l'entreprise, ils contiennent des concepts liés au domaine, mais leur retour sur investissement est limité. Les "Generic Domains" représentent des concepts qui ne sont pas propres à notre domaine, tels que l'identité de l'utilisateur, l'envoi de courriels, le règlement des factures - nous devrions envisager d'acheter des logiciels SaaS ou d'utiliser des logiciels libres plutôt que de créer des "Generic Domains".<br/>
<br/>
Pour tenter de clarifier, de structurer et de quantifier ces concepts afin qu'ils soient plus faciles à comprendre et à appliquer, j'ai utilisé la représentation de base suivante.<br/>
<br/>
[[Fichier:Core Domain Patterns 01.jpg|border|link=]]
Légende : Distinguer les "core domains" en identifiant la grande complexité et la différenciation des activités de l'entreprise.<br/>
<br/>
Selon cette définition, un "Core Domain" est un domaine qui offre la possibilité d'une forte différenciation commerciale. Cela représente un retour sur investissement incontournable. En outre, la mise en œuvre doit avoir un degré de complexité qui soit raisonnable (complexité du modèle). Si une simple solution de formulaires sur les données ( c'est-à-dire CRUD) suffit, nous ne devrions pas perdre de temps à faire de trop gros efforts de conception et de développement.<br/>
<br/>
Grâce à cette représentation, nous pouvons aller plus loin et identifier des ‘’patterns’’ qui guideront notre stratégie technologique et nos investissements en matière de développement de logiciels aujourd'hui et demain.<br/>
<br/>
== Core décisif==
Légende : Core Domains décisifs<br/>
<br/>
Lorsqu'un "core domain" est extrêmement complexe et qu'il offre un potentiel de différenciation commerciale très élevé, il s'agit d'une capacité (''capability'') décisive. Décisive parce que l'organisation qui y parvient est susceptible de devenir le leader du marché. Les niveaux élevés de complexité nécessitent un investissement important pour réussir.<br/>
==Core à court-terme==
Légende : Core Domains à court-terme<br/>
<br/>
Lorsqu'un "core domain" a un fort potentiel de différenciation mais que sa complexité est relativement faible, il peut s'agir d'un "core" à court terme. En raison de sa faible complexité, il ne constitue pas un atout digne d'être défendu et la concurrence le rattrapera dans un laps de temps relativement court.<br/>
<br/>
==Core caché==
Légende : Core Domains cachés<br/>
<br/>
Un antipattern potentiel dont il faut se méfier est le core caché. Si un contexte est peu complexe, par exemple un simple système CRUD de formulaires sur des données, il ne s'agit pas d'un core domain qui nous impose d'innover.<br/>
<br/>
Toutefois, si cette capacité représente un élément de différenciation pour l'entreprise, il convient de se méfier : soit la concurrence sera facilement en mesure d'atteindre un niveau équivalent, soit l'entreprise passe à côté d'une opportunité majeure - par exemple, la complexité est toujours gérée manuellement par les employés et le système logiciel ne fait que remplacer le papier.<br/>
<br/>
Dans cette situation, l'entreprise doit se poser la question suivante : "Pouvons-nous exploiter le potentiel de la technologie dans ce cas ? Pouvons-nous reprendre les processus manuels et laisser les machines faire tout le travail de fond que les gens accomplissent aujourd'hui ?<br/>
==Ancien Core qui est devenu un sujet à la portée de tous==
Légende : Ancien Core qui est devenu un sujet à la portée de tous<br/>
<br/>
Le cycle de vie naturel de toute innovation est qu'avec le temps, elle devient un sujet incontournable - elle n'est plus une innovation qui fait la différence, mais elle est toujours nécessaire.<br/>
<br/>
Vous souvenez-vous de la première vague de magasins et de restaurants qui ont commencé à accepter les paiements sans contact ? Merveilleux, pratique, une raison qui a influencé votre choix de magasin ou de restaurant. Aujourd'hui, nous exigeons le paiement sans contact partout.<br/>
==Core banalisé==
A l'image de ‘’l'ancien Core qui devient un sujet à la portée de tous’’, ce qui était autrefois un core domain peut devenir une capacité générique que n'importe quelle entreprise peut facilement utiliser comme un produit SaaS ou un outil open source.<br/>
<br/>
Un moteur de recherche est un exemple de core banalisé. Si votre produit reposait sur des capacités de recherche avancées pour se différencier de la concurrence, l'arrivée de moteurs de recherche open source et SaaS de pointe tels qu'Elasticsearch aura détruit votre avantage, donnant à tout concurrent potentiel les moyens de vous concurrencer.<br/>
==Core cygne noir==
Il arrive parfois que l'on ne s'y attende pas du tout et qu'un produit apparemment banalisé devienne un "core domain". L'histoire de Slack me revient en mémoire.<br/>
<br/>
Slack a d'abord été un système de chat interne pour une entreprise du marché des jeux vidéo. Lorsque les jeux vidéo ont cessé de générer des revenus, l'entreprise a décidé de transformer son système de chat en produit. Slack vaut aujourd'hui 13 milliards de dollars.<br/>
<br/>
L'IRC (‘’ discussion relayée par Internet’’) était déjà une norme de discussion bien établie qui remplissait une fonction. Le potentiel de différenciation semblait faible. Personne n'y a vu d'opportunité, pas même Slack, qui utilisait pourtant le produit.<br/>
== Core sur lequel on parie beaucoup / Core disruptif==
Légende : Core sur lequel on parie<br/>
<br/>
Pour de nombreuses initiatives, le niveau potentiel de différenciation commerciale est inconnu. Tant que le produit n'est pas livré et que les retours du marché n'ont pas été recueillis, personne n'est sûr de rien.<br/>
<br/>
En raison du potentiel élevé de cette capacité, qui pourrait révolutionner un marché, il peut s'agir d'un pari ambitieux, car l'organisation doit y injecter des ressources importantes et en faire un objectif prioritaire, convaincue que le retour sur investissement peut être énorme.<br/>
==Core suspecté de support==
Légende : Core suspecté de support<br/>
Si un contexte délimité est super complexe alors qu'il ne fait que du support, il convient de se poser de sérieuses questions. Comment quelque chose de relativement peu différencié sur le plan commercial peut-il nécessiter des niveaux d'investissement aussi élevés pour gérer la complexité ?<br/>
<br/>
Une raison tout à fait valable est que cette complexité accidentelle est trop élevée - peut-être qu'une migration est en cours d'un ancien système vers un nouveau. Un plan clair et un calendrier de réduction de la complexité doivent être mis en place afin de garantir que les efforts gaspillés puissent être réaffectés à des capacités ayant un potentiel de différenciation plus élevé.<br/>
== Passer au niveau supérieur==
Je trouve que l'évaluation des contextes délimités pour la différenciation et la complexité de l'entreprise est un point de départ très pratique et accessible. Pour les équipes qui comprennent mal comment leur architecture est liée au modèle d'entreprise, j'ai trouvé cette technique incroyablement utile pour permettre aux développeurs de raisonner davantage en fonction de la perspective de l'entreprise, et en particulier de son évolution dans le temps.<br/>
<br/>
Essayez-le. Faites-moi part de vos réactions et indiquez-moi tout autre pattern de core domain que vous découvririez. Mais surtout, ne vous arrêtez pas là...<br/>
<br/>
Pour comprendre pourquoi les capacités évoluent en différenciation et en complexité au fil du temps, je vous recommande vivement d'étudier la cartographie de Wardley et le cadre Cynefin.<br/>
<br/>
Il est également essentiel de comprendre les différents types de complexité - fondamentale ou accidentelle - et les diverses sous-catégories de la complexité accidentelle.