8 – Les apports de la SOA

Une architecture SOA ne va pas générer de valeur ajoutée en soi mais apporte un changement de perspective dans la construction des systèmes informatiques. Dans les lignes suivantes, je vais essayer de donner quelques exemples de mesure du retour sur investissement dû à la SOA selon 2 points de vue.

 

ROI SOA vue du métier

1. Amélioration de la productivité par la réduction de la part du budget utilisé pour soutenir l’existant et la réduction des coûts d’exploitation et de maintenance. Le but de la SOA n’est pas de réduire les budgets des services informatiques mais d’injecter les sommes économisées pour développer de nouvelles capacités.

2. Augmentation des revenus par le développement de nouvelles capacités métier et la mise à disposition plus rapide de nouvelles fonctionnalités permettant de capturer de nouveaux marchés.

3. Augmentation de l’efficacité opérationnelle par le développement d’une nouvelle capacité métier permettant d’améliorer l’efficacité dans l’exécution des processus métier et l’édition de rapports et d’analyse. La SOA, étant une approche tirée par les processus, remet la logique métier au cœur des fonctionnalités du SI. Les services métiers sont visibles donc mieux perçus par les responsables de processus. C’est une démarche qui favorise l’implication des métiers dans la construction du SI.

 

ROI SOA vue du SI

1. Réduction de la complexité de l’architecture devant facilité le développement de nouvelles fonctionnalités, la réduction de l’effort de test pour aboutir à une meilleure performance et une augmentation de la SLA.

2. Le découplage entre applications, applications / données, données / données minimise les redondances et donc les risques d’incohérence et optimise les relations transverses entre SI (« interopérabilité » entre blocs applicatifs).

3. Réduction des coûts par ré-utilisation de composants (à l’intérieur d’un même bloc applicatif pour des composants métiers ou de manière transverse pour des composants techniques) d’où des coûts de maintenance plus faible.

4. L’accès aux données est délocalisé, rendant transparente la synchronisation de bases hétérogènes et multiples.

5. Les cycles de développements sont raccourcis : le développement de composants de services ré-utilisables focalise sur la construction de nouveaux services par combinaison d’éléments fonctionnels ou techniques existants (concept « application composite »).

6. Souplesse des modifications et une meilleur intégration avec les autres systèmes aboutissant à une réduction de la durée d’indisponibilité et des erreurs au moment des tests d’acceptance.

7 – Hiérarchie des éléments SOA

Un service n’est pas un composant.

• Evolution naturelle : Fonction – Composant – Service – Processus
• Le processus correspond à un assemblage de services orchestrés.
• Les services gèrent messages, données et composants :
  • Les données privées sont totalement encapsulées par le service.
  • Les messages sont le seul moyen d’échanges entre services.
• Un composant correspond à une unité de traitement exécutable (EJB, servlet, …).

6 – Définition SOA

L’adoption de l’architecture orientée services a pris un essor conséquent depuis sa réintroduction dans les bonnes pratiques d’architecture et la souplesse apportée par les web services. La multiplication d’articles et de documents parfois incohérents et le discours des éditeurs très orientés catalogue rendent très difficile la compréhension des concepts.

La SOA est un ensemble de principes d’architecture SI basés sur l’ouverture, la flexibilité, l’extensibilité et consistant à orchestrer/coordonner des services pour réaliser un processus métier.

Un service est conceptuellement autonome, indépendant des technologies d’accès aux ressources, interopérable, potentiellement réutilisable et possédant une qualité de service. La description et l’implémentation d’un service sont basées sur des interfaces pour permettre le découplage du fournisseur et du consommateur via des protocoles et standards ouverts (ce qui explique son succès actuel par rapport à des initiatives plus anciennes comme CORBA ou DCOM).

Pour aller plus loin dans la compréhension des concepts, le modèle de référence SOA de OASIS constitue une très bonne lecture. En effet, les concepts et les relations définies sont les bases nécessaires pour construire des architectures concrètes en prenant en compte les spécificités imposées par le contexte ou l’environnement de déploiement (standards, protocoles, spécifications, ..).

Les web services grâce à leurs spécificités (standardisation, large adoption dans l’industrie, couplage faible, virtualisation , …) offrent un moyen standard de communication entre les services et de fait constituent une solution technique à la SOA.