Tâche: Analyse des actifs existants
Cette tâche identifie les éléments de conception d'une solution orientée services en termes de services et de partitions et documente la spécification initiale de ces services.
Objet
  • Identifier les éléments de conception d'une solution orientée services en termes de services et de partitions.
  • Documenter la spécification initiale des services.
  • Déterminer les dépendances initiales et la communication entre les services.
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif: Externe:
  • Aucun
Sorties
Description principale
L'analyse des actifs existants est le processus consistant à optimiser les actifs existants (par exemple, les systèmes existants tels que les applications intégrées ou personnalisées) ainsi que les normes de l'industrie, les modèles et les actifs afin d'atteindre la réalisation des services. A l'aide d'une approche ascendante, l'analyse des actifs existants identifie et valide les services candidats, les composants et les flux. Les contraintes techniques liées aux systèmes existants doivent être évaluées le plus rapidement possible à des fins de gestion des risques. Par conséquent, l'étude de faisabilité technique des décisions de réalisation des services doit être menée le plus rapidement possible après/pendant l'analyse des actifs existants.
Etapes
Identifier des services candidats à partir d'applications personnalisées

Deux sous-étapes sont utilisées pour identifier la fonctionnalité fournie par les applications existantes. La première sous-étape, le mappage à granularité grossière, mappe les processus métier avec le portefeuille des applications existantes. La seconde sous-étape, le mappage à granularité fine, mappe un service à une transaction ou un traitement par lots spécifique, au sein de l'application existante. Le mappage à granularité fine est effectué pendant la spécification de service.

L'objectif du mappage à granularité grossière est d'obtenir le mappage préliminaire, c'est-à-dire initial, des fonctions métier avec les services.

Il faut comprendre la relation entre le processus métier et les applications existantes pour distinguer les services candidats des fonctionnalités dans les applications existantes. Cette relation peut être décrite sous la forme d'un mappage à granularité grossière. Ce mappage est établi entre les activités métier ou les processus métier et les fonctions métier des applications existantes, comme illustré ci-dessous.

Pour capturer les relations entre les processus métier et les applications existantes, nous effectuons les étapes de mappage à granularité grossière suivantes :

  1. Comprendre les fonctions métier prises en charge par chaque application.  Généralement une fonction métier peut être mappée sur une activité au sein d'un processus métier.
  2. Enregistrer les attributs des applications existantes en termes de technologies utilisées, de styles architecturaux, etc.
  3. Identifier les applications qui exécutent des services communs.

Mappage à granularité grossière et analyse de portefeuille d'applications

Comprendre la valeur métier et la qualité technique des applications existantes aide à créer un plan de transformation dont la priorité la plus élevée est donnée aux services à la valeur la plus élevée ; cela aide aussi à évaluer la portée et les risques techniques en fonction des qualités techniques de l'application, par exemple, du degré de couplage.

L'analyse de portefeuille d'applications fournit une portée et des limites au mappage à granularité grossière. Par exemple, des applications ayant une valeur métier minimale ou une valeur technique faible et qui sont ciblées pour obsolescence n'entreront probablement pas dans le cadre de l'identification des services candidats.

Si elle est effectuée, l'analyse de portefeuille d'applications peut fournir des informations sur les services existants pour le mappage à granularité grossière. Cette analyse renvoie des services candidats, comme illustré ci-dessous.

Identifier des services candidats à partir d'applications intégrées

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 :

  1. Une compréhension de l'importance et de l'influence du package ISV au sein de l'entreprise.
  2. La propension à réaliser tout nouveau service via le package ISV.
  3. Les normes architecturales et les composants techniques utilisés dans le package ISV et leur rôle au sein de l'entreprise.
  4. 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Vérifiez que les exigences non fonctionnelles liées aux actifs sont documentées

Lors de la documentation des exigences non fonctionnelles liées aux actifs existants, les rubriques clés suivantes doivent être prises en compte.

  • Traitement des exceptions - Il faut comprendre le fonctionnement actuel du traitement des exceptions. Dans un traitement par lots, lorsqu'une exception se produit, le programme est interrompu (se termine anormalement) et produit un cliché du processus core. Le programmeur doit examiner le cliché du processus core et déterminer les mesures à prendre. Cela peut ne pas être acceptable. On peut envisager les mesures à prendre et, par exemple, comment intégrer ces mesures à une infrastructure préfabriquée de traitement des exceptions.
  • Distribution des processus et des données - Il convient d'examiner où les données et les processus sont exécutés. Une application CICS s'exécutant sur une machine peut envoyer une requête vers une autre machine (mécanisme également appelé accès aux ressources éloignées sous CICS) ou des données d'appel distantes sur une autre machine. Il est possible d'envisager d'aller directement (JDBC vers BD) sur la machine distante où s'exécutent les processus ou les données, plutôt que d'utiliser le connecteur allant de JDBC à la base de données.
  • Disponibilité des données - Si un fichier client dans VSAM requiert, par exemple, une fenêtre de maintenance pendant 4 heures, il est impossible de prendre en charge un service client 24 heures sur 24 et 7 jours sur 7. Il convient alors d'envisager une nouvelle solution de stockage.
  • Autorisation/Authentification - De nombreuses applications existantes contiennent les mécanismes d'authentification et d'autorisation dans leur code d'application. Cela requiert la migration de la gestion des accès utilisateur vers un environnement géré fédéré, pris en charge par les meilleures pratiques.
  • Délais de transfert - Généralement des programmes de traitement par lots s'exécutant une fois par jour, pendant la nuit. Si le programme doit être exécuté plus fréquemment, il convient alors de modifier la planification afin d'agir sur la fréquence.
Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Plus d'informations