Méthode d'évaluation
pour la réutilisation
des services SOA

Le problème

Je fournis des services de consultation avec les produits Oracle depuis 1991 et je vois toujours le même problème au fil des ans: la duplication des fonctions et des données. La duplication oblige les organisations à construire et à entretenir des processus de synchronisation (interface) entre les différentes applications de l'organisation.

Par exemple, le département marketing d'une organisation stocke les informations relatives à la vente de produits dans un système de gestion de contenu (CMS). Cette information est ensuite affichée sur le site Web de l'entreprise. La plate-forme Web de la société est bien intégrée au CMS. Les clients peuvent utiliser ces informations pour les aider dans leurs achats. Mais l'information de produits est également utilisé par le département des finances. Ces informations sont également stockées dans la base de données du système ERP. Par conséquent, nous avons les mêmes informations de produit dans le CMS et également dans la base de données du système ERP. Si les informations de produits sont modifiés dans le CMS et non dans l'ERP alors des incohérences peuvent se produire. Cette organisation a besoin d'un processus de synchronisation entre la CMS et la base de données du système ERP.

Le but de cet article

Le but de cet article est d'expliquer une méthode d'évaluation de la réutilisation des services impliqués dans un projet SOA lorsque les services sont dans la phase de conception.

Cette approche peut être utilisée par le gestionnaire pour aider à construire l'analyse de rentabilisation d'un projet SOA à éviter la duplication des fonctions et des données et aussi pour aider à promouvoir des projets SOA. La réutilisation peut également être appliquée non seulement aux services mais aussi à d'autres actifs utilisés par un projet SOA comme modèle de processus d'affaires, XML et des fichiers WSDL.

Le but de la réutilisation

Le but principal de réutiliser une fonctionnalité existante est de coder la fonctionnalité une fois et éviter le coût du maintien implémentation différente de la même fonctionnalité. Mais d'abord, nous devons reconnaître que la construction d'une fonctionnalité qui peut être utilisé pour un seul projet prendra moins de temps que de construire la même fonctionnalité qui peut être utilisé par de nombreux projets et applications. En outre, il n'est pas tous les services qui peuvent être réutilisés.

Le désigne des services et la réutilisabilité

Certaines personnes pensent que plus un service est générique plus sa réutilisation élevée. Mais un service peut être très difficile à utiliser s’il est trop générique. Un développeur devra avoir beaucoup de connaissance au niveau de la mise en œuvre du service pour être capable de l'utiliser correctement. Je pense que les paramètres et la gestion des exceptions d'un service doivent être clairs et précis. Par exemple, un service comme EmployeeAssignmentService pour gérer les affectations des employés et un service comme UpdateEmployeeAssignment qui fonctionnement avec un paramètre EmployeeData. Si un consommateur du service veut mettre à jour l'affectation d'un employé, le paramètre à fournir n'est pas claire. Quelle sont les informations que la paramètre EmployeeData doit contenir et qu’elle informations d'affectation voulons-nous mettre à jour? Nous devons fournir une opération comme UpdateAssignmentSupervisor avec des paramètres comme employeeId et la date. Cela permet une meilleure chance de les réutiliser.

Programme de réutilisation

Beaucoup de programmes de réutilisation de l'organisation consistent simplement récupérer l'ancien code pour une utilisation ultérieure (parfois dénommé «réutilisation non planifiée»). Cependant, les plus grands avantages de la réutilisation est de s'engager dans un programme de réutilisation formelle, prévues et devraient se produire tôt dans le cycle de développement d'un projet SOA (2).

Le pourcentage de réutilisation

Avec l'approche SOA, le pourcentage de réutilisation est supérieur à celle d'une approche traditionnelle basée sur des composants, car SOA est basée sur la réutilisation des services autant que possible. Réutilisation des fonctionnalités existantes (services) fait en sorte qu'il peut être changé rapidement parce que vous n'avez pas à repartir de zéro à chaque fois.

Le niveau de réutilisation dans une application typique SOA a augmenté de 25% par rapport à une moyenne de seulement 10% dans une application à base de composants traditionnel, qui entraîne des économies importantes sur les projets SOA à venir (1).

Mais le directeur informatique doit mettre en place de bonnes mesures pour évaluer les coûts et les avantages de la réutilisation qui est un processus d'évaluation des actifs que de se concentrer sur des économies de développement. Il est de bonne pratique de nommer un groupe dans une organisation qui est responsable et de promouvoir le programme de réutilisation. Il peut être l'une des tâches de la Commission de révision de l'architecture d'entreprise. Ce groupe connaît les applications critiques, les entités de données communes et des processus d'affaires. Cela peut être un bon point de départ pour identifier les possibilités de réutilisation potentielles. Ce groupe aura besoin d'outils pour aider à rechercher et à trouver des composants réutilisables donc besoin d'un référentiel de ressources réutilisables. Mais nous devons comprendre que ces choses coûtent de l'argent pour l'organisation.

Métrique de réutilisation

Estimation du temps nécessaire pour construire un service à usage unique

Cette mesure représente le temps passé (analyse, programmation et déploiement) pour fournir un service pour un projet donné.

Durée estimée pour construire un service pour une réutilisation

Cette mesure représente le temps passé à fournir un service pour une réutilisation. Il est habituellement le double du temps nécessaire pour construire le service à usage unique. (200%)

Par exemple, si nous considérons la phase de test, les modèles d'échange de messages probables disponibles au sein de l'entreprise doivent être testés.

Facteur de consommation

Le temps que le développeur va passer sur la réutilisation d'un service. Ce temps peut être évalué que 5% du temps estimé pour construire un service à usage unique. Mais ce nombre peut être ajusté en fonction de l'expérience.

Heures net prédit sauvegardé (3)

Cette mesure représente le coût de développement évitée grâce à la réutilisation du service ou de l'actif au lieu de recréer l'actif dans différentes applications. Par conséquent, il est: Heures nets prédit sauvegardé = Estimation du temps nécessaire à la construction d'un actif ou d'une fonction à usage unique - heure estimée d'utiliser un actif existant

Priorisation des investissements des services réutilisables

Nous pouvons utiliser les étapes suivantes pour aider à prioriser les investissements en services réutilisables:

• 1 - Estimer le niveau de consommation annuelle
• 2 - Calculer les heures nets prévus épargnées en dollars avec un taux de charge (burden rate) Le taux de charge est les frais généraux par heure pour une ressource donnée utilisé par un projet. Ce taux peut être fourni par le service des Finances.
• 3 - Calculer la valeur de réutilisation potentielle en dollars

La valeur de réutilisation potentielle en dollars:

Heures nets prédit épargnées x nombre de réutilisation annuelle du service X taux de charge par heure

Par exemple, nous estimons le nombre total d'heures de développement d'une version réutilisable du service addressVerification à 246 heures.

Le temps de développer une version non réutilisable est 50% du total des heures pour une version réutilisable: 436 heures x 50% = 123 heures pour une version non réutilisable du service addressVerification.

Le facteur de consommation est de 5%: 123 heures x 5% = 6,15 heures

Heure net prévue épargnées: 123 heures - 6,15 heures = 116,85 heures

Le nombre de réutilisation annuel du service est estimé que 10. Nous avons 10 applications potentielles différentes qui peuvent être un consommateur de ce service.

Le taux de charge totale par heure est de 100 $

Valeur de réutilisation potentielle en dollars: 116,85 heures x 10 x 100 $ = 116 850 $.

La feuille de calcul ci-dessous est un exemple de ce qui peut être utilisé pour calculer la valeur de réutilisation potentielle pour l'année:

Conclusion

L’Organisation doit se fixer des objectifs à atteindre dans la feuille de route SOA, mais doit également établi des indicateurs clés pour suivre les progrès. Il est très important de montrer la valeur monétaires des avantages de l’architecture SOA.

Références

(1) The ROI of SOA Based on Traditional Component Reuse, Jeffrey Poulin, Ph.D. and Alan Himler, MBA
(2) Determining the Value of a Corporate Reuse Program, Jeffrey S. Poulin Joseph M. Caruso
(3) Oracle Practitioner Guide, Determining ROI of SOA through Reuse, Stephen G. Bennett

Oracle® & Oracle® E-Business Suite
are registered trademarks of Oracle Corporation