Méthodologie SOA en six domaines - Révéler les avantages métiers d'une Architecture Orientée Services

 
Méthodologie SOA en six domaines - Révéler les avantages métiers d'une Architecture Orientée Services
Livre Blanc BEA

Méthodologie SOA en
six domaines
Révéler les avantages métiers
d’une Architecture Orientée Services
Copyright
Copyright © 2005 BEA Systems, Inc. Tous droits réservés.
Avril 2005

UTILISATION, REPRODUCTION, GARANTIE
Le présent document ne peut être photocopié, reproduit, traduit ni résumé, en tout ou partie, par quelque moyen que
ce soit (électronique ou traditionnel), sans autorisation écrite préalable de BEA Systems, Inc. Les informations
contenues dans cette étude sont modifiables sans préavis et ne constituent en aucun cas un engagement de BEA
Systems, Inc.

MARQUES
BEA, Built on BEA, Jolt, Joltbeans, Steelthread, Top End, Tuxedo, WebLogic et BEA WebLogic Server sont des mar-
ques déposées de BEA Systems, Inc. BEA dev2dev Subscriptions, BEA eLink, BEA Liquid Data for WebLogic, BEA
MessageQ, BEA WebLogic Enterprise Platform, BEA WebLogic Enterprise Security, BEA WebLogic Express, BEA
WebLogic Integration, BEA WebLogic Java Adapter for Mainframe, BEA WebLogic JDriver, BEA WebLogic Log
Central, BEA WebLogic Platform, BEA WebLogic Portal, BEA JRockit, BEA WebLogic WorkGroup Edition et BEA
WebLogic Workshop sont des marques de BEA Systems, Inc. BEA Mission Critical Support est une marque de serv-
ice de BEA Systems, Inc. Tous les autres noms de sociétés ou de produits sont potentiellement soumis à des droits
de propriété détenus par des tiers.

CWP0965E0705-1A
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

SOMMAIRE
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
      Six domaines répondant à des challenges spécifiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Stratégie métier et processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
      Programme SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
      Optimisation des processus métiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
      Orientation service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
      Standardisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
      Orientation entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
      Orientation métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
      Architecture de référence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Coûts et avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
      Avantages des SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
      Gestion des coûts SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Projets et applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
      Projets et applications actuels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
      Planification du programme SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Briques de construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
      Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
      Infrastructures communes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Organisation et gouvernance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
      Modèles de gouvernance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
      Conformité SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
      Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Ressources additionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

A propos de bea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Contributeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

Introduction
L’objectif des architectures orientées services ou SOA (Service Oriented Architecture) est de permettre aux
entreprises de réaliser des progrès métiers et technologiques en combinant l'innovation des processus, une
gouvernance efficace et une stratégie technologique centrée sur la définition et le réemploi des services. Bien
qu’impliquant une stratégie à long terme - qui amène à repenser la façon dont les technologies de l'information
sont fournies aux utilisateurs - les SOA doivent également répondre à des initiatives immédiates. En d'autres
termes, le bénéfice des SOA exige de maintenir l'équilibre entre objectifs à long terme et besoins opérationnels
à cour terme en instituant, dès l’initialisation, un ensemble de pratiques d’excellence organisationnelles,
financières, opérationnelles, de conception et de livraison. Le modèle SOA en 6 domaines conçu par BEA
« encapsule » ces pratiques d’excellence dans six domaines clés – qui doivent être traités avec la même
diligence pour proposer un framework SOA performant.

Bien que distincts, ces six domaines sont interconnectés et interdépendants. La réussite exige de les traiter
avec une égale attention ; ce document présente les enjeux propres à chaque domaine et les pratiques
d'excellence qui conditionnent la réussite de la mise en place d’une SOA.

  Qu’est-ce qu’une SOA ?
  L’architecture orientée service ou SOA est une stratégie permettant de convertir les fonctions applicatives
  élémentaires en modules de service normalisés et interopérables qui peuvent ensuite être rapidement
  combinés et réutilisés pour donner naissance à de nouvelles solutions ou processus composites.

  En organisant les systèmes d’information autour de services et non d’applications, les SOA présentent les
  avantages suivants :
  • Meilleure productivité, agilité et vitesse pour l’entreprise et ses technologies de l’information ;

  • Livraison accélérée de nouveaux services parfaitement conformes aux besoins métiers

  • Meilleure réactivité opérationnelle et livraison accélérée de solutions utilisateur optimisées.

Six domaines répondant à des challenges spécifiques
Chacun de ces six domaines soulève un enjeu particulier pour réussir le déploiement d’une architecture orienté
service.

1. Processus Métiers & Stratégie
    Enjeu : Fournir des implémentations techniques prenant en charge les activités opérationnelles et les
    changements des besoins.
    Réponse : Un environnement reliant l’administration et la quantification des technologies de l’information aux
    stratégies métier afin que ces deux aspects fonctionnent en symbiose pour une constante amélioration des
    processus.

                                                                                                                     5
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

2. Architecture :
    Enjeu : Les entreprises financent et développent leurs projets informatiques par lignes d’activité. Elles gèrent
    ensuite les processus d’intégration transversale qui limitent la capacité de changement.
    Réponse : Un environnement technique basé sur des standards, la distribution, le « couplage faible » et des
    représentations des processus permettant de répondre au changement et d’intégrer des fonctionnalités de
    niveau entreprise.

3. Eléments de base :
    Enjeu : Manque de cohérence et de reproductibilité empêchant d’atteindre des objectifs budgétaires et
    d’agilité.
    Réponse : Un socle d’information commun, standardisé et homogène permettant de capitaliser sur les
    réussites à travers le réemploi des implémentations et des infrastructures centrales.

4. Projets et Applications :
    Enjeu : Les technologies de l’information sont traditionnellement développées par projets au sein des lignes
    d’activité métier impliquant de fréquents « doublons fonctionnels ». Elles génèrent souvent des doublons et
    impliquent la réécriture de fonctionnalité à l’identique.
    Réponse : Collecte, catégorisation et repositionnement des fonctionnalités des systèmes et applications
    pour normaliser la façon dont ils sont proposés, réduire la redondance et améliorer l’homogénéité
    d’exécution.
5. Organisation et Gouvernance :
    Enjeu : La croissance interne par création de solutions ponctuelles pour répondre à de nouveaux besoins
    génère des architectures rigides et coûteuses à modifier.
    Réponse : Une structure organisationnelle chargée de la gouvernance et de la standardisation des modalités
    de livraison des services, garantissant leur conformité aux besoins métiers et maximisant l'utilisation des
    fonctionnalités existantes.

                                                                                   • Stratégies métiers SOA
                                                                                   • Architecture des processus métiers

Figure 1:                                                                                        Processus
                                         • Coûts de construction                                                             •   Architecture de référence
                                                                                                 métiers &
                                         • Avantages métiers                                      Stratégie                  •   Administration/Disponibilité
Les six domaines SOA                      et informatiques                                                                   •   Evolutivité
                                         • Indicateurs clés                          Coûts &                                 •   Sécurité
                                                                                     Bénéfices                Architecture

                                         •   Conception organisationnelle      Organisation &            Eléments            •   Services d'infrastructure
                                                                               Gouvernance                de base
                                         •   Financement                                                                     •   Services d’information et d'a
                                         •   Compétences                                                                     •   Services métiers partagés
                                                                                             Projets &
                                         •   Fonctions et responsabilités                                                    •   Services de présentation
                                                                                            Applications
                                         •   Standards                                                                       •   Applications composites
                                         •   Processus et outils opérationnels
                                         •   Gestion du changement
                                                                                   • Applications existantes
                                                                                   • Projets clés opérationnels
                                                                                   • Plans de construction des infrastructures

6
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

6. Coûts & Bénéfices :
    Enjeu : Le rapport coûts/avantages des technologies de l’information est un facteur récurrent de friction
    entre les départements informatiques et les directions fonctionnelles qu’ils supportent.
    Réponse: Planification et exécution d’implémentations permettant de créer de la valeur rapidement en
    intégrant les ressources existantes à une architecture évolutive et extensible.

Processus Métiers & Stratégie
Les technologies de l’information jouent un rôle clé dans le processus décisionnel des directions fonctionnelles ;
pourtant, la direction informatique est rarement perçue comme un partenaire stratégique mais plutôt comme une
entité relativement lente à produire les améliorations indispensables de productivité.

Cet écart entre les besoins métiers et la capacité d’exécution technique dépend moins des technologies
elles-mêmes que de la façon dont elles sont mises à la disposition des activités. Très souvent, les entreprises
commencent par développer une stratégie métier puis tentent ensuite de l’implémenter dans une stratégie
informatique distincte.

En outre, les stratégies opérationnelles et informatiques se basent sur des échelles de temps différentes : à
long terme pour les premières ; à court terme pour les secondes qui doivent répondre aux besoins immédiats
de chaque entité métier. Lorsque les systèmes d'information sont organisés sur la base des lignes d'activité,
l'écart entre les deux stratégies s’amplifie ; il en résulte des silos applicatifs ne bénéficiant d’aucune intégration
transversale.

La réalisation de gains de productivité exige de réduire l’écart entre les besoins liés à la stratégie métier et
l’exécution technique, et par conséquent, d’appliquer des changements fondamentaux aux principes
d’« alignement » entre les systèmes d’information et les stratégies métiers. Lors de la mise en place des SOA
de première génération, BEA a constaté que cette approche novatrice favorisait la synergie entre stratégies
informatiques et impératifs métiers en maximisant la conformité des réalisations aux besoins exprimés.

                                                 Architecture traditionnelle                Architecture orientée service (SOA)

Figure 2:
                                                                            Stratégie                                Stratégie
                                              Stratégie                                        Stratégie
Approche traditionnelle et approche                                     des technologies                   SOA   des technologies
                                               métier                                           métier
SOA                                                                      de l’information                         de l’information

                                                                                                                         7
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

Programme SOA
Les SOA exigent un changement culturel dans les modes de collaboration, la réflexion architecturale et les prin-
cipes de fourniture des fonctionnalités aux utilisateurs. Un programme SOA – bénéficiant d’appuis
hiérarchiques forts et d’une grande visibilité – est indispensable pour mettre en place ces changements dans
l’entreprise et notamment pour :

    • Promouvoir le partage et la compréhension de la stratégie générale afin que les décisions soient prises
      avec une vision globale (non limitée à une ligne d’activité) ;
    • Centraliser la stratégie SOA d’entreprise pour chacun des six domaines clés à travers un programme
      d’évolution sur plusieurs années ;
    • Définir une architecture dynamique, réactive et standardisée ;

    • Garantir une livraison au moindre coût des fonctionnalités par identification et optimisation des processus
      divisibles en services partagés et réemployables ; éviter la duplication des fonctionnalités en utilisant celles
      proposées par les applications existantes ;
    • Décider des priorités de développement et de déploiement de services et choisir les incréments et dates
      de livraison ;
    • Établir une organisation de gouvernance appropriée afin que les processus, politiques et standards soient
      respectés ;
    • Encourager le changement et l’adoption à travers des mesures de promotion et d’incitation ;

    • Déployer les outils de mesure appropriés pour analyser en permanence le rapport coûts/bénéfices ;
      organiser une « boucle de rétroaction » pour valider la viabilité de l’ensemble du programme.

Optimisation des processus métiers
Les SOA font des systèmes d’information un partenaire à part entière de la stratégie générale d'entreprise.
Les technologies sont alors l’expression concrète des processus d'entreprise - et non 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. La direction des systèmes
d'information peut ainsi considérablement améliorer sa réactivité avec la maturité des SOA dans la mesure où
la fourniture de nouvelles fonctionnalités consiste à étendre des processus existants et non à construire des
systèmes ou applications indépendants.

L’étude des processus, systèmes et programmes de développement existants à court, long et moyen termes
permet d’identifier les processus prioritaires de l’initiative SOA. Il s’agit à ce stade de réaliser une analyse
collaborative entre les directions fonctionnelles et informatiques pour prioriser les activités en fonction de la
stratégie métier et d’initialiser une boucle d’itération pour maximiser le retour sur les investissements
existants. La figure 3 illustre cette boucle d’itération.

L’analyse des processus permet de recenser les fonctionnalités techniques préexistantes et celles nécessitant
de nouveaux développements. Les fonctionnalités métiers standards seront ensuite proposées sous forme de
services et de contrats en régissant l’usage. 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.

8
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

L’optimisation n’est pas un projet ponctuel mais l’exécution d’une stratégie SOA pluriannuelle. Pour en tirer des
avantages à court, moyen et long termes, elle exige en effet une gestion des cycles d’itération pour
standardiser la livraison des services conformément aux objectifs métiers.

Les SOA représentent un changement fondamental dans les modes de livraison des technologies de
l'information. Les gains d’agilité réalisés par une utilisation rapide et adaptée d’une SOA au service des lignes
d’activité encouragent une étroite collaboration entre les départements fonctionnels et informatiques pour
réaliser les avantages du changement dans toute l’entreprise. Lorsque la direction des systèmes d’information
peut exprimer les activités métiers en termes technologiques, elle obtient plus facilement l’adhésion des
directions fonctionnelles dans le cadre d'un partenariat stratégique. Plutôt que de simplement traduire les
besoins dans un jeu de systèmes et applications déconnectés au service des lignes d’activité, les SOA
permettent aux entreprises d’être vraiment innovantes et de s’adapter rapidement à des environnements
changeants.

                                                                        • Orchestration
                                                                         des services en processus
                                                                        • Alignement des critères
Figure 3:                                                                de mesure avec la stratégie
Optimisation des processus –                                            • Identification des opportunités
Boucle d’itération
                                                                         d’optimisation

                                                                                                     • Analyse des processus
                                                 • Collecte des fonctionnalités                      • Identification des fonctions
                                                   des actifs existants                              de support requises
                                                 • Développement
                                                   de nouvelles fonctionnalités
                                                 • Développement des contrats
                                                   et packaging en services

                                                                                                                          9
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

Architecture
L’architecture définit comment les fonctionnalités sont fournies et déployées au bénéfice d’une activité et de
ses utilisateurs. L’évolutivité architecturale face au changement est un enjeu décisif que les méthodes
traditionnelles de livraison de services ne traitent pas correctement.

Pour que les architectures soient suffisamment réactives, c’est leur fonction même qui doit être repensée.
Les SOA sont au cœur de ce changement en raison de caractéristiques fondamentalement différentes de
celles habituellement en vigueur dans la plupart des grandes entreprises. Ces caractéristiques sont idéalement
adaptées pour gérer le changement et mieux aligner les systèmes d'information sur les besoins métiers.

Orientation service
Les systèmes d’information sont généralement acquis ou développés pour satisfaire les besoins d’un segment
métier donné - et déployés à son seul bénéfice. Cette approche sectorielle contribue largement à la duplication des
fonctionnalités - alors même que les initiatives de partage des fonctionnalités existantes (au niveau code ou
composant) échouent généralement en raison de cette orientation séquentielle des activités de développement.

Une approche de service exige de repenser la façon dont les fonctionnalités sont développées et livrées aux
utilisateurs. Il s’agit en synthèse de les analyser, les « factoriser » et les déployer une fois pour être utilisées à tous
les niveaux de l'entreprise et bénéficier de coûts réduits, d'une livraison accélérée et d’une meilleure réactivité au
changement. En complément de ses différences de financement et de gouvernance, l’approche de service
nécessite un changement dans la façon dont les fonctionnalités sont packagées et déployées. Les SOA intègrent
leurs modalités de mise à disposition sous forme de services et leurs principes d'administration et de pilotage.

Standardisation
Dans les architectures traditionnelles, chaque projet recourt à la méthode la plus immédiate pour satisfaire les
besoins exprimés. Ce qui peut conduire à la prolifération de technologies parallèles – qui peut poser problème
dès qu’il s’agit de leur faire échanger des informations. Les tentatives antérieures d’approche par composants
(comme CORBA ou DCOM) ont subi les désavantages des technologies requises pour les mettre en œuvre et
d’un développement peu dynamique des standards sous-jacents – voire des deux... Plus récemment des
solutions comme XML, les services Web et UDDI ont permis de développer un socle normalisé pour les SOA
favorisant le réemploi grâce à des technologies supportant les standards véritablement disponibles et
indépendantes de la plate-forme.

Orientation entreprise
Le développement des systèmes d’information par ligne d’activité réduit la visibilité et complexifie
singulièrement les initiatives transversales. Beaucoup d’entreprises répondent à cette déficience en créant des
groupes ou des comités d’architecture - qui généralement se focalisent sur la sélection des technologies 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.

10
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

Orientation métier
Dans la plupart des entreprises, les utilisateurs fonctionnels ont besoin de dizaines d’applications pour
accomplir leurs missions quotidiennes. Il s’agit là encore d’une méthode traditionnelle de livraison par produit -
où chaque application est développée pour un ensemble de besoins. Cette organisation est génératrice de
redondances, d’augmentation des frais de formation, de dépendance vis-à-vis de compétences spécialisées,
de duplication des saisies de données et d’un manque général de visibilité et de contrôle des processus
globaux. L’objectif des SOA est de fournir des fonctionnalités dans un contexte que les utilisateurs peuvent
comprendre, spécifier, tester et utiliser quotidiennement.

Architecture de référence
Les caractéristiques exclusives des SOA et leur approche descendante « top down » permettent de définir une
architecture d’entreprise de haut niveau. Cette architecture – dite de référence - décrit les composants
essentiels de la SOA et leurs relations les uns avec les autres. L’architecture de référence SOA est présentée à
la figure 4.

L’architecture interpose entre les utilisateurs et les fonctionnalités des systèmes ou applications sous-jacentes
une infrastructure de service et de livraison. Ces couches de services et les infrastructures qui les prennent en
charge sont regroupées sous le vocable de « couche d’Infrastructure de Service » - exprimant leur vocation à
rénover les méthodes de livraison des technologies d’information. Les applications existantes, les données et
les solutions de middleware constituent les fondations dont les services sont « extraits ».

L’infrastructure prend en charge et formalise les activités existantes à travers des services normalisés
d’infrastructure - (socle commun pour le déploiement de tous les autres types de services). Elle assure
également leur administration (indépendance de l’emplacement physique, basculement, gestion, etc.) et le suivi
de leurs caractéristiques inhérentes à la qualité. Un « bus de service » prend en charge les activités générales
de routage et de transformation (comme un échangeur de messages ou un bus applicatif dans les outils
traditionnels de middleware). Les autres services généraux (journal, audit, sécurité, gestion des erreurs, etc.)
peuvent être intégrés aux outils d’entreprise pour normaliser la livraison des fonctions centrales. Ces services
sont déployés dans une infrastructure de partage qui constitue un nouveau concept pour beaucoup
d'entreprises mais n'en reste pas moins un élément clé pour construire une plate-forme SOA performante.

                                                    Ventes                Engineering          Services                                        Clients

                                                                 B2B                    B2C               Partenaires
Figure 4:

Architecture de référence SOA

                                                                                                                                                                                                      Besoins
                                                                                                                                                                         Couche d’infrastructure

                                                             Applications composites                                                                                                               non fonctionnels
                                                                                                              Gestion des services

                                                                                                                                                      Services communs

                                                                                                                                                                                                       Standards
                                                                                                                                     Bus de service

                                                                                                                                                                               de service

                                                          Services de présentation
                                                                                                                                                                                                      Outils de
                                                                                                                                                                                                    développement

                                                                   Services métiers partagés                                                                                                            Gestion
                                                                                                                                                                                                   des configurations

                                                                                                                                                                                                    Administration
                                                     Services d’information et d'accès                                                                                                                système

                                                                                                                                                                                                    Administration
                                                                                                                                                                                                       réseau
                                                 Systèmes d’information Données et Middleware
                                                      d’entreprise                                                                                                                                 Dimensionnement

                                                                                                                                                                                                     Pilotage des
                                                                                                                                                                                                    activités métier
                                                                                  Bases de   Middleware
                                                   Applications spécifiques
                                                                                  données Interactions
                                                       Progiciels tiers                  (Tuxedo, MQ, etc.)
                                                                                                                                                                                                      Répertoires
                                                      (PGI, GRC, etc.)

                                                                                                                                                                                                        Modèles

                                                                                                                                                                                                                        11
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

La couche d’information et d’accès représente les fonctionnalités existantes. Ces services sont créés
(ou collectés dans les ressources existantes) et déployés dans l’infrastructure de partage pour garantir la
qualité de service ; elle normalise les accès aux fonctionnalités et informations en les encapsulant afin que les
utilisateurs n’aient pas à connaître les technologies ni les modalités d’implémentation sous-jacentes du service.
La mise en œuvre de ces concepts clés permet de développer un socle commun pour accéder aux ressources
existantes et les intégrer à de nouveaux services, plus performants, à haute valeur ajoutée et ciblés sur une
fonction ou une communauté d’utilisateurs. La couche de services métiers partagés représente les
fonctionnalités essentielles d’entreprise ; elle se distingue de la couche de services d’information et d’accès
dans la mesure où elle fournit des fonctionnalités applicables aux informations – et non les informations
elles-mêmes. En d’autres termes, la couche de services métiers partagés intègre les services dans la couche
des services d’information et d’accès pour proposer des fonctions métiers communes. Par exemple, si un
collaborateur est représenté par une entité d’entreprise, encapsulée comme un service d’information, un
service métier partagé de planification peut intégrer le service d’information de ce collaborateur pour obtenir les
données permettant de modifier son planning.

La couche de services de présentation intègre des composants communs - utilisant des services d’information
et d’accès partagés pour interagir avec les ressources d’entreprise – et favorise le réemploi des logiques de
présentation. Par exemple, un portlet d’information de compte constitue un service de présentation (utilisable
dans un portail en libre-service ou d’assistance client), recourant à un service d’information pour afficher les
données du client.

La couche d’applications composites orchestre les autres services et fonctions pour proposer des outils
généraux d’entreprise ; elle représente les fonctionnalités métiers de la façon dont les utilisateurs les envisagent
et souhaitent les utiliser. Un portail d’assistance client ou un processus d'introduction de nouveau produit sont
des applications composites. Elles constituent un processus métier qui peut être géré et mesuré pour
parfaitement répondre aux besoins et aux attentes des utilisateurs fonctionnels. Les véritables avantages
de la couche d’infrastructure de service sont réalisés lorsque les utilisateurs – en parfaite synergie avec les
intervenants techniques – peuvent développer des outils transfonctionnels innovants procurant un remarquable
retour sur investissement.

Au-delà des couches de services et des infrastructures partagées sur lesquelles elles sont déployées, d’autres
besoins et disciplines technologiques doivent être traités pour répondre aux besoins architecturaux généraux.
Les disciplines de développement (packaging, déploiement, suivi des versions et des changements, etc.)
doivent également être normalisées et renforcées afin d’assurer l’homogénéité de l’environnement de partage.
Les caractéristiques de la plate-forme de déploiement (fiabilité et disponibilité) doivent également être prises en
compte pour fournir une qualité de service répondant aux exigences de réactivité d’entreprise.

12
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

Coûts & Bénéfices
La justification d’un programme SOA ne relève pas de la même logique que les projets traditionnels dans la
mesure où les SOA présentent des avantages multiples concernant l’ensemble de l’entreprise. En effet, à
travers les innovations rendues possibles grâce à l’optimisation des processus et aux services partagés, les
SOA offrent des opportunités de création de valeur incomparablement plus élevées que les projets logiciels
classiques. Ce pouvoir d’innovation des SOA est un facteur clé de différentiation pour concevoir un cas métier
robuste. Son évaluation économique doit prendre en compte le fait que les coûts initiaux de mise en œuvre
d’un programme SOA génèrent des bénéfices qui s’accumulent et s’accélèrent substantiellement au fil du
temps.

Avantages des SOA
Sur un plan opérationnel, la continuelle amélioration des processus et la livraison de services orientés métier sont
rendues possibles par une collaboration plus étroite entre les intervenants métiers et informatiques. Les avantages
de cette approche sont nombreux car elle permet de comptabiliser la contribution des technologies de l’information
aux stratégies métiers et de quantifier le rapport coûts/avantages des fonctionnalités service par service.

Sur un plan informatique, les avantages sont également nombreux : livraison de services plus rapide, déploiements
incrémentaux, réemploi des services, accélération des déploiements, standardisation, portabilité des compétences et
réduction des besoins d’expertise spécialisée dans un environnement normé. L’infrastructure de partage exige une
attention particulière dans la mesure où une plate-forme commune de déploiement des services améliore la fiabilité,
la disponibilité, l’extensibilité et les performances grâce à des outils communs de mesure et d’administration.

L’impact d'un programme SOA est généralement plus important pour les domaines métiers. En effet, les budgets
informatiques représentent généralement de 5 à 11 % des budgets totaux de l’entreprise et les réductions des
coûts ou gains de productivité font « pale figure » comparativement aux bénéfices opérationnels. L’exemple d’un
client de BEA permet d’illustrer cette différence entre la rentabilité informatique et les bénéfices métiers.

Figure 5:                   Avantages Métiers                                          Avantages IT
Justifications SOA          Résultats liés aux enjeux métiers stratégiques             Résultats liés aux enjeux informatiques stratégiques
                            Principal                                                  Secondaire
                            Augmentation du chiffre d’affaires en raison d’une         Réduction des coûts de back-office de 30 à 40 %
                            meilleure réactivité de mise sur le marché et du
                            profilage personnalisé.
                            Amélioration de 75 % de la fidélisation de la clientèle    Systèmes centraux retirés – plus de 200 applications
                            Réduction de 20 % du coût de lancement par offre           Développement d’applications dans les délais et les budgets
                            Meilleur reporting, analyse plus fine des clients et des   Réutilisation de 30 % - conforme aux objectifs
                            campagnes

                                                                                                                                13
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

Cette banque internationale - après avoir identifié les vecteurs clés de sa stratégie métier et les objectifs de son
programme SOA - a suivi sa progression tout au long de lla mise en place. Les résultats techniques ont été
particulièrement significatifs puisque plus de 200 applications ont pu être éliminées – ainsi que les coûts de support
et de maintenance des fonctionnalités dupliquées. Cependant, les résultats les plus remarquables ont été obtenus
dans le domaine fonctionnel puisque les « sponsors métiers » du programme SOA ont amélioré de 75 % la
fidélisation des clients grâce à leur nouvelle capacité à proposer rapidement de nouveaux services et fonctionnalités
à travers leurs canaux de commercialisation en ligne.

Les entreprises ayant adopté une architecture SOA utilisent plusieurs approches pour justifier les investissements
initiaux et récurrents de leurs programmes SOA. Les critères techniques de quantification sont parfois complexes
mais certains se focalisent sur le développement d’un framework simple pour aligner les systèmes d’information
avec les impératifs métiers. L’identification et la définition de ces critères au début du processus de planification
SOA permettent de prioriser les travaux afin de créer de la valeur dès le début du projet.

Les objectifs et la stratégie métier - associés à l’inventaire des fonctionnalités disponibles et des activités techniques
requises pour les prendre en charge - fournissent toutes les informations nécessaires pour développer une stratégie
d'implémentation SOA focalisée sur la création de valeur, sous la responsabilité commune des intervenants
techniques et fonctionnels. Cette priorisation des premiers projets sur la création de valeur est essentielle pour
garantir la pérennité à long terme des programmes SOA.

Gestion des coûts SOA
Les avantages des SOA se mesurent sur plusieurs années et non sur quelques mois. Des investissements
initiaux en ressources humaines et technologies doivent être réalisés qui produisent leurs effets lorsque les
services commencent à être utilisés et les fonctionnalités standards réemployées pour générer d’autres gains
opérationnels, marginaliser les applications les plus anciennes et capitaliser sur différents autres facteurs de
rentabilité.

Lorsqu'il existe un nombre conséquent de services réemployables, la capacité des systèmes d'information à
fournir rapidement de nouveaux outils pour tirer parti des opportunités du marché permet de réaliser de
considérables bénéfices opérationnels. L’impact initial des investissements SOA peut également être minimisé
en sélectionnant avec attention les projets ayant le plus fort effet d’entraînement. Au fil du temps, les SOA
modifient la structure du coût des technologies de l’information comme illustré à la figure 6.

                                                                                    Approche
                                                                                  traditionnelle
Figure 6:
                                             Coûts cumulés

Structure des coûts de livraison tradi-
tionnels et SOA
                                                                                                                                SOA

                                                             Investissements              Intégration                 Maturité
                                                             en infrastructures        des infrastructures       des infrastructures
                                                                     SOA                       SOA                       SOA

                                                             1     2      3        4   5      6      7       8   9     10     11       12

                                                                   Nombre de fonctionnalités implémentées
14
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

Projets et applications
Dès que l’architecture de référence SOA et la structure du programme sont définies, il reste à choisir les
services qui offriront les fonctionnalités et le retour sur investissement exigés par l'entreprise et leur rythme de
déploiement. Ce plan de déploiement des services guide et priorise les travaux de collecte, de développement
et d’optimisation des services.

La stratégie de service débute par l'identification des projets déjà planifiés et des fonctionnalités du portefeuille
d’applications pour déterminer les services existants qui peuvent être implémentés ou collectés. Les projets qui
complètent l’architecture doivent ensuite être développés et priorisés. Le programme SOA permet de gérer
plusieurs projets individuels créateurs de valeur métier pour gagner de nouveaux clients, maximiser la valeur
des clients existants ou accélérer la création de nouveaux produits ou services. La planification efficace de ces
projets pour fournir des services partagés est une discipline essentielle pour garantir la réussite des
programmes SOA.

Projets et applications actuels
Les programmes SOA débutent généralement dans un contexte de forte hétérogénéité (infrastructures
techniques, applications, projets en cours, etc.) nécessitant d'analyser l’état initial des applications et des
projets pour localiser les fonctions existantes applicables à l’ensemble de l’entreprise – et donc potentiellement
réemployables. Cette étape est cruciale lorsque plusieurs applications disposent de fonctionnalités identiques
ou similaires. Elle permet également de localiser les composants d’infrastructure existants et ceux qui devront
être acquis ou développés pour fournir une SOA complète. En revanche, il n’est pas nécessaire à ce stade
d’envisager les fonctionnalités entièrement spécifiques à l’application ou au projet pour lequel elles sont
développées.

Le programme SOA doit donc débuter par un inventaire des applications existantes et un catalogue des
projets en cours ; ces deux éléments doivent notamment intégrer les informations suivantes :
   • Fonctionnalités des applications existantes, services et dépendances ;

   • Granularité et capacité des services existants ;
   • Interdépendances des applications existantes avec les projets planifiés ou en-cours et enjeux de
     développement et de maintenance ;
   • Utilisation actuelle des services communs ;
   • Coûts et autres critères de mesure relatifs au développement applicatif ;
   • Informations consultées et livrées par les applications ;
   • Modèle de données, transformations et traductions utilisés dans les applications ;
   • Workflow et flux de processus impliqués dans les applications ;
   • Utilisation de services tels que signature unique (SSO), journalisation, traitement des erreurs et exceptions,
     monitoring et notifications ;
   • Contrats de niveau de service (SLA), de qualité de service (QoS) et autres informations métiers
     non-fonctionnelles ;
   • Détails des prévisions de livraison actuelles et des calendriers des projets immédiats.
   .

                                                                                                                       15
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

Il peut exister plusieurs catalogues ou inventaires - associés aux lignes d’activité, divisions ou selon d’autres
critères. En amont du programme SOA, les services essentiels sont identifiés d’après l’importance de leurs
fonctionnalités dans les processus métier de l’entreprise. Le résultat de cette analyse fournit les bases pour
mieux comprendre les services de haut niveau qui seront mis en œuvre dans les infrastructures SOA. Lorsque
le catalogue projet et l’inventaire des applications sont réalisés, il est possible de sélectionner les services
initiaux de l’infrastructure SOA.

Ces décisions doivent également intégrer les conclusions des activités d’optimisation des processus. Certains
services applicatifs correspondent bien aux services métiers stratégiques et d’autres éléments peuvent fournir
des fonctionnalités ou composants d’infrastructure utiles (services d’information et d’accès, etc.). Certains
services applicatifs existants nécessitent en revanche des modifications pour répondre aux besoins
transversaux d’entreprise.

L’audit initial des applications et projets permet d’identifier les fonctionnalités préexistantes candidates à une
mise en service. Ces services initiaux sont publiés dans un catalogue contenant les détails de leurs interfaces,
de leurs fonctionnalités et d’autres métadonnées permettant de définir leurs « contrats d’utilisation ». Cette
documentation doit être conforme aux principes de développement partagé du programme SOA et faciliter
l’identification des services intégrables aux différents projets applicatifs. Le programme SOA doit gouverner la
structure et les règles de propriété du catalogue de services, de la stratégie de service et des autres modèles
de communs.

Planification du programme SOA
Le lancement d’un programme SOA est une vaste entreprise, impliquant de multiples applications utiles à
l’ensemble de l’entreprise. Après avoir été localisés et publiés, les services seront en effet utilisés par plusieurs
entités internes – voire par des partenaires ou des clients. Compte tenu de cette importance stratégique, les
programmes SOA doivent faire l’objet d’une implémentation graduelle, préférable à une approche de
« big bang », comme en attestent tant l’expérience de BEA que les pratiques d’excellence professionnelles.
En effet, la réduction des risques et de la complexité des projets de développement logiciel exigent une
approche incrémentale pour maîtriser la complexité architecturale et générer des avantages métiers tout au
long du cycle de vie du programme - et notamment dans ses phases initiales. Cette analyse permanente du
rapport coûts/bénéfices des solutions SOA permet de garantir leur justification et leur pérennité.

L’identification, la planification et la définition des contenus des projets SOA répondent à plusieurs motivations
sous-jacentes et au besoin de développer des services partagés et des blocs de construction. Par ailleurs, les
travaux de rénovation et de portage des applications monolithiques ou spécialisées dans l’infrastructure SOA
doivent être intégrés au planning. Certaines de ces motivations vont au-delà de celles qui influencent
normalement les projets de développement non-SOA spécifiques à une ligne d’activité et soulignent le besoin
d’une structure de gouvernance.

16
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

Nos expériences des solutions SOA nous permettent de classer les projets de production de services partagés
en différentes catégories en fonction de leurs attributs de complexité et de phase. Le niveau de complexité se
réfère à la solution technique requise pour le projet et au type d’application développé ; il peut être faible,
moyen ou élevé. La matrice de complexité intègre de multiples facteurs : organisation, importance stratégique
ou tactique de l’application, niveau de maturité de la gestion politique de l’application, sophistication des
mécanismes de gouvernance appliqués au développement d’applications, etc. La notion de phase se réfère au
niveau d’avancement du projet ; on en distingue généralement trois qui sont caractérisées par des enjeux
spécifiques applicatifs, de développement, métiers, opérationnels et techniques liés au nombre croissant
d’applications en environnement SOA.

La figure 7 illustre ces deux notions de complexité et de phase ainsi que les motivations des projets successifs
et la compréhension de l’environnement initial qui guident la planification et le cadencement des programmes
SOA. Cette discipline permet d’obtenir une bonne visibilité des réussites métiers et de créer les infrastructures
techniques essentielles en amont du cycle de vie pour recevoir ultérieurement des applications plus complexes
grâce à la maturité des infrastructures SOA.

                                                                                              Nirvana SOA

                                                                                                         • Infrastructure partagée
                                                                  • Introduction SODA
                                                                                                         • Multiples applications
                                           Forte

                                                                  • Solution tactique
                                                                                                         • Partage et réutilisation généralisés
Figure 7:                                                         mono-application
                                                                                                         des services d’entreprise
                                                                  • Accès aux données
Approche du développement                                                                                • Intermédiaire
                                                                  via services
incrémental                                                                                              • Contrôles basés sur des politiques
                                                     Complexité

                                                                  • Applications composites
                                           Moyenne

                                                                                                         • Gestion des contrats de niveau
                                                                  • APS
                                                                                                         de service et de qualité (SLA/QoS)
                                                                                                         • Déploiements distribués étendus
                                                                                                         • Processus métiers et applications
                                                                                                         composites
                                                                                                         • Modèles de gouvernance intégrés
                                           Faible

                                                                                 Phase
                                                                  Phase 1         Phase 2      Phase 3

                                                                                                                                 17
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s

Le développement progressif de l’infrastructure SOA, des livraisons et du catalogue de services conduit à une
plus grande présence des modules partagés et à l’essor de nouveaux projets dans le temps.

La figure 8 indique comment les services peuvent être collectés dans différents projets et partagés et comment
l’infrastructure cible est développée en adoptant l’approche recommandée de développement incrémental.

Les blocs de construction - identifiés d’après les applications, les projets et l’organisation cible - sont
regroupés dans les couches de l’architecture de référence, et leur implémentation est planifiée en fonction du
calendrier de livraison des applications et projets, de la stratégie générale et de la charge d’implémentation.
BEA recommande d’adopter une approche incrémentale de conception de l’architecture cible et des blocs de
construction associés pour bénéficier d’un retour sur investissement immédiat – et non après deux ou trois ans
de déploiement d’une infrastructure SOA complète.

La planification de l’implémentation des blocs de construction dépend des besoins du projet et des charges de
conception, de développement et de test de chacun d’entre eux. Le guide d’estimation de projet SOA conçu
par BEA peut être utilisé pour estimer les efforts nécessaires au développement de chaque bloc de
construction et de chaque application. Les estimations des blocs de construction définissent les phases et les
modalités d’accélération de la création de valeur des investissements d’infrastructure sous-tendant la SOA ;
associées aux besoins métiers et non-fonctionnels, elles peuvent être utilisées pour planifier le développement
d’architectures cibles orientées SOA.

                                                                                                                                                                                     Couche d’infrastructure
Figure 8:                                                 1     2    3
                                                                                                                         Gestion des services

                                                                                                                                                                  Services communs
                                                                                                                                                Bus de services

                                                                           Applications composites
                                                                1    3
Approche incrémentale de collecte
                                                                                                            1    2   3
                                                                                                                                                                                           de service

                                                                Services de présentation 1 2 3
Plan d’infrastructure — Exemple
                                                  1
Objectif : plan de développement à
plusieurs années séquencé par :                   2                            Services métiers partagés
• les principales initiatives métier ;            3                                1   2   3    3   2      1     2 2 1
• les projets de développement en cours ;                                                                                 1                     1                   1
                                                  1
• les capacités organisationnelles ;
• les financements disponibles ;
                                                             Services d’information et d'accès                            2                     2                   2
                                                  2
• la nature des applications.                                  1    2      3   3                             3   2   1
                                                  3                                                                       3                     3                   3

                                                         1    - Projet 1       2   - Projet 2   3   - Projet 3

18
Vous pouvez aussi lire