Posts Tagged 'urbanisation'

SOA ne s'achète pas, SOA se construit

Voici le contenu d’une interview que j’ai donnée au site Silicon.fr sur SOA.

Dans quels contextes SOA incarne-t-elle une démarche pertinente ?

Globalement, je citerai trois raisons qui présentent un intérêt évident pour une approche SOA. En dehors de ces trois situations, l’entreprise peut se passer de la démarche SOA.

  • Première motivation : apporter de l’agilité aux processus métier. Dans certains secteurs (finance, services…), ces processus évoluent fortement. Or, s’ils sont “codés en dur” dans les programmes, la rigidité freine fortement l’agilité du système d’information qui ne peut s’adapter souplement pour répondre aux besoins évolutifs de l’entreprise. Avec une architecture SOA, les processus sont décomposés en briques élémentaires appelées services. Cela favorise les évolutions sans remettre en cause l’ensemble du schéma applicatif. Par exemple, une banque propose des services bancaires en marque blanche à d’autres acteurs. Or, chacun souhaite disposer de sa propre variante de processus tels que la souscription de crédit (traitement spécifique en cas de refus, limiter les étapes de validation…). En mode SOA, soit le processus présente une souplesse suffisante, soit la banque peut mettre en place des variantes d’un même processus pour un coût très raisonnable.
  • Seconde situation favorable dans laquelle le SOA apporte une solution efficace : l’interopérabilité. Une caractéristique critique pour une entreprise nécessitant de forts échanges entre les briques de son système information, entre ses applications décloisonnées, ou pour communiquer avec les applications de ses partenaires, fournisseuse ou clients. C’est ce que j’appelle la “SOA de surface” : on ne sait pas forcément ce qui se trouve dans l’application, mais on déploie les interfaces nécessaires à la communication (e.g. Services Web). Ainsi, un groupe de transport dont les processus restent identiques doit pourtant se conformer à de nouvelles règlementations. Il ne modifie pas les processus applicatifs, mais uniquement l’interface des échanges.
  • Troisième cas, moins fréquent que les deux autres : la rationalisation du SI. L’objectif consiste à réduire les occurrences multiples d’informations et d’applications ou fonctions. Il s’agit alors de travailler sur la qualité des données et des services applicatifs (MDM et autres outils de ce type). Si ce travail permet de réduire les coûts à moyen terme, on ne vise pas le retour sur investissement rapide, mais plutôt la cohérence du SI.

Quels éléments ou infrastructures favorisent l’élaboration d’une approche SOA ?

L’infrastructure ou les logiciels ne sont pas l’essentiel de la démarche, et les questions à leur sujet ne devraient pas se poser au départ. SOA est une philosophie de construction du SI sous forme de briques élémentaires et réutilisables. Or, cette notion de réutilisabilité provient de la qualité de l’interface et passe forcément par des formats pivots (description par message d’un processus métier, qui sera véhiculé lors des appels de services). L’intérêt consiste à mettre sur pied un vocabulaire commun à toute l’entreprise et à détecter les différences. Par exemple, la notion de “client” est différente selon les services, mais certains attributs sont communs. Alors, autant utiliser ce “plus petit dénominateur commun” de façon unique et le stocker dans un référentiel. Ainsi, en cas de modification et d’évolution, l’impact sera moindre et la maintenance des données largement simplifiée. Au final, une meilleure cohérence du SI et une productivité en hausse des informaticiens. On comprend alors pourquoi le référentiel est propre à chaque entreprise, à sa culture et ses métiers, et peut difficilement être vendu “prêt à l’emploi”.

En quoi l’architecture SOA diffère-t-elle de l’architecture applicative classique ?

Dans une architecture traditionnelle, on distingue trois couches : la couche utilisateur (avec le poste de travail et les interfaces homme-machine), les traitements et les données. Avec SOA, les traitements métiers sont séparés en Services élémentaires et en Services d’orchestration. Les premiers sont les briques de base que les seconds viennent compléter pour permettre la communication et les échanges.

À quel moment et où les logiciels peuvent-ils faciliter la démarche ?

Dans les solutions des éditeurs, la couche la plus stratégique reste le transport avec des logiciels comme MQ Series d’IBM ou JMS Sonic MQ de Progress, entre autres. En outre, lorsque les services se multiplient et se comptent par centaines, des suites logicielles deviennent indispensables pour comprendre ce qui se passe et orchestrer l’ensemble. Elles permettent d’industrialiser les tâches. De même, l’entreprise devra en déployer une pour assurer une ouverture contrôlée de ses applications dans des flux B2B. Cependant, SOA ne s’achète pas, mais se construit ! Signer un chèque à un éditeur ne sert à rien au départ du projet. Bien qu’il faille planifier cet investissement pour la suite.

Cas d’utilisation d’un ESB

Dans la vision standard d’une architecture SOA, on retrouve toujours un certain nombre d’éléments communs : des services, des clients ou consommateurs de ces services, un annuaire/registre de services, et une infrastructure technique, l’ESB, utilisée comme couche de médiation entre les fournisseurs et les consommateurs de services.

Lors de nos missions chez SQLI Consulting, nous avons identifié quatre grands cas d’utilisation d’un ESB à différents niveaux de l’entreprise.

1) Usage intra applicatif

C’est un cas d’usage limité, presque toujours implémenté avec un ESB Open Source, léger et simple à mettre en œuvre.
On le retrouve dans des applications ayant un fort besoin d’agilité, qui justifie le surcoût en performance que provoque le passage par un ESB, ou dans des applications proposant une interface multi protocoles (pour des progiciels en marque blanche par exemple) ; le module consommateur de service se trouve alors dans une autre application / système.

2) Usage tactique

L’utilisation tactique correspond à un ESB utilisé au sein d’une entité / département afin de mettre à disposition pour l’ensemble de l’entité des services réutilisables.

Les services exposés peuvent être issus :

  • De nouvelles applications reposant une sur une architecture SOA interne (exposition des services via les standards actuels)
  • D’applications existantes dont une partie du code applicatif est réutilisé pour exposer des services (exposition des services via les standards actuels)
  • De systèmes légataires, tels que les mainframes ou AS400 (exposition de services grâce à des connecteurs spécifiques)

3) Usage stratégique

La vision stratégique correspond à l’utilisation de l’ESB pour établir une communication entre les silos, dans le but d’exposer des services utilisés par des processus métier transverses. Comme pour la vision tactique, les services peuvent être issus de diverses sources, voir même de l’ESB tactique qui peut exister dans chacun des silos.

4) Communication externe

Dans ce cas d’usage, l’ESB est destiné à exposer des services pour une utilisation externe à l’entreprise

Dans ce genre d’utilisation, les aspects de sécurité doivent être l’objet d’une attention particulière. Pour cette raison, il est d’usage de ne pas utiliser un ESB interne (tactique ou stratégique), mais de dédier un ESB pour les communications avec l’extérieur. Un ESB pour la communication externe sera généralement placé dans une DMZ.

Il est à noter que les échanges inter SI se font généralement par l’intermédiaire de web services (sécurisés), et que les besoins en connectivité sont donc souvent plus limités. Ces différents cas d’utilisation se combinent dans les entreprises au fil des implémentations SOA plus ou moins stratégiques à différents niveaux du système d’information.

Les ESB en entreprise, où en est-on actuellement ?
Au travers de nos missions, nous remarquons que les deux usages majoritaires des ESB sont :

  • l’ESB départemental afin de faire communiquer différentes applications appartenant à un ou deux ensemble fonctionnel
    Même si ces projets font parfois communiquer deux silos, il n’est pas possible de les considérer comme des projets d’ESB stratégique, qui est une réflexion globale sur la communication au sein de l’ensemble du SI, et dont l’objectif est l’implémentation de bout en bout des processus métiers de l’entreprise.
  • l’ESB pour l’extérieur afin d’offrir des services aux clients/partenaires de l’entreprise.

L’usage intra applicatif ne se justifie que dans de rares cas, lorsque l’agilité de l’application est considérée comme plus importante que ses performances.
Enfin le cas de l’ESB stratégique, transverse à l’entreprise reste encore limité, principalement par le fait que la plupart des systèmes d’information n’ont pas la maturité requise pour faire émerger des services dans l’ensemble de l’entreprise.

Je pense personnellement que l’un des principaux enjeux est maintenant l’interconnexion de ces différents ESB mis en place au cours de l’évolution du SI souvent sans se préoccuper de la vision globale du SI, nécessaire à l’alignement du SI sur le métier.

Conférence Sustainable IT Architecture

Le 31 janvier se sont déroulées les assises des systèmes d’information durables, organisées par Pierre Bonnet (le fondateur de la communauté « Sustainable IT Architecture »). Cette journée a été le moment de revenir sur les architectures orientées services (SOA), avec un discours mature et centré sur les problématiques rencontrées. Quelques grands retours d’expérience ont été présentés durant la journée mais le premier constat est qu’il reste néanmoins beaucoup de chose à défricher, surtout du coté des méthodologies; ce que les communautés Praxime (poussant la méthodologie Praxème) et Sustainable IT souhaitent résoudre à terme.

Sustainable IT est une communauté qui promet de prendre beaucoup d’importance vu le nombre de participants (plus de 250 personnes, sans compter ceux qui n’ont pu venir faute de place); des auditeurs qui venaient de tous les domaines de l’informatique (Service, Editeur, DSI) et de sociétés de toutes tailles (Sun, BNP Paribas, …). Du côté des intervenants, le séminaire était animé par trois types de profil, chacun avec leurs discours propres :

  • les DSI expliquant leur démarche SOA en interne et les changements sur les habitudes de travail,
  • les éditeurs de logiciel, amenant une démarche outillée pour assurer une meilleur agilité des applicatifs,
  • les intégrateurs, avec un discours beaucoup plus centré sur les impacts applicatifs et la réalité projet.

Un des messages forts passés à l’intention des DSI est la besoin de mobilisation des ressources pour arriver à bon port, car la route SOA est certe très intéressante mais pavée d’embuches. Le SOA se justifie par un effort de revue interne pour changer en profondeur les SI, afin de les rendre plus réactifs et plus maléables. A l’arrivée, le SI ne sera plus perçu comme une source de coût et de rigidité pour le business, et pourra fournir des vraies métriques indicateurs de l’impact sur la stratégie d’entreprise.

Mes impressions après cette journée sont les suivantes :

  • Des intervenants de différentes qualités mais souvent au dessus de la moyenne, particulièrement du coté des DSI et des quelques éditeurs qui ont su mener une longue refléxion autour des SI et de certains principes qui ont fait ou sont en train de faire leurs preuves,
  • Le partage de vrais retours d’expérience sur les succès mais aussi les échecs de la démarche ont été très enrichissants, et ont révélé le travail effectué autour des démarches SOA et de l’organisation,
  • La présentation d’une suite logicielle (ACMS) assurée par la mise en place d’outils complémentaires découpée par préoccupation semble assez intéressant. Ces produits offrent un regard assez neuf sur la conception des applications et proposent une flexibilité et une articulation là où le métier en aurait le plus besoin, i.e. selon eux, au niveau de la gestion des données maitres (données transverses à toute l’entreprise), au niveau des processus et aussi au niveau des règles métier.

J’ai aussi noté quelques idées intéressantes que je vais vous résumer en quelques mots. Tout d’abord, le SOA doit être mené comme un projet de « refonte », c’est à dire qu’il faudra changer profondément l’architecture des applications, la maintenance opérationnelle des services et par conséquent l’organisation. Evidemment pour réussir cette refonte, elle ne doit pas être réalisée avec d’un seul bloc en raison de l’effet tunnel qui s’avère souvent mortel pour les projets de refonte du SI. Ici, la refonte doit être menée de manière incrémentale, et en trois étapes :

  • le SOA esthétique ou SOA de surface,
  • le SOA étendu,
  • le SOA de refonte.

Ces trois étapes sont sensées améliorer graduellement la nouvelle démarche de conception des applications, avec des quick win internes justifiant sa continuation. Cet effet graduel va pouvoir laisser aux participants le temps d’intégrer l’apprentissage de nouveaux langages, la capitalisation des méthodes de conceptions, et d’évaluation projet.

Un autre concept discuté dans la journée est celui des variantes, c’est-à-dire le fait qu’au même moment on peut avoir besoin « d’un même applicatif pour des prises de décision dans des contextes différents ». Ces variantes ou règles de variation doivent être sorties du code pour ne pas figer et mélanger ces règles sensibles dans un embroglio de code. C’est dans ce contexte que la plateforme ACMS, souhaite intervenir en amenant des concept assez novateurs et qui offrent une réponse d’agilité à trois niveaux : données, processus et règles métier. Ainsi l’introduction d’un BRMS (moteur de règles) semble sortir des couples classiques de « services \ processus » (avec un BPM évidemment), cependant l’intégration et l’interopérabilité transparente entre les différents outils d’agilité me laisse encore un peu perplexe.

Néanmoins, je pense que ce sont des bons produits en soi et il faudra suivre de près la plateforme ACMS, qui pourrait constituer à terme une base sur lesquels articuler les applicatifs et peut-être même le SI dans sa globalité, qui sait ?

Ainsi pour conclure, les concepts forts de la journée étaient :

  • L’approche SOA entraine une Refonte du SI (organisation, architecture, démarches et procédures de dévelopement applicatif), et donc un vrai changement des habitudes !
  • L’introduction de l’agilité avec la plateforme ACMS,
  • La présentation d’une démarche centrée sur la méthode et l’impact culturel dans les entreprises.

Pour en savoir plus n’hésitez pas à vous inscrire dans les communautés Praxime et Sustainable IT :

Il n'y aura pas de SI purement SOA

Vous trouverez ci-dessous la transcription d’une interview réalisée pour 01 DSI et publiée dans le numéro du 18 janvier de 01 Informatique.
La version complète en PDF de cette interview est aussi disponible ici.

01DSI : SOA a été l’un des thèmes récurrents de l’année 2007. Sa réalité dans les entreprises est pourtant beaucoup plus modeste. Comment expliquer cette différence ?

Aujourd’hui, les barrières technologiques sont tombées. HTTP, XML, IP… Toutes ces technologies nous permettent d’envisager des architectures orientées services. Reste que pour faire collaborer deux services, il faut qu’ils s’échangent des paramètres, qu’ils aient un langage, un référentiel communs. Et là, on tombe dans la problématique classique de l’urbanisation du SI. Qu’est-ce qui est dans le référentiel ? Qu’est-ce qui n’y est pas ? Qui est propriétaire des données? Bref, envisager un SI complètement SOA implique de passer au crible l’ensemble des processus et des données de l’entreprise. La tâche est immense, voire impossible d’un point de vue pratique. Du coup, aujourd’hui, les projets SOA qui avancent sont de petits projets ou, au moins, des projets à périmètre restreint, de type éditique ou CRM, par exemple. Avec ce type de projets, l’ambition est mesurée mais le risque maîtrisé, car on ne propage pas les problématiques d’une application à une autre.

01DSI : L’urbanisation est donc directement mise en cause… Que font les urbanistes alors ?

Rapprochons le rôle de l’urbaniste de celui de l’architecte. Comme dans la « vraie vie », l’urbaniste s’occupe du cadre dans lequel l’architecte va construire ses applications. L’architecte s’occupe de l’intérêt du projet, l’urbaniste de l’intérêt général. Or, en France, l’expérience montre que les urbanistes en sont encore souvent à cartographier le système, pas à édicter les règles d’évolution du SI en fonction d’une vision métier stratégique.

01DSI : Il n’y a pas d’issue alors ?

Si, bien sûr, mais je ne pense pas que l’on voie un jour des SI purement SOA. En matière d’urbanisation, il y a deux approches. L’une, plus française, est l’approche top-down. Elle est excellente d’un point de vue théorique mais ses bénéfices en termes de ROI ne sont perceptibles qu’à long terme, ce qui revient à dire qu’elle est difficile à faire passer auprès des directions financières. La seconde, plus anglo-saxonne, de type bottom-up , est plus risquée à terme mais bénéficie d’un ROI plus rapide. En fait l’approche topdown est un piège si on la pense au niveau global. Le SI est stratifié, historique. pratiquement, le top-down ne peut s’appliquer qu’à un niveau local. Il faut donc arbitrer entre les deux approches. Et cet arbitrage est particulièrement complexe.

01DSI : Malgré ces freins, l’arrivée de SOA, mais aussi, les offres SaaS, les services Web, marque-t-elle la fin des progiciels ?

Certainement pas. Mais ils vont devoir évoluer et le processus est d’ailleurs déjà engagé. Les éditeurs vont devoir donner accès à leurs briques élémentaires. Les boîtes noires qu’ils étaient doivent se transformer en boîtes blanches. C’est d’ailleurs l’une des clés du succès de SOA.

01DSI : Une bonne nouvelle quand même sur le front du SOA ?

Oui, sans doute. La complexité des SI augmente parce que les métiers sont toujours plus exigeants. SOA ne réduit pas cette complexité mais accroît l’agilité du SI vis-à-vis de ces demandes croissantes. Du coup, la bonne nouvelle, c’est que les informaticiens ont du travail pour longtemps…


Mises à jour Twitter

Entrer votre adresse e-mail pour vous inscrire a ce blog et recevoir les notifications des nouveaux articles par e-mail.

Rejoignez 29 autres abonnés

Catégories

Statistiques

  • 64,074 hits