Architecture Orientée Services (SOA)
Gouvernance SOA : la phase de Design Time (3)
- Si le service est appelé par une application ou un autre service externe il est alors dans le rôle d’un fournisseur,
- dans le cas contraire où c’est lui qui utilise un service externe il devient un consommateur.
- le rôle d’intermédiaire actif ou passif entre deux services
- rôle de contrôleur
- simple membre d’une composition.
- le cycle de vie des contrats de services,
- la standardisation des données
- la conformité du design par rapport aux contraintes de performance, fiabilité et qualité de services.
- Identifier les besoins :
- permet d’identifier les besoins des clients qui sont à l’origine de la demande de service. Une question simple permettant de capturer les exigences des clients est de se demander pourquoi ces derniers veulent ils utiliser le service ou quelle est leur motivation principale ?
- Définir les objectifs :
- se focalise sur la définition des objectifs que les clients devraient atteindre en utilisant le service. Il s’agit du but même du service du point de vue du client mais aussi du point de vue du fournisseur de service. Cette étape permet de mettre en évidence ce que les clients espèrent avoir comment résultats et la mesure dans laquelle ils aimeraient l’obtenir.
- Définir les niveaux de services :
- concerne la détermination d’un seuil minimum de niveau de services qui doit être maintenu dans le cadre du contrat de service. Cela revient à garantir un minimum de qualité dérivée des besoins capturés dans la première étape. Il est aussi possible de planifier des actions de correction en cas de diminution de la qualité de service.
- Déterminer la responsabilisation :
- consiste à clarifier les responsabilités que chaque partie, clients et fournisseurs, doit assumer dans tous les cas de figure. Cette prise de responsabilité typique des contrats formels passés entre deux entités distinctes permet de définir en avance le comportement de chaque partie et de réagir plus rapidement face à l’imprévu.
- les besoins des clients,
- Leurs objectifs,
- les niveaux de services et la responsabilisation.
Gouvernance SOA : la phase de Design Time (2)
- par la volonté de supporter plusieurs types de services (services de processus, métier et de support),
- pour guider le développement de services vers une dimension supplémentaire de flexibilité et souplesse architecturale ainsi que de réutilisation de services.
- à exposer les fonctionnalités des applications existantes sous la forme de services et à bénéficier ainsi des caractéristiques propres aux services « wrapper », telles que des cycles de développement courts permettant de passer d’une architecture orientée composants à une SOA de base en très peu de temps,
- de réduire la complexité du développement,
- supporter l’intégration d’application à l’aide de services et promouvoir l’interopérabilité.
- les principes d’architecture,
- les principes de données,
- les principes d’application
- les principes de technologie.
- Les services,
- les données,
- la technologie sous-jacente.
- mécanismes de création,
- recherche,
- découverte
- utilisation des services.
Gouvernance SOA : La phase de Design Time (1)
- Design-Time,
- Run-Time,
- Change-Time
- le format,
- le contenu et
- l’emplacement approprié des documents tels que les modèles de données, les fichiers de code, etc.
- l’analyse et capture des exigences métier
- la conception et implémentation des services.
- les tâches liées à l’analyse orientée service des processus métier, à savoir la définition des exigences métier,
- l’identification des processus métier,
- la définition des modèles services
- l’analyse des fonctionnalités et des systèmes existantes.
- les tâches de modélisation de services telles que la décomposition des processus métier en sous-processus,
- l’identification des opérations candidates,
- implémentation des services
- la construction des prototypes.
- Promouvoir la réutilisation
- Promouvoir l’interopérabilité
- Mesurer et comparer la performance des services
- Identifier et fournir les bons services
- Guider l’implémentation de l’infrastructure nécessaire au support de SOA
- la création,
- la publication
- la maintenance des interfaces de service.
- le design de haut niveau,
- le design détaillé
- l’implémentation.
- l’alignement stratégique,
- les risques
- les investissements IT.
- les politiques de réplication des registres
- le choix entre les stratégies de fédération ou centralisation des registres. Les mécanismes qui permettent de créer et de modifier les métadonnées concernant les interfaces,
- Le comportement et les politiques des services.
4/11 Projet informatique : passer du moyen âge à l'ère industrielle. Résolvez l'équation : ROI = SOA
SOA (Service Oriented Architecture) permet un véritable alignement entre les objectifs stratégiques de la direction générale et les technologies de la DSI. Cette traçabilité entre les services fonctionnels et leurs implémentations permettra d'obtenir les investissements et leurs bénéfices à moyen terme.
Pendant la tempête, maintenez la voilure sinon gare au naufrage.
La récession menace, il est difficile alors pour les DSI de convaincre la direction générale des bienfaits des SOA (Service Oriented Architecture). La stratégie générale est de geler les projets et d'attendre la reprise économique plutôt que d'investir dans de nouvelles pratiques aussi bonnes soient elles. Comme tout le monde va faire pareil, il est urgent de prendre le contre pied pour se différencier et trouver de nouveaux moyens pour accomplir les objectifs stratégiques d'expansion de l'entreprise.
Les applications existantes correspondent aux lignes d'activités verticales sans sans réelle communication entre elles avec de nombreux modules fonctionnels en double.
Le découpage en services réutilisables, composables permet de rendre les technologies comme une expression concrète des processus d'entreprise - et non comme un ensemble disjoint de
systèmes représentant chacun un fragment de processus. Parallèlement, les processus métiers sont encapsulés et peuvent ainsi faire l'objet de mesures et d'analyses de pertinence.
Les applications informatiques sont réalisées avec des méthodes antédiluviennes ou on conçoit des nouveaux composants alors qu'ils existent par ailleurs faute d'avoir un catalogue efficient des services déjà réalisés et des technologies permettant de les utiliser.
Imaginez Apple, obligé de recréer processeur, écran, batterie, appareil photo, système d'exploitation, applications à chaque fois qu'un nouveau modèle d'iphone sort sur le marché.
Les processus peuvent alors être exprimés comme un ensemble de services assemblés (ou « orchestrés ») constituant un processus complet. Les contrats gouvernant les services intègrent des mécanismes pour mesurer les performances générales et vis-à-vis d’indicateurs clés. Mais ils mesurent aussi la conformité avec les engagements de qualité de service (SLA). Ces éléments quantitatifs permettent de mettre en lumière des opportunités d'améliorations et de réaliser une boucle d’itération pour aligner les systèmes d'information sur les besoins métiers.
L'augmentation du "time to market" c'est-à-dire la rapidité à laquelle on met une nouvelle fonctionnalité à la disposition du métier permet de renforcer la communication entre la DSI et les grands domaines fonctionnels. L'osmose produite entre technologie et besoins fonctionnels permet à la DSI d'obtenir plus facilement l’adhésion des directions métier dans le cadre d'un partenariat stratégique.
Le développement par ligne d'activité conduit à des applications en silos qui réduisent la visibilité et complexifient les processus transverses. Pour pallier au manque de transversalité, on crée des comités d'architecture qui se focalisent sur des solutions techniques sans avoir une autorité suffisante pour faire appliquer leurs recommandations. Ces organes doivent bénéficier de prérogatives étendues de gouvernance et instaurer un mécanisme de définition, déploiement, pilotage et administration d’accès standardisés aux fonctionnalités d’entreprise – avec une granularité et une visibilité adaptées aux différentes communautés d’utilisateurs. Seule une architecture de service idoine, associée à des principes de gouvernance renforcée, permet de développer une plate-forme de déploiement adaptée.
Mais la question qui nous préoccupe est le retour sur investissement. La collaboration renforcée entre le métier et le technique est rendu possible par l'amélioration en continu des processus et la réalisation de services métier. On peut donc quantifier la contribution de la DSI aux métiers, de calculer le rapport coûts/bénéfices service par service.
Bien sur on a les traditionnels avantages informatiques comme la réutilisabilité, l'évolutivité, la maintenabilité, la portabilité, la documentation, … Mais la ou on aura un réel bénéfice c'est au niveau de la valeur créée pour les clients permettant de les fidéliser et d'améliorer l'image de la société.
Il faudra savoir attendre ces retours sur investissement qui se concrétisent sur plusieurs années lorsque les services commencent à être mutualisés. Mais pour surfer sur la vague ne faut il pas se lancer et prendre de la vitesse au bon moment.
Voir aussi le site :