Les packages d'éditeurs de logiciel indépendants (ISV) sont couramment implémentés pour activer les sous-systèmes et/ou
les composants de service au sein d'une organisation. Par exemple, les solutions ISV ERP (Planification des ressources
de l'entreprise), comme celles offertes par SAP, PeopleSoft et Oracle, sont souvent implémentées en tant que systèmes
complets, constitués de plusieurs sous-systèmes qui prennent intégralement en charge un ou plusieurs domaines au sein
d'une organisation. Cette section décrit une série d'étapes qui permettront au spécialiste d'identifier les
fonctionnalités et les services candidats au sein des packages ISV existants. Cette analyse alimente les produits de
travail Matrice de fonctions métier/système, Catalogue de règles métier et Modèle de services en fonction des capacités
des packages ISV existants.
Remarque : Etant donné que chaque package ISV est différent, il n'est pas possible de développer une approche
normative détaillée pour chacun d'eux. Les activités suivantes décrivent une approche générique et un ensemble
d'activités générique qui :
-
Identifient les services candidats au sein des packages ISV.
-
Identifient les caractéristiques de haut niveau des packages ISV qui seront prises en compte pendant la réalisation
des services.
Identification de packages ISV
Dans le meilleur des cas, les packages ISV, pour les domaines et les composants métier dans la portée, ont dû être
identifiés dans le système CBM en entrée de Fond de page de composant métier (ou équivalent). On obtient alors une
liste de packages ISV qui activent les fonctionnalités dans les composants métier spécifiques, dans la portée de la
solution envisagée. Si cette entrée est manquante, les packages ISV prenant en charge les domaines et les composants
métier dans la porté devront être identifiés et mappés avec des composants métier.
Notez que certains packages ISV, tels que ceux de SAP, PeopleSoft et Oracle, sont constitués d'un certain nombre de
modules élémentaires et facultatifs. Par exemple, SAP propose un module de fabrication, un module de ressources
humaines et un module de gestion de la relation client. Dans ce cas, il est important de spécifier quels modules
spécifiques des packages ISV sont utilisés. On obtient ainsi une analyse mieux centrée qui permet de gagner du temps et
d'éviter une prolifération de services inutile.
Catégorisation de packages ISV
La catégorisation des packages ISV donne un aperçu général des caractéristiques importantes dont il faudra tenir compte
pendant la réalisation des services (cela s'applique aux composants fonctionnels et techniques). Les ISV peuvent être
classés en ISV de niveau 1, 2 ou 3, en fonction de caractéristiques telles que les compétences, la taille et le revenu,
comme indiqué dans le récapitulatif du tableau 10. Notez tout particulièrement les aspects Impact technique et Impact
métier.
Catégorie d'ISV
|
ISV de niveau 1
|
ISV de niveaux 2 et 3
|
Description
|
ISV de grande taille comme les éditeurs d'outils ERP (Planification des ressources de l'entreprise)
fournissant des applications intégrées qui aident les entreprises à gérer leurs ressources et leurs
opérations principales.
|
ISV de petite et moyenne taille tendant à offrir des solutions métier verticales, spécifiques d'un secteur
d'activité
|
Caractéristiques
|
-
Applications intégrées, multimodule, intersectorielles pour la planification de produits, l'achat
de composants, la gestion des stocks, l'interaction avec les fournisseurs, la fourniture du service
client et le suivi des commandes.
-
Peuvent également inclure des modules applicatifs pour les aspects financiers et de ressources
humaines d'une entreprise.
-
Englobent généralement plusieurs composants métier et parfois des domaines dans une mappe CBM
-
Sont souvent mis en forme avec leurs propres logiciels intermédiaires propriétaires, leur fonction
de sécurité et d'autres composants techniques
|
-
Activent généralement des sous-systèmes verticaux, propres au secteur d'activité, qui prennent en
charge une fonction spécifique dans une entreprise.
-
Possèdent généralement des interfaces métier documentées avec un ou plusieurs ISV de niveau 1.
-
Contenus généralement dans un domaine CBM et un petit nombre de composants métier.
-
Dépendent généralement d'un logiciel intermédiaire tiers externe et d'autres composants techniques.
-
Peuvent avoir leurs propres composants de sécurité.
|
Impact technique
|
Etant donné leur "encombrement" élevé, ces ISV peuvent avoir une influence significative sur
l'architecture et les normes techniques utilisées dans une organisation. Dans ces cas, ces influences sont
identifiées et prises en compte pendant la réalisation des services.
Les logiciels intermédiaires et les autres composants techniques, tels que l'authentification et la
consignation, devront être pris en compte pendant la réalisation des services.
|
Généralement, ces ISV influencent peu l'architecture dans une grande organisation, mais, dans une
organisation plus petite et hautement spécialisée dans son secteur d'activité, ils peuvent avoir une
influence significative sur la réalisation des services.
En règle générale, ces packages ne fournissent pas leurs propres logiciels intermédiaires ou leurs
composants techniques. Ils peuvent dépendre pour cela d'un logiciel intermédiaire et de composants
techniques tiers, ou peuvent dépendre de ceux fournis par un ISV de niveau 1. Certains ISV plus petits
peuvent ne pas fournir d'interface pour les composants techniques. Ils peuvent dépendre pour cela d'un
logiciel intermédiaire et de composants techniques tiers, ou peuvent dépendre de ceux fournis par un ISV de
niveau 1. Certains ISV plus petits peuvent ne pas fournir d'interface pour les composants techniques.
|
Impact métier
|
Les organisations ayant investi dans des ISV de niveau 1 ont fréquemment une prédisposition à optimiser au
maximum ces packages d'ISV. Dans ce cas, il existe une forte propension à utiliser ces packages existants
pour la réalisation de services et l'activation de nouveaux services.
|
Etant donné que ces packages tendent à activer une portée plus faible de fonctionnalité, la propension et
l'opportunité pour développer ces packages afin de réaliser de nouveaux services sont moindres.
|
Exemples
|
SAP, Siebel, Peoplesoft, Oracle Financials
|
Manugistics, Provia, Evoke/TD>
|
Les packages ISV étant utilisés dans pratiquement toutes les organisations, la plupart des solutions orientées services
va incorporer des services réalisés à l'aide de composants de service basés sur des packages ISV. La catégorisation de
ces packages ISV permet au spécialiste de comprendre le rôle et l'importance relative de ces packages au sein de la
solution SOA ; elle leur permet également d'identifier les caractéristiques techniques et fonctionnelles qui seront
prises en compte pendant la réalisation des services.
Pour chaque package ISV, on peut comprendre les domaines suivants par l'analyse effectuée pendant la catégorisation :
-
Une compréhension de l'importance et de l'influence du package ISV au sein de l'entreprise.
-
La propension à réaliser tout nouveau service via le package ISV.
-
Les normes architecturales et les composants techniques utilisés dans le package ISV et leur rôle au sein de
l'entreprise.
-
Une compréhension des logiciels intermédiaires et des composants techniques compatibles avec le package ISV.
Analyser les options pour l'accès aux services dans les packages ISV
Cette étape identifie les mécanismes permettant d'accéder aux fonctions dans les packages ISV (c'est-à-dire, les
aspects techniques du package directement liés à l'exposition et à la réalisation des services). Ces informations
permettent d'identifier les services candidats dans les packages ISV (à la prochaine étape) et seront également
utilisées ultérieurement pour évaluer la faisabilité technique et prendre les décisions de réalisation des services.
Plusieurs mécanismes peuvent être utilisés pour accéder aux packages ISV. Pendant cette étape, chaque package dans la
portée est analysé pour déterminer et décrire les mécanismes disponibles pour chaque package. En général, les packages
ISV prennent en charge un ou plusieurs des mécanismes suivants :
Mécanisme
|
Description
|
Exposition directe en tant que service
|
Le package expose directement la fonctionnalité à l'aide de services compatibles avec SOA, qui sont
généralement des services Web. Ces services peuvent être répertoriés dans un catalogue. La conformité aux
normes et à l'interopérabilité de l'implémentation spécifique est évaluée.
|
Utilisation d'API
|
Le package fournit une ou plusieurs API pouvant être utilisée pour exposer des services dans le package.
Ces API peuvent être utilisées directement pour exposer la fonctionnalité en tant que service ou bien des
encapsuleurs de services Web ou une façade peuvent être développés pour permettre l'accès à la
fonctionnalité via l'API.
|
Accès direct aux données
|
Dans le cas où aucune API n'est disponible mais qu'un service exposant les données gérées par le package
ISV est requis, un service accédant directement à la base de données utilisée par le package est
développé.
Remarque : Si cette approche est techniquement réalisable, le contournement de la logique métier dans
le package ISV introduit un risque potentiel de détérioration des données ou de violation de l'intégrité
des données mise en oeuvre par un programme. C'est pourquoi, il est recommandé de limiter cette technique
aux services qui exécutent des opérations "en lecture seule". Malgré tout, cette approche reste risquée en
raison des modifications potentielles du schéma de données de l'ISV et doit, par conséquent, être appliquée
avec une grande prudence.
|
Techniques d'identification des services des packages ISV
Pendant cette étape, plusieurs techniques sont utilisées pour analyser les packages ISV et identifier la fonctionnalité
pouvant être exposée en tant que service. Les règles métier associées à la fonctionnalité sont également identifiées.
Chaque technique est utilisée pour évaluer les packages selon une perspective différente, ce qui permet une analyse
complète des packages pour y rechercher les services candidats. Les résultats de l'analyse sont capturés dans les
produits de travail Matrice de fonctions métier/système et Catalogue de règles métier. Comme avec les autres activités
d'identification SOMA, les services candidats sont ajoutés au portefeuille de services et à la hiérarchie de services.
-
Réviser le catalogue de services prédéfinis du package ISV
Certains packages ISV proposent un catalogue de services prédéfinis. Si tel est le cas, les services candidats
pour les domaines et les composants métier dans la portée sont identifiés dans le catalogue et ajoutés au
portefeuille de services. Si elle est prise en charge par l'ISV, cette technique représente la manière la plus
simple d'identifier des services candidats à l'aide de packages ISV.
Remarque : Pendant l'étape de spécification SOMA, le degré de granularité de ces services sera pris en
compte lors de la prise des décisions d'exposition des services. Il est donc important de capturer le degré de
granularité en tant que caractéristique des services candidats, pendant l'identification SOMA. Il peut être
nécessaire de regrouper ou de décomposer les services exposés en fonction de leur degré d'alignement avec les
services réalisés au sein des packages ISV. Cette analyse aide également à aligner les services candidats dans la
hiérarchie de services.
-
Réviser les API du package ISV
Les packages ISV peuvent offrir une ou plusieurs API pouvant être utilisées pour accéder à la fonctionnalité au
sein des packages. Ces API sont examinées pour les domaines et les composants métier dans la portée afin
d'identifier les services candidats à ajouter au portefeuille de services. Etant donné que la fonctionnalité
accessible via ces API n'est pas offerte en natif en tant que service, un encapsuleur de service ou une façade
devra être développé pour exposer ces appels d'API en tant que services. La souplesse de cette approche permet la
combinaison d'au moins deux appels d'API dans un seul service ce qui peut permettre le développement de services
dans les packages en vue d'un alignement avec des services de la hiérarchie de services. Dans ce cas, le
spécialiste identifie les services dans la hiérarchie de services et les mappe à la fonctionnalité de support et
aux appels d'API, au sein des packages.
-
Réviser les mappes de processus métier et l'enchaînement d'activités du package ISV
Les processus métier et l'enchaînement d'activités activés par un package ISV peuvent être documentés sous forme
de manuel imprimé ou au format électronique. Ces artefacts sont examinés afin d'identifier des services candidats
supplémentaires à ajouter au portefeuille de services. Plus précisément, cette révision doit comporter une vue de
bout en bout des processus métier dans les packages ainsi qu'un examen du contexte d'enchaînement d'activités dans
lequel le processus est exécuté. Ainsi, tout service candidat associé peut être identifié et les considérations
liées aux processus métier et à l'enchaînement d'activités sont identifiées afin d'être prises en compte pendant la
réalisation des services.
-
Identifier les limites de service du package ISV
Un package ISV est développé afin de prendre en charge des processus métier et de gérer des données dans une
portée alignée sur des composants métier (domaines fonctionnels) et des domaines. Ces composants métier forment
l'"encombrement" ou la "limite de service" des packages ISV. Toutefois, au sein d'une entreprise spécifique, le
package ISV peut être implémenté dans un sous-ensemble de la limite de service générale qui lui est associée. En
identifiant la limite de service générale du package ISV, le spécialiste détermine si des services supplémentaires
dans la limite de service du package doivent être ajoutés au portefeuille de services. En outre, le spécialiste
peut déterminer si de nouveaux services qui sont obligatoires doivent être réalisés via les packages ISV.
S'il est déterminé que de nouveaux services sont requis pour activer la solution orientée services, le spécialiste
doit définir si ces services sont compris dans la limite de service pour le package ISV. Si tel est le cas, les
services du package ISV qui prennent en charge la fonctionnalité requise sont identifiés et ajoutés au portefeuille
de services. Cela permet à la solution d'optimiser pleinement les capacités du package ISV ; cela réduit également
le risque de duplication au sein de plusieurs systèmes prenant en charge le même composant métier.
-
Analyser les données élémentaires contrôlées dans les packages ISV
Les données élémentaires entrant dans le cadre de la solution sont évaluées afin de déterminer si elles sont
gérées dans les packages ISV. Si les données sont gérées dans les packages ISV, d'autres processus métier, dans les
packages, qui lisent ou mettent à jour les mêmes données, sont analysés afin d'y rechercher des services candidats
à ajouter au portefeuille de services.
Cette analyse révèle également des processus associés ou externes et des interfaces pouvant être affectées par la
solution et devant être prises en compte pendant la réalisation des services. Ces interfaces sont documentées et
évaluées pendant la réalisation des services.
-
Analyser la sécurité et d'autres composants techniques du package ISV
De nombreux packages ISV contiennent leurs propres composants de sécurité pour l'authentification et
l'autorisation et peuvent contenir d'autres composants techniques prenant en charge des fonctions comme la
consignation et la messagerie. Pour chaque package, ces composants sont identifiés et analysés afin d'y rechercher
des services techniques candidats qui pourraient ajoutés au portefeuille de services.
En outre, pendant cette analyse, tout problème ou contrainte qui pourrait être introduit par ces composants est
identifié afin d'être pris en compte pendant la réalisation des services. Par exemple, l'interaction obligatoire
avec les composants de sécurité du package pour accéder à la fonctionnalité dans le package doit être comprise et
prise en compte pendant la réalisation des services.
L'application de ces différentes techniques d'analyse permet d'identifier des services candidats au sein des packages
ISV dans la portée, à partir de différentes perspectives. Ces différentes techniques d'analyse permettent également
d'identifier les problèmes et les contraintes introduits par les composants fonctionnels et techniques des packages ISV
et qui doivent être pris en compte pendant la réalisation des services.
|