Architecture SOA et Cloud computing pour accélérer le SI

 La démarche SOA vise à intégrer les différents composants applicatifs d’un système d’informations et de gérer leurs interactions.

 

Concept mis en lumière au début des années 2000 par Gartner, la SOA (Service Oriented Architecture – architecture orientée services) est une démarche permettant d’intégrer les différents composants applicatifs d’un système d’informations et de gérer leurs interactions.

Elle  a pour objectif de faciliter l’intégration de nouvelles applications au sein de la structure IT d’une entreprise, en optimisant ses échanges et son fonctionnement.

Cette approche repose sur la réorganisation des applications grâce à des services, qui correspondent à des interfaces de communication. L’avantage est que ces services sont standardisés, donc interpretable de manière simple par d’autres applications partageant les même standards et potentiellement exploitables par l’ensemble des systèmes de l’environnement SI. Certains services exposent de la donnée, et d’autres consomment de la donnée, composant ainsi la base des échanges SI dans une architecture SOA.

De son côté, le Cloud Computing facilite l’accès aux ressources informatiques, avec comme principe fondateur la mise à disposition de ces ressources comme une commodité publique. Concrètement : la disponibilité par internet, l’élasticité, le paiement à l’usage de ressources informatiques sous forme de service.

Ainsi lorsque l’architecture SOA suporte le traitement agile de services informatiques et que le Cloud permet la mise a disposition de ces services de manière rapide et peu coûteuse, on peut en conclure que l’association de ces deux principes est pertinente pour les entreprises et leurs systèmes d’information, leur conférant ainsi plus de flexibilité.

---

La plateforme de communication est l’élément central d’une architecture SOA.

 

Comme nous l’avons dit, une architecture SOA permet l’échange de données entre les applications exposées par des interfaces standardisées (services). Ces derniers sont organisées autour d’une plateforme de communication (bus d’échange).

La plateforme de communication est l’élément central d’une architecture SOA. Elle représente la couche d’abstraction entre les flux applicatifs, ce qui permet d’éviter la création de connexions point à point. Concretement, à chaque intégration d’une nouvelle application dans le SI, il n’y a qu’une “demi-interface” à redévelopper pour l’intégrer : l’interface entre ses services, et le bus de communication. Elle pourra ensuite communiquer des informations à toutes les applications existantes du SI, via les connexions déjà existentes.

Un EAI est un exemple de bus de communication. Ce dernier peut intégrer des applications internes à l’entreprise (on premises) ou externe (Cloud dans l’exemple ci-dessous) :

 

 

Le service est bien sûr un composant clé de l’architecture orientée services. Encore une fois, il a pour objectif d’exposer ou de consommer des données.

Techniquement, mais en simplifiant légerement, un service est ensemble cohérent de fonctions (moteur) sur un ou plusieurs objet connexes, accessible par des API. Par exemple : dans le CRM, le service “Gestion des clients” pourra avoir, entre autres, comme fonctions “Création de client” “Modification de client” ou “Liste des des commandes clients”. Il interviendra sur les objets “Clients”, et “Commande”.

Pour le consommateur du service, homme ou machine, seul le résultat est visible et important. La complexité du service et son modèle de données ne sont pas connu du consommateur et c’est bien l’objectif.

 

Dans le cas d’une utilisation SaaS, la DSI qui devient le consommateur final n’a pas la vision de la mécanique du service, ne fait que consommer le service – et peut se concentrer sur sa valeur ajoutée pour l’entreprise.

Au final, une architecture orientée services consiste essentiellement en une collection de services qui interagissent et communiquent entre eux par l’intermédiaire du bus de communication. Il est important de garder en tête que ces services doivent être standardisés, indépendants, réutilisables et autonomes.

---

 

La démarche SOA a donc pour objectif de rendre le SI plus flexible, et plus efficace. Cette promesse ne peut être tenue que dans le cadre d’un environnement normé, maîtrisé, et répondant à un certain nombre de principes techniques définissant la manière de construire les services.

Elle entend créer un environnement dans lequel il est possible de réutiliser les services pour accélérer le développement, en permettant aux décideurs et développeurs de collaborer pour la mise à disposition de nouvelles applications métiers.

De par sa nature, l’architecture orientée services est une initiative à l’échelle de l’entreprise qui exige des niveaux élevés de communication, de coordination, de collaboration et de contrôle. La gouvernance SOA est le cadre qui permet, mesure, définit et renforce les règles de communication, de collaboration et de contrôle dans l’entreprise, ainsi qu’auprès des décideurs informatiques et métiers. Ce cadre est une extension de la gouvernance IT qui se focalise sur la gestion efficace de chaque aspect lié aux services.

Par contre, il ne s’agit pas d’un projet de refonte de gouvernance mais plutôt d’un projet qui s’inscrit dans la continuité des piliers existants dans la gouvernance IT. Ces piliers sont l’alignement des stratégies métier et IT, la valeur des livrables, la gestion de la performance, le management des ressources et des infrastructures et la maîtrise des risques sur le plan technologique.

On peut mesurer les apports sous deux angles : pour le service IT interne à l’entreprise et ses clients, les métiers.

Les apports pour les métiers :

• Améliorer l’agilité et la flexibilité du métier
• Faciliter la gestion des processus métier, en cassant les barrières organisationnelles et en améliorant le niveau d’intégration entre les applications.
• Réduire  le cycle de développement des produits  et améliorer le retour sur investissement : une fois les services définis et normés, développer une nouvelle fonctionnalité devient plus rapide car les données et fonctions des applications existantes sont déjà disponibles et utilisables. De la même façon les fonctions proposées par ce nouveau développement seront rapidement intégrables dans l’existant.

 

Les apports pour l’IT  :

• Réduire la complexité de l’architecture SI
• Construire les services une seule fois et les réutiliser fréquemment
• Garantir une intégration standardisée et le support de clients hétérogènes
• Faciliter la maintenance et les évolution du SI
• Réduction des coûts d’intégration et developpement de nouvelles applications

 

---

 

Les apports d’une architecture SOA sont donc évident pour l’entreprise. Cependant comme nous l’avons déjà expliqué, il s’agit d’un bouleversement profond de la manière dont le SI est construit. Les impacts dépassent naturellement le domaine technique, et influent sur des enjeux métiers forts.

Ainsi la mise en place d’une architecture SOA requiert une étude transverse poussée afin de comprendre certes la technologie, mais également les enjeux fonctionnels, et organisationnels sous-jacents.

Même si chaque contexte est specifique, des étapes clés peuvent être identifiées :

1 – L’Organisation

• Analyse interne des besoins d’amélioration de l’entreprise (brainstorming, audit)
• Analyse des ressources disponibles (budget, RH etc…)

 

2 – La Planification

• Elaboration d’une stratégie d’intégration
• Audit de chaque secteur de l’entreprise (métiers et IT) à travers leurs directions respectives
• Modélisation de l’existant (Business Processus, fonctionnel, applicatif, technique)
• Élaboration de la structure après intégration
• Planification des plans d’actions

 

3 – Le Déploiement

• Implémentation de l’architecture  SOA
• Formation et montée en compétence des utilisateurs
• Tests opérationnels de la SOA, mesures des performances et réajustements des actions
• Validation de l’intégration

 

L’approche SOA repose sur l’analyse précise et détaillée des processus métiers. A ce titre, elle requière la compréhension des différentes tâches, pour permettre l’intégration des différentes solutions informatiques à chaque niveau du processus.

Ainsi, pour maîtriser ces processus on intègre en parallèle de cette démarche le concept de BPM (Business process management). On appelle « BPM » l’approche consistant à modéliser informatiquement les processus métiers de l’entreprise, aussi bien dans leur aspect applicatif qu’organisationnel. L’objectif de cette démarche est d’aboutir à une meilleure vue globale de l’ensemble des processus métiers de l’entreprise et de leurs interactions afin d’être en mesure de les optimiser et, dans la mesure du possible, de les automatiser. Celle-ci intègre une fonctionnalité qui consiste en l’orchestration des services mis à disposition par les applications.

Ces deux approches (SOA / BPM) ont un objectif commun qui est de maximiser la valeur ajoutée de l’utilisation de l’information.

---

 

La mise en place d’une architecture SOA en entreprise présente de nombreux avantages. Cependant, cette mise en place est complexe, et demande une analyse des risques poussée.

Pour vous assister dans votre démarche, nous avons recensé les cas les plus fréquents de projets SOA qui se terminent dans la tourmente, sans parvenir à leurs fins.

SOA furtive : faire la SOA sans le métier

La tentation peut devenir forte, coté DSI, de mettre en place une SOA sans faire participer le métier au projet, voire sans même les informer de la démarche : dans de nombreuses entreprises, la discussion entre les métiers et une informatique décrédibilisée et considérée comme coûteuse, est devenue difficile.

Dans la réalité la définition d’une stratégie et la mise en place de cette transition. Tout d’abord, un des objectifs majeurs de la SOA est l’alignement du SI sur le métier. L’absence de dialogue rend impossible toute transformation architecturale prenant réellement en compte les attentes concrètes et les jalons du métier.

Ensuite, la SOA implique la mise en place d’une infrastructure, d’outillages et de services partagés et transverses à l’entreprise. Le financement de leur mise en place et surtout celui de leur maintenance en vie courante sont incompatibles avec des modes des fonctionnements et l’allocation de budget basés sur les projets.

Le métier doit donc être impliqué très tôt dans toute initiative SOA, sur les aspects métier, afin de définir une architecture et un plan de mise en œuvre permettant l’alignement du système d’information et le financement des actions à entreprendre.

Simplisme : Une architecture SOA, c’est simple et facile

Les concepts d’une SOA sont simples à comprendre et l’arrivée à maturité des solutions logicielles supportant ce type d’architecture, fait apparaître la mise en œuvre comme tout aussi simple à qui n’y prend pas garde. Mais ignorer la complexité de la SOA coûtera cher en temps et en budget.

Pour bien évaluer l’effort à fournir, l’utilisation d’un modèle de maturité SOA recensant les champs à couvrir et définissant des repères d’avancement sur chacun des axes est une solution  Il permet d’obtenir une vision d’ensemble des impacts de la SOA sur l’entreprise et des sujets à traiter tant dans l’immédiat que dans l’avenir.

Prolifération de services

Pourquoi ne pas demander aux nouveaux projets d’appliquer une politique « tout service » ? Il paraîtrait aisé de favoriser à postériori la réutilisation des services existants et d’arbitrer entre les éventuels services dupliqués ? Parce que la réutilisabilité ne coule pas de source. Par exemple, le manque de supervision des projets a mené certaines entreprises à constater la mise en production de 6 à 10 services identiques… à quelques différences près. Ainsi le manque d’harmonisation, de normalisation et de communication en amont des projets peut détruire ce qui fait la force d’une SOA : ses services standardisés, et réutilisables.

Dès lors mieux vaut gérer rigoureusement dès le départ le portefeuille de services que de devoir le remettre à plat plus tard.

Connaître les concepts SOA vaut mieux que connaître l’entreprise

Appliquer la méthodologie SOA pour démultiplier la puissance et l’efficacité de son SI est un vœu pieux. En effet, sans un contexte parfaitement maîtriser pour appréhender les enjeux métiers et organisationnel d’un tel changement, le projet ne pourra pas voir le jour. Ainsi il est primordiale de former des équipes projets avec des compétences transverses, spécialisée tant dans la démarche SOA que dans la compréhension des usages des métiers de l’entreprise.

Absence d’orientation processus : ne voir l’entreprise que par ce qu’elle produit

Une entreprise peut être observée au travers d’une vue « produit », c’est à dire de manière focalisée sur les biens et services qu’elle génère. Ce type de vision correspond aux organisations en silos et conduit à une architecture SI qui reflète ce type de structure… avec tous ses inconvénients, dont le principal : des objectifs distincts selon les services de l’entreprise. En effet dans le cadre de la SOA, cela représenterait une architecture où chaque application cherche à recevoir les données qui lui sont utile mais refuse de développer les interfaces nécessaires à exposer les données utiles pour les applications d’autres services.

La SOA considère au travers des services les capacités fondamentales de l’entreprise, ce qu’elle fait réellement. Pour identifier ces capacités, une connaissance approfondie du fonctionnement de l’entreprise, c’est-à-dire de ses processus, est indispensable.

Ainsi la démarche SOA se calque sur le fonctionnement réel de l’entreprise et non sur la manière dont elle est organisée, ce qui suppose une approche orientée processus.

Amélioration des standards : gagner du temps avec une petite modification

Un des piliers de SOA est l’utilisation de standards, qu’ils soient des normes mondiales tels les Web Services ou des standards utilisés au sein d’une entreprise. Ils sont à la fois une commodité et une contrainte – car ils donnent un cadre structurant. En cédant à la facilité, par exemple en contournant, dans un cas bien précis par un petit développement non conforme, le standard devient spécifique. Cela  peut suffire à complexifier la maintenance et induire des coûts supplémentaires.

Il est nécessaire de faire preuve de rigueur dans l’application des standards et de mettre en place les contrôles de conformité nécessaires.

Le Tout SOA : tout migrer vers la SOA

Les architectures orientées services présentent de nombreux avantages parmi lesquels la flexibilité et la réactivité. Il est tentant de remplacer tout le vieux système par du neuf. Cela n’est bien entendu ni possible ni souhaitable.

Avoir la vision d’un monde « tout SOA » permet de montrer ce qui peut être atteint par l’entreprise.

En fonction de l’effort organisationnel et technique à fournir pour migrer un sous-système donné, il est possible de déterminer si un besoin, un enjeu existe réellement. Aucun business case ne justifiera la refonte de deux systèmes qui ne communiquent qu’entre eux simplement pour les orienter “service”. Comme dans tout projet, la pertinence fonctionnelle doit être démontrée.

SOA sans gestion d’un référentiel de données de base

Enfin une architecture SOA permet de remplacer les échanges point-à-point par une plateforme intégrée pour accéder de façon générique aux informations clients, produits, prix, …, mais si aucun effort n’est fait pour uniformiser les modèles sémantiques des données dans les applications, l’hétérogénéité subsiste au niveaux des données et les informations remontées par ces services ne sont pas cohérentes. Le bénéfice des services génériques n’est alors plus aussi flagrant. Voilà pourquoi une démarche de gestion unifiée des données se justifie, voir est indispensable pour un projet SOA.

---

 

La SOA […] permet l’éclosion d’un SI réellement flexible, capable de rester au plus proche des besoins métiers

 

L’avènement du Cloud Computing a permis de mettre à disposition des DSI des services informatiques performants et innovants. L’intégration de l’architecture SOA dans les SI existants permet de tirer le meilleurs de la flexibilité et de la performance apportée par le Cloud Computing, tout en rapprochant le SI des directions métiers.

La synthèse de ces outils permet l’éclosion d’un SI réellement flexible, capable de rester au plus proche des besoins métiers, et en apportant une performance de long-terme à l’organisation, au prix cependant d’un effort de transformation structurelle relativement complexe.