Il est possible d’offrir des services de granularité plus forte en composant certains services.

Pour la consultation celà ne pose pas de problème mais qu’en est-il pour la modification? Faut-il gérer d’une manière ou d’une autre une forme de transaction?

Merci.

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.

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.

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 ?

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).

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

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.

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 ?