Il est extremement difficile de faire une réponse générique dans ce domaine.  Avant d'aller plus loin, il faudra d'abord préciser de quoi on parle :

• Quelle type d'institution financière? Banque de Détail? Investissements?


• Quelle est la stratégie de l'entreprise?


• Comment est organisé le FO actuellement?


• Quel sont les processus impactés?


• Quel type d'application Front Office est envisagé?


• Quels sont les raisons de cette mise en oeuvre?


• ...

Pour démarer, recherchez dans la presse professionnelle (01, ZDNET ) des cas clients dans ce domaine., sur les sites Web des vendeurs d'applications foinancières.   Ensuite sur un scénario identique, la démarche de d'évalaution peut commencer

Bon courage

 

Ce sont deux notions différentes et complémentaires.



Le Référentiel SOA est la base de données de référence des services SOA dans laquelle sont listés toutes les entités SOA  et leur liens :

- Liste des Services avec leurs clients, dépendances et contrat

- Liste des processus métiers avec leurs dépendances

De plus le référentiel gère le cycle de vie (depuis la phase de design jusqu'à la phase d'exécution) de ces services.

Le référentiel contient toutes les informations pertinentes sur les services SOA (et pas seulement services Web) et leur cycle de vie.



Par contre, l'annuaire UDDI (registre - registry) est utilisé de manière dynamique pour localiser les services Web :

- Les pages blanches comprennent la liste des entreprises ainsi que des informations associées à ces dernières.

- Les pages jaunes recensent les services Web de chacune des entreprises sous le standard WSDL.

- Les pages vertes fournissent des informations techniques précises sur les services fournis.

Il existe de nombreuses expériences de refontes d'applicatifs anciens dans le cadre d'une architectrue SOA.

Avant de se lancer dans cette démarche, il faut bien analyser le patrimoineet évaluer les contraintes techniques

• l'application sépare-t'elle la logique métier de l'interface utilisateur de l'accès aux données?


• Y a'il des outils disponibles sur la plateforme (support XML, Web Services, ...)


• L'application peut elle supporter un modèle de communication asynchrone?


• Y a t'il des traitements par lots, des transactions?

et les contraintes métiers (coûts, risque, réglementation)

Il fautensuite analyser les actifs patrimoniaux pertinents et en déduire la stratégie d'évolution :

• Conservation de l'applicatif sans modification : il a un usage limité et isolé


• Intégration de l'applicatif : il est stable et efficace ou extrementent complexe 


• Migration de l'applicatif . Il ne répond plus aux besoins, coûte trop cher, son éditeur a disparu, les compétences ne sont pas disponible


• Discontinuation de l'applicatif : il est redondant, plus nécessaire

Il existe 3 stratégies possibles d'intégration :

• Intégration au niveau de l'interface utilisateur (refonte html, ASP, JSP ) RIA ou Mashup


• INtégration au niuveau de la logique métier (transformation en service Web)


• Intégration au niveau de l'accès aux données

Enfin, des éditeurs publient sur leur site des références de modernisation d'applications clients. Par exemple :

• IBM 


• SOftware AG

On peut répondre à cette question en prenant deux points de vue différents :
Du point de vue des directions métiers, agilité, adaptation, flexibilité sont des impératifs
- D'abord, flexibilité et adaptation aux changements sont demandées par les entreprises. Dans le contexte économique auquel les entreprises sont confrontées, elles doivent innover sans cesse et développer de nouveaux produits et services pour rester compétitives.
- Les processus, les transactions doivent être adaptés pour répondre aux nouveaux défis qui apparaissent.
- Les nouvelles réglementations de plus en plus contraignantes doivent être respectées impérativement, en respectant une date-butoir.
- Dans ce monde de consolidation et de fusions et d'acquisitions il faut intégrer les équipes, processus, informations des deux entreprises pour pouvoir générer le plus rapidement possible la valeur ajoutée de la fusion.
- Et enfin, afin de limiter les dépenses « non productives, les entreprises se concentrer sur leur expertise dans leur cœur de marché. L’externalisation des processus non critiques est vue comme un moyen de réduire les coûts. Aujourd’hui, de nombreuses entreprises externalisent la paye, une partie de l’informatique, la gestion du processus de livraison.
Tous ces impératifs vont se traduire par une demande d’agilité, de flexibilité des systèmes d’information.

On peut aussi regarder le point de vue de la direction des systèmes d’information. Aujourd’hui, la DSI est devant le défi de permettre l’innovation en limitant les investissements et assurant un contrôle des coûts stricte.
- Pour cela, elle doit promouvoir la réutilisation des actifs existants, les systèmes centraux, les applications legacy, les applications transactionnelles.
- Cependant, tous ces investissements informatiques n’avaient pas été conçus pour supporter les changements et s'intégrer facilement les uns avec les autres.
- Les projets d'informatiques doivent montrer un retour sur investissement rapide et mesurable, non seulement sur l'aspect informatique mais aussi démontrer leur valeur métier
- Enfin, l'informatique doit aussi assurer ses capacités traditionnelles, c'est-à-dire limiter le risque opérationnel, garantir la sécurité, préserver la pérennité des données, etc.…

Dans ce contexte, l’architecture orientée service montre toute sa valeur :
Réutilisation, à base de composant, abstraction de l’infrastructure, couplage lâche sont autant d’attributs qui apportent flexibilité, agilité, adaptation aux changements aux systèmes et applications supportant les processus des directions métier.

Entre l'informatique et les métiers il y a un gap culturel important.
Les utilisateurs vont être focalisés sur leurs objectifs « vendre leur produits et services, leur proposition de valeur » et sur les coûts.
Les directions métiers vont tenter d’optimiser l'organisation pour améliorer l’efficacité, la productivité, la flexibilité.
L'informatique de son côté va se focaliser sur la gestion des projets, l'architecture d'entreprise, les standards tintèrent opérabilité, les infrastructures.

Il est clair que les préoccupations des uns sont différentes de celles des autres. Les équipes n’ont pas la même compréhension de la problématique métier. Elles n’ont pas la même compréhension des opportunités d’affaires. Les langages métiers et informatiques sont différents. Les utilisateurs pensent que l’informatique n’est pas en ligne avec leurs préoccupations. De même les informaticiens pensent que les utilisateurs ne comprennent pas les impacts à long terme de leur métier.

Et la question est comment faire pour que ces équipes collaborent avec la même vision de la stratégie et sur des objectifs partagés.
SOA apporte une réponse à ce besoin d’alignement en facilitant le travail en commun des métiers et de l’informatique. En réduisant les délais de production des applications, en mettant en œuvre des méthodes agiles de développement qui imposent une forte collaboration entre les parties, en permettant aux utilisateurs de s’exprimer dans leur vocabulaire, en facilitant les mécanismes de discussions, SOA permet de réduire le gap culturel entre les deux mondes.

SOA signifie Architecture Orientée Service mais aussi Approche Orientée Service.
Ce concept, issue du monde de l’informatique, a reçu un accueil mitigé de la part des métiers. « Encore un truc de l’informatique qui va disparaître très vite »
Pourtant, une vision orienté service a de réels avantages pour les entreprises.
- Du côté des métiers, l'approche orientée services permet d'innover dans les modèles et les processus de l'organisation, permet de capitaliser sur l'ensemble des informations disponibles, permet d'optimiser la collaboration interne entre les différents participants des processus mais aussi la collaboration externe, l'organisation et ses partenaires, l'organisation et ses fournisseurs, l'organisation et ses clients.
- Du côté de la direction informatique, les mots-clés de l'architecture orientée services sont : réutilisation, couplage lâche, découverte, abstraction, composition. Le paradigme du logiciel évolue pour ressembler à celui du matériel. SOA permet la composition d'applications : au lieu de développer ou d'acheter une suite applicative complète, les entreprises peuvent assembler des composants, des services pour supporter des processus métier de bout en bout. Comme le constructeur informatique assemble des composants standards pour construire un PC, le « constructeur » d'applications va créer des applications à partir d'assemblage de composants, les uns développés en interne, les autres obtenus auprès du fournisseur d’application intégrée traditionnel, et enfin des composants découverts sur Web.

Un autre aspect important de SOA est sa possibilité d'abstraction. Le monde des applications client/serveur avait permit de réaliser une couche d'abstraction sur le matériel. La portabilité des applications, le déport de quelques fonctions sur les postes clients, permettaient de focaliser simplement sur le logiciel, le code sans s’occuper des contraintes du matériel. Aujourd'hui avec le réseau, le Web et les architectures SOA, nous avons une nouvelle couche d'abstraction qui permet de s'affranchir non seulement du matériel mais aussi du logiciel. SOA, basée sur les technologies du Web, présente les mêmes avantages. Quand vous accédez et à une ressource à travers votre navigateur, vous ignorerez non seulement l'infrastructure matérielle, support de cette ressource (quelle machine, quel réseaux,…) mais aussi l'infrastructure logicielle nécessaire à la ressource (le système d'exploitation, les outils de middleware utilisés, le langage de programmation).

L’entreprise est confrontée à un certain nombre de contraintes externes. Le marché est de plus en plus mondialisé et compétitif. De concurrents situés dans des pays où la main-d’œuvre est pas chère peuvent venir concurrencer sur le marché local nos entreprises. Les fusions et acquisitions deviennent de plus en plus nombreuses. La réglementation enfin doit être respectée.
Dans ce contexte les mots-clés de l'entreprise deviennent vitesse, innovation et consolidation. Il faut offrir des réponses appropriées à ce marché mondialisé, à ces réglementations de plus en plus contraignantes et à ce besoin de consolidation illustré par les nombreuses fusions-acquisitions de ces dernières semaines.

Dans ce contexte, la pression sur la direction informatique est importante. Pourtant, les budgets alloués à l'informatique ne sont pas extensibles. Toutes les études montrent que ces dernières années, les directions générales ont eu tendance à réduire ou tout au moins limiter le budget alloué à l’informatique.

Dans ce budget au mieux constant, une grande partie est déjà réservée pour les opérations et la maintenance.

Il ne reste que 30 % au maximum alloué pour supporter l'innovation, c'est-à-dire les nouveaux développements, les nouvelles demandes des utilisateurs.

Pour réduire les coûts des opérations (Run the business, comme disent les américains) et augmenter la capacité d’innovation, il faut donc industrialiser l’informatique.

Et SOA est certainement un moyen d'industrialisation. Par ses capacités d'assemblage, SOA réduit les coûts de développement. Par ses capacités d'abstraction, SOA permet de capitaliser sur l'existant : les applications legacy et les données. En définissant des services, SOA augmente la réutilisation et par-delà la productivité des équipes.

La définition de SOA dépend du point de vue de celui qui la définit :
- Pour l’analyste métiers :
SOA est un ensemble de services que les métiers et désirent exposer à leurs clients, partenaire et collègue de l'entreprise
- Pour l'architecte :
SOA est un style architectures basé sur des fournisseurs et des consommateurs de services. Elle sera apporte des caractéristiques de modularité, encapsulation, couplage lâche, réutilisation et composition.
- Pour le développeur :
SOA est un modèle de programmation basée sur des standards, des outils et des technologies issues du Web.
- Pour l'intégrateur :
SOA est une solution optimisée pour l'assemblage, orchestration, la surveillance et la gestion des services.

En fait, chaque acteur qu'il soit éditeur de logiciels, intégrateur, analyste, consultant, … a sa propre définition de SOA, qui peut aussi mettre en valeur sa propre offre logicielle ou de service.

Donc, on peut donner ici une définition objective et non biaisée, sans arrière pensée mercantile, c’est celle de l'organisme de standardisation OASIS :
« L’architecture orientée services est un paradigme d'organisation et d'utilisation de capacités distribuées qui peuvent être sous le contrôle de différents propriétaires de domaines. »

Pour faire une analogie, on peut comparer les principes de l'approche orientée services avec le concept de la prise électrique.
D’un côté les consommateurs. Ils vont brancher la fiche électrique de leur matériel dans une prise et obtenir un service : du courant de 120 Volts 60 hertz. Tous les jours, vous utilisez de l’électricité. Là ou cela devient intéressant, c’est que vous ignorez, comme moi, tout ce qui se passe derrière la prise électrique. Les fils tirés dans la maison jusqu’à la prise, l’infrastructure nécessaire pour amener le courant de la centrale au domicile, l’origine même de cette électricité, elle peut provenir d’une centrale nucléaire, une centrale à charbon ou une éolienne. La centrale peut être située à des centaines de kilomètres du domicile, éventuellement à l’étranger.
Du prévu du producteur c'est la même magie. Celui-ci ignore complètement le type de d’appareil qui utilise son service. C’est peut-être votre ordinateur, votre téléphone portable, une radio, un lave-linge ou tout autre appareil consommant de l'électricité.

Le seul point commun entre le consommateur et le producteur est la fiche et la prise électrique. Interface normalisée entre la consommation et la production, c’est elle qui fait le lien et qui permet l'utilisation du service « Electricité 120V 60Hrtz ».
L'approche orientée service utilise ce même principe. Elle sépare complètement la consommation de la production. Seule l'interface du service est connue du consommateur. Un contrat de service est défini entre le producteur et le consommateur qui permet de garantir les termes de l’utilisation.

Sur cette interface simple, si le service offert n’est pas suffisant, on peut rajouter un adaptateur pour offrir des fonctions additionnelles de la même manière que sur une prise electrique on peut ajouter un variateur.

SOA est une architecture d'intégration avec les caractéristiques suivantes :
- C'est une architecture interopérable : cela veut dire qu'elle n'est pas liée avec une plate-forme particulière
- C'est une architecture en réseau : elle permet de se connecter à la voler grâce à des intermédiaires
- C'est une architecture fédérée : elle permet de dépasser les frontières technologiques administratives de sécurité et au-delà les frontières de l'entreprise.
- C'est une architecture simple : seuls la définition commune entre les producteurs et les consommateurs et définis.
- C'est une architecture standardisée. Les définies par les standards ouverts de l'industrie.
- C'est une architecture extensible. Elle s'adapte et s'adaptera facilement et dynamiquement à de nouvelles implémentations à de nouvelles technologies.