Heuristique pour des services indépendants - Historique des versions

Fabrice Aimetti : /* Ressources */

Fabrice Aimetti — Wed, 17 May 2023 06:22:23 GMT

Ressources

← Version précédente		Version du 17 mai 2023 à 06:22
Ligne 77 :		Ligne 77 :
	* '''Anti-modèle - coordination des versions''' : Les producteurs et les consommateurs en amont et en aval ont-ils besoin que votre "chose" coordonne des versions (par exemple, un train de versions) ou peuvent-ils publier des versions indépendamment aussi souvent qu'ils le souhaitent ?		* '''Anti-modèle - coordination des versions''' : Les producteurs et les consommateurs en amont et en aval ont-ils besoin que votre "chose" coordonne des versions (par exemple, un train de versions) ou peuvent-ils publier des versions indépendamment aussi souvent qu'ils le souhaitent ?
	==Ressources==		==Ressources==
	* ~~Regarder~~ la présentation de [https://github.com/matthewskelton Matthew Skelton] et [https://github.com/ntcoding Nick Tune] concernant [https://www.youtube.com/watch?v=q8hwkDyL6Zs ISH lors de DDD Europe 2022]		* Regardez la présentation de [https://github.com/matthewskelton Matthew Skelton] et [https://github.com/ntcoding Nick Tune] concernant [https://www.youtube.com/watch?v=q8hwkDyL6Zs ISH lors de DDD Europe 2022]
	* ~~En savoir plus~~ sur les [https://teamtopologies.com/key-concepts Topologies d'équipe]		* Apprenez-en davantage sur les [https://teamtopologies.com/key-concepts Topologies d'équipe]
	* ~~Explorer~~ les [https://www.dddheuristics.com/ Heuristiques de Domain-Driven Design] - une partie de l'excellente communauté [https://virtualddd.com/ virtualDDD.com]		* Explorez les [https://www.dddheuristics.com/ Heuristiques de Domain-Driven Design] - une partie de l'excellente communauté [https://virtualddd.com/ virtualDDD.com]
	* Apprenez à utiliser l'[https://techbeacon.com/devops/introduction-event-storming-easy-way-achieve-domain-driven-design Event Storming] pour découvrir différents domaines métiers - cela peut être une bonne "passerelle" vers le Domain-driven Design (DDD) - ''merci à [https://twitter.com/rebeccawb Rebecca Wirfs-Brock] pour cette idée''.		* Apprenez à utiliser l'[https://techbeacon.com/devops/introduction-event-storming-easy-way-achieve-domain-driven-design Event Storming] pour découvrir différents domaines métiers - cela peut être une bonne "passerelle" vers le Domain-driven Design (DDD) - ''merci à [https://twitter.com/rebeccawb Rebecca Wirfs-Brock] pour cette idée''.
	* ~~Découvrir~~ les [https://hiredthought.com/2018/09/01/intro-to-wardley-mapping/ Cartes de Wardley]		* Découvrez les [https://hiredthought.com/2018/09/01/intro-to-wardley-mapping/ Cartes de Wardley]
	* ~~Lire~~ des articles sur la [https://theitriskmanager.com/2013/11/24/introducing-staff-liquidity-1-of-n/ Liquidité des Compétences par Chris Matts]		* Lisez des articles sur la [https://theitriskmanager.com/2013/11/24/introducing-staff-liquidity-1-of-n/ Liquidité des Compétences par Chris Matts]

	==Remerciements==		==Remerciements==
	Merci aux personnes du [https://www.meetup.com/dddlondon/events/265895638 groupe de rencontre DDD Londres] pour leurs commentaires sur une première version de l'heuristique des services indépendants. 😻<br/>		Merci aux personnes du [https://www.meetup.com/dddlondon/events/265895638 groupe de rencontre DDD Londres] pour leurs commentaires sur une première version de l'heuristique des services indépendants. 😻<br/>

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti — Wed, 17 May 2023 06:18:50 GMT

Mode d'emploi

← Version précédente		Version du 17 mai 2023 à 06:18
Ligne 41 :		Ligne 41 :
	#* L'organisation assure-t-elle un suivi séparé pour cette chose ?		#* L'organisation assure-t-elle un suivi séparé pour cette chose ?
	# '''Données''' : Est-il possible de définir clairement les données d'entrée (provenant d'autres sources) dont cette chose a besoin ?		# '''Données''' : Est-il possible de définir clairement les données d'entrée (provenant d'autres sources) dont cette chose a besoin ?
	#* La chose est-elle relativement indépendante de toute source de données ?		#* Cette chose est-elle relativement indépendante de toute source de données ?
	#* Les sources sont-elles internes (sous notre contrôle, pas externes) ?		#* Les sources sont-elles internes (sous notre contrôle, pas externes) ?
	#* Les données d'entrée sont-elles propres (pas fouillis) ?		#* Les données d'entrée sont-elles propres (pas fouillis) ?

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti — Wed, 17 May 2023 06:17:57 GMT

Mode d'emploi

← Version précédente		Version du 17 mai 2023 à 06:17
Ligne 37 :		Ligne 37 :
	#* Existe-t-il une base ou un segment de clientèle clairement défini ?		#* Existe-t-il une base ou un segment de clientèle clairement défini ?
	# '''Suivi des coûts''' : L'organisation peut-elle actuellement suivre les coûts et les investissements de cette chose, séparément d'autres choses similaires ?		# '''Suivi des coûts''' : L'organisation peut-elle actuellement suivre les coûts et les investissements de cette chose, séparément d'autres choses similaires ?
	#* Les coûts totaux de fonctionnement sont-ils transparents ou peuvent-ils être identifiés en tenant compte des coûts d'infrastructure, des coûts de stockage des données, des coûts de transfert des données, des coûts de licence, etc.		#* Les coûts totaux de fonctionnement sont-ils transparents ou peuvent-ils être identifiés en tenant compte des coûts d'infrastructure, des coûts de stockage des données, des coûts de transfert des données, des coûts de licence, etc. ?
	#* Cette chose est-elle relativement séparée, déconnectée d'autres choses dans l'organisation ?		#* Cette chose est-elle relativement séparée, déconnectée d'autres choses dans l'organisation ?
	#* L'organisation assure-t-elle un suivi séparé pour cette chose ?		#* L'organisation assure-t-elle un suivi séparé pour cette chose ?

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti — Wed, 17 May 2023 06:17:22 GMT

Mode d'emploi

← Version précédente		Version du 17 mai 2023 à 06:17
Ligne 34 :		Ligne 34 :
	# '''Revenus/Clients''' : Cette chose pourra-t-elle être gérée comme un service cloud viable en termes de revenus et de clients ?		# '''Revenus/Clients''' : Cette chose pourra-t-elle être gérée comme un service cloud viable en termes de revenus et de clients ?
	#* Est-ce que ce sera un service viable avec une offre payante ?		#* Est-ce que ce sera un service viable avec une offre payante ?
	#* Est-ce qu'il pourra générer des revenus récurrents grâce à des formules d'abonnement ?		#* Est-ce qu'elle pourra générer des revenus récurrents grâce à des formules d'abonnement ?
	#* Existe-t-il une base ou un segment de clientèle clairement défini ?		#* Existe-t-il une base ou un segment de clientèle clairement défini ?
	# '''Suivi des coûts''' : L'organisation peut-elle actuellement suivre les coûts et les investissements de cette chose, séparément d'autres choses similaires ?		# '''Suivi des coûts''' : L'organisation peut-elle actuellement suivre les coûts et les investissements de cette chose, séparément d'autres choses similaires ?

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti — Wed, 17 May 2023 06:16:43 GMT

Mode d'emploi

← Version précédente		Version du 17 mai 2023 à 06:16
Ligne 26 :		Ligne 26 :
	# '''Vérification du sens''' : Est-il logique d'offrir cette chose "en tant que service" ?		# '''Vérification du sens''' : Est-il logique d'offrir cette chose "en tant que service" ?
	#* Cette chose est-elle suffisamment indépendante ?		#* Cette chose est-elle suffisamment indépendante ?
	#* Les consommateurs la ~~comprendraient~~-ils ou lui ~~accorderaient~~-ils de la valeur ?		#* Les consommateurs la comprendront-ils ou lui accorderont-ils de la valeur ?
	#* Est-ce que cela simplifiera le travail ?		#* Est-ce que cela simplifiera le travail ?
	# '''Marque''' : Pourriez-vous imaginer cette chose sous la forme d'un service accessible sur le cloud public (comme ''AvocadoOnline.com'' 🥑) ?		# '''Marque''' : Pourriez-vous imaginer cette chose sous la forme d'un service accessible sur le cloud public (comme ''AvocadoOnline.com'' 🥑) ?
Ligne 60 :		Ligne 60 :
	#* Cette chose fournit-elle une valeur ajoutée concrète au sein d'une période d'exécution bien définie ?		#* Cette chose fournit-elle une valeur ajoutée concrète au sein d'une période d'exécution bien définie ?
	#* L'équipe peut-elle définir sa propre feuille de route en fonction de ce qu'elle estime être le mieux pour le produit et ses utilisateurs (de sorte que l'équipe ne soit pas guidée par les exigences et les priorités d'autres équipes) ?		#* L'équipe peut-elle définir sa propre feuille de route en fonction de ce qu'elle estime être le mieux pour le produit et ses utilisateurs (de sorte que l'équipe ne soit pas guidée par les exigences et les priorités d'autres équipes) ?

	== Autres considérations==		== Autres considérations==
	* '''Vocabulaire''' : le vocabulaire est-il cohérent entre les différentes parties du système ou les différents domaines métiers ? Si ce n'est pas le cas (si le même mot a une signification différente dans des domaines différents), il peut être nécessaire d'avoir deux services ou systèmes différents.		* '''Vocabulaire''' : le vocabulaire est-il cohérent entre les différentes parties du système ou les différents domaines métiers ? Si ce n'est pas le cas (si le même mot a une signification différente dans des domaines différents), il peut être nécessaire d'avoir deux services ou systèmes différents.

Fabrice Aimetti le 17 mai 2023 à 06:15

Fabrice Aimetti — Wed, 17 May 2023 06:15:34 GMT

← Version précédente		Version du 17 mai 2023 à 06:15
Ligne 9 :		Ligne 9 :
	Traduction :<br/>		Traduction :<br/>
	<br/>		<br/>
	L'heuristique pour des services indépendants (ISH - Independent Service Heuristics) est une règle empirique qui permet d'identifier les flux de valeur candidats et les frontières des domaines en déterminant s'ils peuvent être gérés comme un produit SaaS/cloud distinct.<br/>		L'heuristique pour des services indépendants ('''ISH''' - Independent Service Heuristics) est une règle empirique qui permet d'identifier les flux de valeur candidats et les frontières des domaines en déterminant s'ils peuvent être gérés comme un produit SaaS/cloud distinct.<br/>
	<br/>		<br/>
	Basé sur certaines idées du livre ''Team Topologies'' de Matthew Skelton [https://github.com/matthewskelton @matthewskelton] et Manuel Pais [https://github.com/manupaisable @manupaisable].<br/>		Basé sur certaines idées du livre ''Team Topologies'' de Matthew Skelton [https://github.com/matthewskelton @matthewskelton] et Manuel Pais [https://github.com/manupaisable @manupaisable].<br/>

Fabrice Aimetti le 17 mai 2023 à 06:14

Fabrice Aimetti — Wed, 17 May 2023 06:14:32 GMT

← Version précédente		Version du 17 mai 2023 à 06:14
Ligne 11 :		Ligne 11 :
	L'heuristique pour des services indépendants (ISH - Independent Service Heuristics) est une règle empirique qui permet d'identifier les flux de valeur candidats et les frontières des domaines en déterminant s'ils peuvent être gérés comme un produit SaaS/cloud distinct.<br/>		L'heuristique pour des services indépendants (ISH - Independent Service Heuristics) est une règle empirique qui permet d'identifier les flux de valeur candidats et les frontières des domaines en déterminant s'ils peuvent être gérés comme un produit SaaS/cloud distinct.<br/>
	<br/>		<br/>
	Basé sur certaines idées du livre Team Topologies de Matthew Skelton [https://github.com/matthewskelton @matthewskelton] et Manuel Pais [https://github.com/manupaisable @manupaisable].<br/>		Basé sur certaines idées du livre ''Team Topologies'' de Matthew Skelton [https://github.com/matthewskelton @matthewskelton] et Manuel Pais [https://github.com/manupaisable @manupaisable].<br/>
	<br/>		<br/>
	Voir [https://teamtopologies.com/ teamtopologies.com] pour plus de détails sur Team Topolologies.<br/>		Voir [https://teamtopologies.com/ teamtopologies.com] pour plus de détails sur Team Topolologies.<br/>

Fabrice Aimetti le 17 mai 2023 à 06:11

Fabrice Aimetti — Wed, 17 May 2023 06:11:50 GMT

Fabrice Aimetti : Page créée avec « Category:DDD Auteurs : Matthew Skelton, Manuel Pais, Chris Combe, George-Leonard Chetreanu, Matt Wynne, Ersin Er, Eduardo da Silva, "penmanglewood", Phil Broering
... »

Fabrice Aimetti — Tue, 16 May 2023 16:36:53 GMT

Page créée avec « Category:DDD Auteurs : Matthew Skelton, Manuel Pais, Chris Combe, George-Leonard Chetreanu, Matt Wynne, Ersin Er, Eduardo da Silva, "penmanglewood", Phil Broering ... »

Nouvelle page

[[Category:DDD]]
Auteurs : Matthew Skelton, Manuel Pais, Chris Combe, George-Leonard Chetreanu, Matt Wynne, Ersin Er, Eduardo da Silva, "penmanglewood", Phil Broering 
Source : [https://github.com/TeamTopologies/Independent-Service-Heuristics Independent Service Heuristics] 
Date : 18/04/2023 
----
Traducteur : Fabrice Aimetti 
Date : 17/05/2023 
----
Traduction : 
 
L'heuristique pour des services indépendants (ISH - Independent Service Heuristics) est une règle empirique qui permet d'identifier les flux de valeur candidats et les frontières des domaines en déterminant s'ils peuvent être gérés comme un produit SaaS/cloud distinct. 
 
Basé sur certaines idées du livre Team Topologies de Matthew Skelton @matthewskelton et Manuel Pais @manupaisable. 
 
Voir teamtopologies.com pour plus de détails sur Team Topolologies. 
 
Copyright © 2018-2021 Team Topologies - Licence CC BY-SA 4.0 
== Présentation générale==
Lorsque l'on conçoit des organisations pour un flux de changement rapide, il faut trouver des frontières efficaces entre les différents flux de changement. Les techniques telles que le Domain Driven Design (DDD) sont très puissantes à cet égard, mais elles peuvent s'avérer assez complexes et difficiles à apprendre. Une approche intermédiaire plus simple consiste à se demander s'il est possible de faire fonctionner cette chose comme un service ou un produit hébergé dans les nuages (SaaS). 
 
L'approche ISH concerne de nombreuses situations typiques rencontrées dans le secteur des logiciels modernes, mais pas toutes. Elle est conçue pour stimuler les conversations et fournir un cadre de réflexion, et non comme un outil "fourre-tout" idéal. 
== Mode d'emploi==
Choisissez un sujet d'intérêt pour l'organisation à représenter dans un logiciel : un parcours utilisateur, un "produit", un domaine métier potentiel, un service logiciel, une application logicielle entière, un ensemble de tâches pour une persona d'utilisateur unique, un flux de valeur potentiel, etc.
Utilisez la check-list ci-dessous pour poser des questions sur le domaine / le service / l'application / la chaîne de valeur candidat(e). Plus il y a de réponses "oui" ou "probablement", plus il y a de chances que vous ayez trouvé un bon candidat pour constituer un flux de changement distinct. Cela signifie que nous pourrions mettre en place une ou plusieurs équipes "Stream-aligned" sur ce sujet.
Check-list
# ‘’’Vérification du sens‘’’ : Est-il logique d'offrir cette chose "en tant que service" ?
#* Cette chose est-elle suffisamment indépendante ?
#* Les consommateurs la comprendraient-ils ou lui accorderaient-ils de la valeur ?
#* Est-ce que cela simplifiera le travail ?
# ‘’’Marque ‘’’ : Pourriez-vous imaginer cette chose sous la forme d'un service accessible sur le cloud public (comme AvocadoOnline.com 🥑) ?
#* Est-ce que ce sera une activité (ou une "micro-activité") ou un service viable ?
#* S'agira-il d'une offre convaincante ?
#* La campagne marketing sera-t-elle convaincante ?
# ‘’’Revenus/Clients‘’’ : Cette chose pourra-t-elle être gérée comme un service cloud viable en termes de revenus et de clients ?
#* Est-ce que ce sera un service viable avec une offre payante ?
#* Est-ce qu'il pourra générer des revenus récurrents grâce à des formules d'abonnement ?
#* Existe-t-il une base ou un segment de clientèle clairement défini ?
# ‘’’Suivi des coûts‘’’ : L'organisation peut-elle actuellement suivre les coûts et les investissements de cette chose, séparément d'autres choses similaires ?
#* Les coûts totaux de fonctionnement sont-ils transparents ou peuvent-ils être identifiés en tenant compte des coûts d'infrastructure, des coûts de stockage des données, des coûts de transfert des données, des coûts de licence, etc.
#* Cette chose est-elle relativement séparée, déconnectée d'autres choses dans l'organisation ?
#* L'organisation assure-t-elle un suivi séparé pour cette chose ?
# '''Données''' : Est-il possible de définir clairement les données d'entrée (provenant d'autres sources) dont cette chose a besoin ?
#* La chose est-elle relativement indépendante de toute source de données ?
#* Les sources sont-elles internes (sous notre contrôle, pas externes) ?
#* Les données d'entrée sont-elles propres (pas fouillis) ?
#* Les données d'entrée sont-elles fournies en libre-service ? L'équipe peut-elle consommer les données d'entrée "en tant que service" ?
# ‘’’Personas Utilisateur’’’ : Cette chose pourra-t-elle avoir un ensemble restreint/bien défini de types d'utilisateurs ou de clients (personas utilisateur) ?
#* Cette chose répond-elle à des besoins d'utilisateurs spécifiques ?
#* Connaissons-nous (ou pouvons-nous facilement formuler) ces types d'utilisateurs et leurs besoins ?
# '''Équipes''' : Une équipe ou un ensemble d'équipes pourra-t-elle/il construire et exploiter efficacement un service basé sur cette chose ?
#* La charge cognitive (étendue des sujets/changement de contexte) pourra-t-elle être limitée afin d'aider l'équipe à se concentrer et à réussir ?
#* Une infrastructure de taille importante ou d'autres abstractions de plate-forme seraient-elles superflues ?
# '''Dépendances''' : Cette équipe sera-t-elle capable de travailler indépendamment des autres équipes la plupart du temps pour atteindre ses objectifs ?
#* Cette chose est-elle logiquement indépendante d'autres choses ?
#* L'équipe pourra-t-elle " auto-administrer " les dépendances d'une manière non bloquante à partir d'une plateforme ?
# '''Impact/Valeur''' : La portée de cette chose permettra-t-elle à une équipe de relever un défi significatif et motivant ?
#* La portée est-elle suffisamment large pour avoir un impact ? La portée sera-t-elle suffisamment motivante pour les personnes talentueuses ?
#* La valeur pour les clients et l'organisation est-elle suffisante pour être clairement perçue ?
# '''Décisions relatives au produit''' : L'équipe travaillant sur cette chose sera-t-elle en mesure de "s'approprier" sa propre feuille de route et la stratégie du produit ?
#* Cette chose fournit-elle une valeur ajoutée concrète au sein d'une période d'exécution bien définie ?
#* L'équipe peut-elle définir sa propre feuille de route en fonction de ce qu'elle estime être le mieux pour le produit et ses utilisateurs (de sorte que l'équipe ne soit pas guidée par les exigences et les priorités d'autres équipes) ?
== Autres considérations==
* ‘’’Vocabulaire ‘’’ : le vocabulaire est-il cohérent entre les différentes parties du système ou les différents domaines métiers ? Si ce n'est pas le cas (si le même mot a une signification différente dans des domaines différents), il peut être nécessaire d'avoir deux services ou systèmes différents.
* ‘’’Phases ‘’’ : une partie du système traite-t-elle une phase antérieure ou postérieure du traitement ? Cela peut également représenter une bonne frontière.
* ‘’’Cartes de Wardley‘’’ : la capacité ou le service pourrait-il être externalisé vers un produit SaaS ou un fournisseur de produits de base ? Sera-t-il bientôt externalisable ? Si c'est le cas, c'est un candidat à la séparation en tant que service distinct en vue d'une éventuelle externalisation auprès d'un fournisseur de produits ou de services de base.
* ‘’’Risque‘’’ : quel est le coût du risque lié à la scission de cette capacité ou de ce service ? Un problème pourrait-il survenir ?
==Considérations détaillées==
* '''Couplage lâche''' : Cette ''chose'' a-t-elle un sens pour être migrée / déployée de manière indépendante dans le cloud public, indépendamment des ''choses'' apparentées ?
* '''Couplage fort''' : Avez-vous des dépendances sur des logiciels de fournisseurs ou de tierces parties qui empêchent la mise à l'échelle en cas de hausse de la demande ?
* '''Opportunité commerciale''' : Existe-t-il une demande pour cette "chose" en dehors du contexte de son utilisation actuelle ? Pourrait-elle être utilisée plus largement au sein de votre organisation ou pour différents segments de clientèle ?
* '''Gouvernance des données''' : Cette chose fait-elle office de source principale ou fait-elle autorité pour les données clés statiques / de référence / du client ?
* '''Contrats d'interface''' : Disposez-vous de contrats d'interface versionnés et de la capacité de déployer de nouvelles versions sans impact sur les "clients" (consommateurs) existants ?
* '''Résilience / scalabilité''' : Au fur et à mesure que la demande pour votre "chose" augmente, avez-vous une augmentation linéaire de la demande pour de nouvelles capacités / disponibilités (y compris dans les régions géographiques) ?
* '''Liquidité des compétences''' : Prenez en compte l'éventail des compétences au sein des équipes. Les équipes peuvent-elles chacune posséder leur service/système après la scission ?
* '''Anti-modèle - couplage de données''' : Votre "chose" dépend-elle d'un couplage fort / de pilotes de fournisseurs spécifiques ou utilise-t-elle des choses comme des liens de base de données plutôt que par le biais d'une API gérée et versionnée ?
* '''Anti-modèle - coordination des versions''' : Les producteurs et les consommateurs en amont et en aval ont-ils besoin que votre "chose" maîtrise une version (par exemple, un train de versions) ou peuvent-ils publier des versions indépendamment aussi souvent qu'ils le souhaitent ?
==Ressources==
* Regarder la présentation de Matthew Skelton et Nick Tune concernant ISH lors de DDD Europe 2022
* En savoir plus sur les topologies d'équipe
* Explorer les heuristiques de Domain-Driven Design - une partie de l'excellente communauté virtualDDD.com
* Apprenez à utiliser l'Event Storming pour découvrir différents domaines métiers - cela peut être une bonne "passerelle" vers le Domain-driven Design (DDD) - merci à Rebecca Wirfs-Brock pour cette idée.
* Découvrir les Cartes de Wardley
* Lire des articles sur la Liquidité des Compétences par Chris Matts
==Remerciements==
Merci aux personnes du groupe de rencontre DDD de Londres pour leurs commentaires sur une première version de l'heuristique des services indépendants. 😻 
 
Merci également à :
* Nick Tune et le DDD Crew pour les supers ressources DDD
* Kacper Gunia pour l'invitation à prendre la parole lors de la rencontre DDD de Londres
* tous les contributeurs à ce dépôt.

← Version précédente		Version du 17 mai 2023 à 06:11
Ligne 11 :		Ligne 11 :
	L'heuristique pour des services indépendants (ISH - Independent Service Heuristics) est une règle empirique qui permet d'identifier les flux de valeur candidats et les frontières des domaines en déterminant s'ils peuvent être gérés comme un produit SaaS/cloud distinct.<br/>		L'heuristique pour des services indépendants (ISH - Independent Service Heuristics) est une règle empirique qui permet d'identifier les flux de valeur candidats et les frontières des domaines en déterminant s'ils peuvent être gérés comme un produit SaaS/cloud distinct.<br/>
	<br/>		<br/>
	Basé sur certaines idées du livre Team Topologies de Matthew Skelton @matthewskelton et Manuel Pais @manupaisable.<br/>		Basé sur certaines idées du livre Team Topologies de Matthew Skelton [https://github.com/matthewskelton @matthewskelton] et Manuel Pais [https://github.com/manupaisable @manupaisable].<br/>
	<br/>		<br/>
	Voir teamtopologies.com pour plus de détails sur Team Topolologies.<br/>		Voir [https://teamtopologies.com/ teamtopologies.com] pour plus de détails sur Team Topolologies.<br/>
	<br/>		<br/>
	Copyright © 2018-2021 Team Topologies - Licence CC BY-SA 4.0<br/>		Copyright © 2018-2021 Team Topologies - Licence [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0]<br/>
	== Présentation générale==		== Présentation générale==
	Lorsque l'on conçoit des organisations pour un flux de changement rapide, il faut trouver des frontières efficaces entre les différents flux de changement. Les techniques telles que le Domain Driven Design (DDD) sont très puissantes à cet égard, mais elles peuvent s'avérer assez complexes et difficiles à apprendre. Une approche intermédiaire plus simple consiste à se demander s'il est possible de faire fonctionner cette chose comme un service ou un produit hébergé dans les nuages (SaaS).<br/>		Lorsque l'on conçoit des organisations pour un flux de changement rapide, il faut trouver des frontières efficaces entre les différents flux de changement. Les techniques telles que le Domain Driven Design (DDD) sont très puissantes à cet égard, mais elles peuvent s'avérer assez complexes et difficiles à apprendre. Une approche intermédiaire plus simple consiste à se demander s'il est possible de faire fonctionner cette chose comme un service ou un produit hébergé dans les nuages (SaaS).<br/>
Ligne 24 :		Ligne 24 :
	Utilisez la check-list ci-dessous pour poser des questions sur le domaine / le service / l'application / la chaîne de valeur candidat(e). Plus il y a de réponses "oui" ou "probablement", plus il y a de chances que vous ayez trouvé un bon candidat pour constituer un flux de changement distinct. Cela signifie que nous pourrions mettre en place une ou plusieurs équipes "Stream-aligned" sur ce sujet.		Utilisez la check-list ci-dessous pour poser des questions sur le domaine / le service / l'application / la chaîne de valeur candidat(e). Plus il y a de réponses "oui" ou "probablement", plus il y a de chances que vous ayez trouvé un bon candidat pour constituer un flux de changement distinct. Cela signifie que nous pourrions mettre en place une ou plusieurs équipes "Stream-aligned" sur ce sujet.
	Check-list		Check-list
	# ~~‘’’Vérification~~ du ~~sens‘’’~~ : Est-il logique d'offrir cette chose "en tant que service" ?		# '''Vérification du sens''' : Est-il logique d'offrir cette chose "en tant que service" ?
	#* Cette chose est-elle suffisamment indépendante ?		#* Cette chose est-elle suffisamment indépendante ?
	#* Les consommateurs la comprendraient-ils ou lui accorderaient-ils de la valeur ?		#* Les consommateurs la comprendraient-ils ou lui accorderaient-ils de la valeur ?
	#* Est-ce que cela simplifiera le travail ?		#* Est-ce que cela simplifiera le travail ?
	# ~~‘’’Marque ‘’’~~ : Pourriez-vous imaginer cette chose sous la forme d'un service accessible sur le cloud public (comme AvocadoOnline.com 🥑) ?		# '''Marque''' : Pourriez-vous imaginer cette chose sous la forme d'un service accessible sur le cloud public (comme ''AvocadoOnline.com'' 🥑) ?
	#* Est-ce que ce sera une activité (ou une "micro-activité") ou un service viable ?		#* Est-ce que ce sera une activité (ou une "micro-activité") ou un service viable ?
	#* S'agira-il d'une offre convaincante ?		#* S'agira-il d'une offre convaincante ?
	#* La campagne marketing sera-t-elle convaincante ?		#* La campagne marketing sera-t-elle convaincante ?
	# ~~‘’’Revenus~~/~~Clients‘’’~~ : Cette chose pourra-t-elle être gérée comme un service cloud viable en termes de revenus et de clients ?		# '''Revenus/Clients''' : Cette chose pourra-t-elle être gérée comme un service cloud viable en termes de revenus et de clients ?
	#* Est-ce que ce sera un service viable avec une offre payante ?		#* Est-ce que ce sera un service viable avec une offre payante ?
	#* Est-ce qu'il pourra générer des revenus récurrents grâce à des formules d'abonnement ?		#* Est-ce qu'il pourra générer des revenus récurrents grâce à des formules d'abonnement ?
	#* Existe-t-il une base ou un segment de clientèle clairement défini ?		#* Existe-t-il une base ou un segment de clientèle clairement défini ?
	# ~~‘’’Suivi~~ des ~~coûts‘’’~~ : L'organisation peut-elle actuellement suivre les coûts et les investissements de cette chose, séparément d'autres choses similaires ?		# '''Suivi des coûts''' : L'organisation peut-elle actuellement suivre les coûts et les investissements de cette chose, séparément d'autres choses similaires ?
	#* Les coûts totaux de fonctionnement sont-ils transparents ou peuvent-ils être identifiés en tenant compte des coûts d'infrastructure, des coûts de stockage des données, des coûts de transfert des données, des coûts de licence, etc.		#* Les coûts totaux de fonctionnement sont-ils transparents ou peuvent-ils être identifiés en tenant compte des coûts d'infrastructure, des coûts de stockage des données, des coûts de transfert des données, des coûts de licence, etc.
	#* Cette chose est-elle relativement séparée, déconnectée d'autres choses dans l'organisation ?		#* Cette chose est-elle relativement séparée, déconnectée d'autres choses dans l'organisation ?
Ligne 45 :		Ligne 45 :
	#* Les données d'entrée sont-elles propres (pas fouillis) ?		#* Les données d'entrée sont-elles propres (pas fouillis) ?
	#* Les données d'entrée sont-elles fournies en libre-service ? L'équipe peut-elle consommer les données d'entrée "en tant que service" ?		#* Les données d'entrée sont-elles fournies en libre-service ? L'équipe peut-elle consommer les données d'entrée "en tant que service" ?
	# ~~‘’’Personas Utilisateur’’’~~ : Cette chose pourra-t-elle avoir un ensemble restreint/bien défini de types d'utilisateurs ou de clients (personas utilisateur) ?		# '''Personas Utilisateur''' : Cette chose pourra-t-elle avoir un ensemble restreint/bien défini de types d'utilisateurs ou de clients (personas utilisateur) ?
	#* Cette chose répond-elle à des besoins d'utilisateurs spécifiques ?		#* Cette chose répond-elle à des besoins d'utilisateurs spécifiques ?
	#* Connaissons-nous (ou pouvons-nous facilement formuler) ces types d'utilisateurs et leurs besoins ?		#* Connaissons-nous (ou pouvons-nous facilement formuler) ces types d'utilisateurs et leurs besoins ?
Ligne 61 :		Ligne 61 :
	#* L'équipe peut-elle définir sa propre feuille de route en fonction de ce qu'elle estime être le mieux pour le produit et ses utilisateurs (de sorte que l'équipe ne soit pas guidée par les exigences et les priorités d'autres équipes) ?		#* L'équipe peut-elle définir sa propre feuille de route en fonction de ce qu'elle estime être le mieux pour le produit et ses utilisateurs (de sorte que l'équipe ne soit pas guidée par les exigences et les priorités d'autres équipes) ?
	== Autres considérations==		== Autres considérations==
	* ~~‘’’Vocabulaire ‘’’~~ : le vocabulaire est-il cohérent entre les différentes parties du système ou les différents domaines métiers ? Si ce n'est pas le cas (si le même mot a une signification différente dans des domaines différents), il peut être nécessaire d'avoir deux services ou systèmes différents.		* '''Vocabulaire''' : le vocabulaire est-il cohérent entre les différentes parties du système ou les différents domaines métiers ? Si ce n'est pas le cas (si le même mot a une signification différente dans des domaines différents), il peut être nécessaire d'avoir deux services ou systèmes différents.
	* ~~‘’’Phases ‘’’~~ : une partie du système traite-t-elle une phase antérieure ou postérieure du traitement ? Cela peut également représenter une bonne frontière.		* '''Phases''' : une partie du système traite-t-elle une phase antérieure ou postérieure du traitement ? Cela peut également représenter une bonne frontière.
	* ~~‘’’Cartes~~ de ~~Wardley‘’’~~ : la capacité ou le service pourrait-il être externalisé vers un produit SaaS ou un fournisseur de produits de base ? Sera-t-il bientôt externalisable ? Si c'est le cas, c'est un candidat à la séparation en tant que service distinct en vue d'une éventuelle externalisation auprès d'un fournisseur de produits ou de services de base.		* '''Cartes de Wardley''' : la capacité ou le service pourrait-il être externalisé vers un produit SaaS ou un fournisseur de produits de base ? Sera-t-il bientôt externalisable ? Si c'est le cas, c'est un candidat à la séparation en tant que service distinct en vue d'une éventuelle externalisation auprès d'un fournisseur de produits ou de services de base.
	* ~~‘’’Risque‘’’~~ : quel est le coût du risque lié à la scission de cette capacité ou de ce service ? Un problème pourrait-il survenir ?		* '''Risque''' : quel est le coût du risque lié à la scission de cette capacité ou de ce service ? Un problème pourrait-il survenir ?
	==Considérations détaillées==		==Considérations détaillées==
	* '''Couplage lâche''' : Cette ''chose'' a-t-elle un sens pour être migrée / déployée de manière indépendante dans le cloud public, indépendamment des ''choses'' apparentées ?		* '''Couplage lâche''' : Cette ''chose'' a-t-elle un sens pour être migrée / déployée de manière indépendante dans le cloud public, indépendamment des ''choses'' apparentées ?
Ligne 74 :		Ligne 74 :
	* '''Liquidité des compétences''' : Prenez en compte l'éventail des compétences au sein des équipes. Les équipes peuvent-elles chacune posséder leur service/système après la scission ?		* '''Liquidité des compétences''' : Prenez en compte l'éventail des compétences au sein des équipes. Les équipes peuvent-elles chacune posséder leur service/système après la scission ?
	* '''Anti-modèle - couplage de données''' : Votre "chose" dépend-elle d'un couplage fort / de pilotes de fournisseurs spécifiques ou utilise-t-elle des choses comme des liens de base de données plutôt que par le biais d'une API gérée et versionnée ?		* '''Anti-modèle - couplage de données''' : Votre "chose" dépend-elle d'un couplage fort / de pilotes de fournisseurs spécifiques ou utilise-t-elle des choses comme des liens de base de données plutôt que par le biais d'une API gérée et versionnée ?
	* '''Anti-modèle - coordination des versions''' : Les producteurs et les consommateurs en amont et en aval ont-ils besoin que votre "chose" ~~maîtrise une version~~ (par exemple, un train de versions) ou peuvent-ils publier des versions indépendamment aussi souvent qu'ils le souhaitent ?		* '''Anti-modèle - coordination des versions''' : Les producteurs et les consommateurs en amont et en aval ont-ils besoin que votre "chose" coordonne des versions (par exemple, un train de versions) ou peuvent-ils publier des versions indépendamment aussi souvent qu'ils le souhaitent ?
	==Ressources==		==Ressources==
	* Regarder la présentation de Matthew Skelton et Nick Tune concernant ISH lors de DDD Europe 2022		* Regarder la présentation de [https://github.com/matthewskelton Matthew Skelton] et [https://github.com/ntcoding Nick Tune] concernant [https://www.youtube.com/watch?v=q8hwkDyL6Zs ISH lors de DDD Europe 2022]
	* En savoir plus sur les ~~topologies~~ d'équipe		* En savoir plus sur les [https://teamtopologies.com/key-concepts Topologies d'équipe]
	* Explorer les ~~heuristiques~~ de Domain-Driven Design - une partie de l'excellente communauté virtualDDD.com		* Explorer les [https://www.dddheuristics.com/ Heuristiques de Domain-Driven Design] - une partie de l'excellente communauté [https://virtualddd.com/ virtualDDD.com]
	* Apprenez à utiliser l'Event Storming pour découvrir différents domaines métiers - cela peut être une bonne "passerelle" vers le Domain-driven Design (DDD) - merci à Rebecca Wirfs-Brock pour cette idée.		* Apprenez à utiliser l'[https://techbeacon.com/devops/introduction-event-storming-easy-way-achieve-domain-driven-design Event Storming] pour découvrir différents domaines métiers - cela peut être une bonne "passerelle" vers le Domain-driven Design (DDD) - ''merci à [https://twitter.com/rebeccawb Rebecca Wirfs-Brock] pour cette idée''.
	* Découvrir les Cartes de Wardley		* Découvrir les [https://hiredthought.com/2018/09/01/intro-to-wardley-mapping/ Cartes de Wardley]
	* Lire des articles sur la Liquidité des Compétences par Chris Matts		* Lire des articles sur la [https://theitriskmanager.com/2013/11/24/introducing-staff-liquidity-1-of-n/ Liquidité des Compétences par Chris Matts]
	==Remerciements==		==Remerciements==
	Merci aux personnes du groupe de rencontre DDD de Londres pour leurs commentaires sur une première version de l'heuristique des services indépendants. 😻<br/>		Merci aux personnes du [https://www.meetup.com/dddlondon/events/265895638 groupe de rencontre DDD Londres] pour leurs commentaires sur une première version de l'heuristique des services indépendants. 😻<br/>
	<br/>		<br/>
	Merci également à :		Merci également à :
	* Nick Tune et le DDD Crew pour les supers ressources DDD		* [https://github.com/ntcoding Nick Tune] et le [https://github.com/ddd-crew DDD Crew] pour les supers ressources DDD
	* Kacper Gunia pour l'invitation à prendre la parole lors de la rencontre DDD de Londres		* [https://github.com/cakper Kacper Gunia] pour l'invitation à prendre la parole lors de la rencontre DDD de Londres
	* tous les contributeurs à ce dépôt.		* [https://github.com/TeamTopologies/Independent-Service-Heuristics/graphs/contributors tous les contributeurs à ce dépôt].

Heuristique pour des services indépendants - Historique des versions

Fabrice Aimetti : /* Ressources */

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti le 17 mai 2023 à 06:15

Fabrice Aimetti le 17 mai 2023 à 06:14

Fabrice Aimetti le 17 mai 2023 à 06:11

Fabrice Aimetti : Page créée avec « Category:DDD Auteurs : Matthew Skelton, Manuel Pais, Chris Combe, George-Leonard Chetreanu, Matt Wynne, Ersin Er, Eduardo da Silva, "penmanglewood", Phil Broering... »

Fabrice Aimetti : /* Ressources */

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti : /* Mode d'emploi */

Fabrice Aimetti : Page créée avec « Category:DDD Auteurs : Matthew Skelton, Manuel Pais, Chris Combe, George-Leonard Chetreanu, Matt Wynne, Ersin Er, Eduardo da Silva, "penmanglewood", Phil Broering
... »