Les 10 pièges de la SOA : 07 – Mauvaise granularité des services
De par leur implication dans des projets SOA (Service Oriented Architecture), les consultants de Xebia vivent de belles réussites. Mais ils rencontrent aussi un certain nombre de projets qui peinent ou qui sont en échec.
Afin de partager ces expériences, nos collègues hollandais, Gero Vermaas, Viktor Grgic, Rik de Groot et Vincent Partington déroulent une série de billets présentant les 10 pièges de la mise en œuvre d’une architecture orientée services (SOA). Comme toujours dans ce genre de « classement », cette liste n’est ni exhaustive ni définitive.
Le quatrième de ces pièges porte sur la mauvaise granularité des services (on entend par mauvaise granularité qu’un service couvre trop ou trop peu de fonctionnalités).
Une mauvaise granularité de services dans une SOA peut conduire à :
- De mauvaises performances ;
- De faibles capacités de réutilisation ;
- Des services sans valeur ajoutée métier.
Les principales causes de ces travers sont :
- Un design full top down ou full bottom up (Cf. « Mise en œuvre d’une SOA : Les clés du succès« ) ;
- Une perspective trop étroite (adoption d’une vision projet plutôt qu’entreprise).
Dans ce billet, nous examinerons de plus près ces symptômes et leurs causes. Puis nous verrons pourquoi la solution réside dans l’adoption d’un point de vue business lors de la conception de services.
Les symptômes annonciateurs d’une mauvaise granularité de services dans une SOA
- Personne n’est en mesure d’expliquer aux gens du métier (par exemple ventes / marketing) ce que font les services. Ceux-ci ne s’intègrent pas dans leur compréhension du métier de l’entreprise. Ces services sont donc à un niveau de détail qui n’est pas pertinent d’un point de vue métier.
- De nombreux services sont nécessaires pour réaliser quelque chose de valeur dans le métier de l’entreprise.
- L’utilisation des services au sein de la SOA conduit à énormément de petites interactions entre les systèmes ce qui impacte dramatiquement les performances de l’ensemble.
- Les services sont des variantes des opérations de base CRUD (Create, Read, Update, Delete) et n’y apportent aucune valeur fonctionnelle.
- La définition des services décrit la façon dont ils sont implémentés (par exemple, il est possible de déduire de la définition d’un service que celui-ci s’appuie sur une base de données).
- La plupart des services disponibles sont définis de telle façon qu’ils ne sont utilisés (utilisables) que par une seule (ou quelques) application(s).
- La propriété (responsabilité) des services n’est pas clairement définie. Plusieurs entités pensent qu’elles doivent être responsables d’un même ensemble de services.
- La SOA utilise beaucoup de couches de services composites. Ainsi, le plus haut niveau de service expose peut-être la bonne granularité, mais ce sont les services composés (des couches sous-jacentes) qui n’ont pas la bonne granularité. Cette mauvaise granularité est souvent causée par l’un des symptômes présentés ci-dessus et des couches supplémentaires de compositions sont mises en place pour le compenser.
Quels sont les pièges qui mènent à ces symptômes ?
Nombre de ces symptômes sont causés par une conception full Bottom Up.
Par exemple, lorsqu’un système existant est relié à une SOA, il est tentant de prendre telles quelles les APIs de ce système et d’exposer ses opérations en tant que services au sein de la SOA. Facile à faire, mais les services ainsi introduits n’auront pas de sens métier et seront potentiellement d’un grain trop fin (l’exemple le plus évidant étant les services de type CRUD). Certains parleront ici de SOA de surface.
Dans le cadre d’une démarche full Bottom Up, il peut également arriver que plusieurs entités (ou projets) travaillent sur les mêmes fonctionnalités sans le savoir, ou pire, sans souhaiter utiliser les travaux connus d’autres entités (un cas typique du syndrome « Not Invented Here »). Ainsi, chaque entité ou projet se contente de considérer son propre point de vue ce qui conduira à de multiples implémentations des mêmes services.
D’un autre côté, un design full Top down n’est pas le remède à une conception full Bottom Up, loin de là.
En effet, lorsque les services sont conçus de façon Top Down et décomposés sur les niveaux inférieurs, on arrive souvent à une myriade de services qui ne sont utilisables que dans le cadre de leur arbre de décomposition. De plus, différentes branches de l’arbre de décomposition peuvent contenir les mêmes services et les services d’une branche sont fortement couplés aux autres services de leur branche.
La conception théorique de services est un autre piège menant à une mauvaise granularité de services : des architectes ou concepteurs « tour d’ivoire » définissent des services sans liens concrets avec les projets ou processus métiers. Cela conduit à des services qui sont tellement génériques qu’aucun projet ne peut les utiliser sans les adapter. Ainsi, chaque projet va décliner ses propres variations des mêmes services.
Quel est le bon niveau de décomposition de services ?
Trouver la bonne granularité de services n’est pas aussi simple que de suivre une recette. Trouver le bon équilibre exige des connaissances, de l’expertise et l’expérimentation de différentes options. Voici cependant quelques lignes directrices qui permettent d’éviter certains travers (sans pour autant les éradiquer à coup sûr) :
- Les services devraient être décomposés en ensemble de « plus petites unités réutilisables », chacune de ces unités devant rester compréhensible par les gens du métier ( »business owners »). De plus, un service ne doit pas être une composition de services à grains plus fins qui ne sont pas disponibles en tant que services distincts (Les exposer laisse ouverte la possibilité de composer d’autres services).
- D’autre part, il est important que la responsabilité (ownership) d’un service soit clairement définie. Or, si les services sont définis avec un grain trop fin, il sera très difficile de les assigner à un propriétaire.
- Enfin, un service doit rester aussi autonome que possible. Si quelqu’un veut utiliser un service, il ne doit pas être contraint à utiliser d’autres services connexes (ce qui n’empêche pas le service en question de faire appel à d’autres services).
Quoi qu’il en soit, l’important est d’itérer. Il serait utopique de vouloir arriver au bon découpage du premier coup. Au fur et à mesure des itérations, si les symptômes évoqués ici apparaissent, il est possible d’y remédier par refactoring (d’autant plus simplement qu’ils sont détectés tôt).
Traduction libre du billet « Top 10 SOA Pitfalls: #7 – Incorrect granularity of services » publié par Gero Vermaas.
Billets sur le même thème :
- Les 10 pièges de la SOA : 05 – Big Design Up Front (BDUF)
- Les 10 pièges de la SOA : 04 – Mauvaise utilisation des Modèles de Données Canoniques (pivots)
- Les 10 pièges de la SOA : 02 – Propriété des composants et Financement au projet
- Les 10 pièges de la SOA
- SOA : Du composant au service : La composabilité
Bonjour,
Dans les projets auxquels vous participez, quelle(s) méthodologie(s) employez-vous pour identifier, spécifier et gouverner les services de la SOA ?
Comment vous y prenez vous pour « adopter un point de vue business » lors de la conception de ces services ? Cela implique-t-il de disposer d’un plan d’urbanisme, d’une cartographie fonctionnelle du domaine concerné, d’une démarche d’architecture d’entreprise, d’un inventaire des processus métier ou des chaînes de valeur ?
Quels sont les profils impliqués (RACI) lors du cycle de vie de ces services ?
Dans les projets auxquels nous participons (qu’il s’agisse de SOA ou pas) nous nous efforçons de promouvoir et de mettre en œuvre les bonnes pratiques issues des méthodes agiles.
Dans ce sens (et idéalement), l’identification des services à réaliser passe par un « Product Backlog » qui constitue la liste des fonctionnalités d’un logiciel. Les éléments du Product Backlog sont rédigés par le « Product Owner » (Directeur de Produit), qui possède l’expertise fonctionnelle. Ils sont rédigés sous forme de « User Stories » (une forme simplifiée et faiblement détaillée de cas d’utilisation), et doivent se focaliser sur les objectifs métier du produit. L’adoption de cette démarche implique en elle-même l’adoption d’un point de vue métier lors de la conception des services puisqu’un service répond à (réalise) un besoin métier exprimé par un expert fonctionnel.
Quelque soit la méthode mise en œuvre, le meilleur moyen d’adopter un point de vue métier est de faire spécifier les services (et les fonctionnalités qu’ils réalisent) par un expert fonctionnel (métier).
Concernant, les plans d’urbanisme et les cartographies fonctionnelles, en dépit des bénéfices attendus, leur mise en œuvre passe (quasiment systématiquement) par une démarche full Top Down. On tombe alors dans le piège du BDUF (Big Design Up Front) que nous traiterons prochainement dans cette série.
Les inventaires des processus métiers et des chaînes de valeur peuvent (doivent) eux aussi être réalisés au travers du Product Backlog. En effet, un processus est l’implémentation d’une User Story (à priori macro et donc décomposée). Les processus métier sont donc référencés dans le Product Backlog et hiérarchisés (comme tout élément qui le compose) en fonction de leur importance (de leur valeur) aux yeux du Product Owner.
[...] Les 10 pièges de la SOA : 07 – Mauvaise granularité des services [...]
[...] Les 10 pièges de la SOA : 07 – Mauvaise granularité des services [...]
La liste est maintenant complète :
Les pièges liés à l’implémentation :
- N° 10 – Le syndrome « Not Invented Here »
- N° 09 – Le Versioning
- N° 08 – La sécurité
Les pièges liés à l’architecture et au design :
- N° 07 – Mauvaise granularité des services
- N° 06 – La SOA ne résout pas automatiquement la complexité
- N° 05 – Big Design Up Front (BDUF)
- N° 04 – Mauvaise utilisation des Modèles de Données Canoniques (pivots)
- N° 03 – Le manque de compétences
Les pièges liés à l’organisation :
- N° 02 – Propriété des composants et Financement au projet
- N° 01 – Ignorer les impacts culturels
Bonjour,
Concernant les symptômes annonciateurs d’une mauvaise granularité de services dans une SOA, la phrase suivante provoque débat avec mes collègues « les services sont des variantes des opérations de base CRUD (Create, Read, Update, Delete) et n’y apportent aucune valeur fonctionnelle. »
Peut-on considérer qu’un service de lecture est un service métier? (ex: pour afficher un compteur dans une IHM).
@ Nicolas
Dans une architecture SOA, on retrouvera nécessairement des services de lecture des données.
La qualification de service en service métier dépendra, à mon sens, de la nature de l’information retournée.
Si l’on prend l’exemple d’un opérateur téléphonique, un service retournant le nombre de points de fidélité acquis pour un client donné pourrait être considéré comme un service métier. Mais un service qui se contente de retourner le nombre de point est-il pertinent dans l’offre de services métier (service de plus haut niveau) ? Ne serait-il pas plus pertinent de proposer un service qui adjoint à ce compteur les offres ou promotions dont le client peut bénéficier grâce à ses points ?
Merci pour la réponse Christophe, nous sommes en phase. L’exemple que vous donnez correspond justement au cas auquel je pensais.
Christophe,
Pour compléter la réflexion sur l’exemple, j’aurais tendance à penser que si le service de consultation des points fidélité est bien un service métier, ce n’est pas le cas du service de mise à jour correspondant. Ma vision est que le ou les systèmes calculant ces points fidélité dans le SI le font de manière autonome et non dans le cadre d’un processus métier.
Le pire pour moi serait de définir comme étant métier les services majPointFidelité ou supprimerPointFidélité.
Qu’en pensez-vous?
Merci.
Nicolas,
Une fois de plus cela dépend du point d’entrée choisi.
Je pense effectivement qu’un service ajouterPointDeFidelite qui prend en paramètre un nombre de points et qui se contente d’incrémenter un conteur (ou, plus certainement, d’ajouter une ligne dans la table idoine) n’est pas un service métier.
Par contre, un service calculerPointDeFidelite qui calcule le nombre de points à attribuer au client en fonction du montant de sa dernière facture, de son ancienneté, de son éventuelle adhésion à un programme promotionnel, etc. offre lui une valeur ajoutée métier et doit être considéré comme un service métier. Dans son implémentation, il se peut que ce service prenne en charge la mise à jour du conteur en base, mais ce n’est pas là sa valeur ajoutée.
On est d’accord Christophe. Merci pour votre retour.