Académique Documents
Professionnel Documents
Culture Documents
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
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
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Orientation service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Standardisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Orientation entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Orientation métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Architecture de référence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
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.
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 ;
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.
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
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
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.
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.
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
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.
Besoins
Couche d’infrastructure
Services communs
Standards
Bus de service
de service
Services de présentation
Outils de
développement
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
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.
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.
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
1 2 3 4 5 6 7 8 9 10 11 12
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.
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 ;
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.
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
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
18
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
Eléments de base
Les éléments réutilisables - développés de la première à la dernière application d’un programme SOA
pluriannuel - et les infrastructures dans lesquelles ils sont déployés, pilotés et administrés constituent les blocs
de construction SOA. Ils peuvent être logiciels (code, modèles de données normatifs, processus, services,
applications, composants) ou organisationnels (pratiques d’excellence, standards, outils de développement, de
déploiement, d’opération, d’administration, etc.). Les applications sont construites à partir d’un ensemble de
blocs de construction constituant l’infrastructure d’entreprise. Comme pour l’architecture cible, BEA
recommande de développer progressivement ces blocs de construction et de les optimiser par itération.
Les services constituent le composant essentiel des blocs de construction logiciels. Un service peut être défini
comme un moyen d’assembler des blocs de construction logiciels pour fournir une fonctionnalité à des
utilisateurs ou à d’autres services – qui sont alors qualifiés de « consommateurs » pour les distinguer des
utilisateurs.
Un service est composé de trois éléments : une implémentation, une interface et un contrat. Les services
représentent une fonctionnalité requise par un ensemble d’utilisateurs ou de consommateurs ; cette fonctionnalité
est l’implémentation du service. Pour accéder à l’implémentation, les utilisateurs ou consommateurs passent par
l’interface et manipulent sa fonctionnalité conformément aux principes de son contrat.
Interface de service : L’interface donne aux utilisateurs un moyen d’accès à la fonctionnalité conformément
aux principes du contrat de service. Un service donné peut proposer plusieurs interfaces permettant de
l’utiliser de différentes façons. Par exemple : une interface fournissant un accès synchrone à une fonctionnalité
interactive et une interface asynchrone pour d’autres utilisations.
Contrat de service : Le contrat indique l’objectif, la fonctionnalité, les contraintes et les principes d’utilisation du
service ; il est défini par des utilisateurs fonctionnels dans leur propre vocabulaire. Par exemple : un contrat peut
limiter l’utilisation d’une fonctionnalité offerte par une interface en fonction du rôle de l’utilisateur ou de sa
provenance (interne/externe). L’infrastructure SOA doit assurer la définition et l’application des contrats. Des outils
– tels que les plates-formes d’administration de services Web et les bus de services d’entreprise – permettre de
répondre à ces besoins.
19
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
Caractéristiques
Les principales caractéristiques fonctionnelles d’un service sont son mode d’appel (synchrone ou asynchrone),
ses principes d’échange (unidirectionnel ou bidirectionnel) et sa complexité (fonction de sa granularité).
La granularité se réfère au niveau d’abstraction du service. Un service à forte granularité propose une
fonctionnalité élémentaire : par exemple, une méthode normalisée d’appel à une API (service d’accès) ou un
mode opératoire vis-à-vis d’une entité d’entreprise comme un collaborateur (service d’information).
Les services métiers partagés sont généralement aussi des services à forte granularité assurant des opérations
élémentaires (calculs financiers, etc.) Les services à faible granularité proposent des mécanismes pour accéder
à des fonctionnalités complexes - telles que la procédure d’embauche d’un collaborateur ou le traitement
d’une commande. Les services à faible granularité ont souvent une longue durée de vie exigeant de
coordonner l’exécution de services à plus forte granularité ; leur implémentation est naturellement plus
complexe.
Les caractéristiques non-fonctionnelles du service intègrent des facteurs tels que les besoins volumétriques, la
qualité de service, la durée d’exécution, etc. qui sont intégrés à son contrat. Les caractéristiques et fonctionnalités
des services permettent de les classer dans différentes couches architecturales. Même si ces dernières sont
déployées selon des principes physiques différents, cette catégorisation permet de prendre des décisions
informées sur l’utilité et les priorités de développement. Les premiers blocs de construction sont les services
d’infrastructure (journalisation, audit, gestion des erreurs, etc.). Ces composants à vocation étendue partagent
souvent les mêmes implémentations (au moins au niveau de la forme du code) et fournissent les infrastructures
communes nécessaires à tous les services qui seront développés ultérieurement. Les services d’information et
d’accès sont également parmi les premiers développés compte tenu de leur utilité générale.
Les disciplines informatiques nécessaires pour réussir l’implémentation SOA doivent également être considérées
comme des blocs de construction (stratégies de gestion des versions, de packaging, de déploiement des services,
de test, etc.). Ces méthodes peuvent varier selon les divisions (voire au sein de la même ligne d’activité) ou être
applicables à l’ensemble de l’entreprise (et faiblement utilisées). En matière de SOA, la réactivité de livraison des
services à leurs utilisateurs ou consommateurs dans toute l’entreprise exige de respecter des principes normalisés
dont la création et l’application sont du ressort de la gouvernance SOA.
Infrastructures communes
Les infrastructures communes prennent en charge les premiers blocs de construction et intègrent différents
composants et notamment un référentiel de services permettant aux consommateurs potentiels de rechercher les
servies disponibles et aux producteurs de services de faire connaître leur disponibilité. Cette capacité à localiser et
utiliser rapidement une fonctionnalité obéissant à un contrat d’utilisation est un des avantages clés des SOA.
Le référentiel de services simplifie la consommation des services dès que les premiers blocs de construction sont
disponibles - et devient rapidement indispensable avec l’augmentation du nombre de services. Les composants
d’infrastructure suivants – impliqués dans le développement et le déploiement des services – doivent également
être considérés comme des blocs de construction SOA par nature :
• Infrastructures de sécurité (gestion des identités, frameworks de sécurité d’entreprise, etc.)
• Infrastructures de routage, transformation et traduction dynamique (généralement un bus de service
d’entreprise)
• Gestion des configurations des composants déployés, du matériel et des services d’exécution.
• Technologie de portail (livraison multicanal, fédération des contenus Web, infrastructures de présentation,
etc.)
20
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 maturité des SOA nécessite également une plate-forme de monitoring des activités (BAM) pour quantifier les
performances de la SOA par rapport aux contrats.
La plate-forme sur laquelle les services sont déployés et ses modalités d’intégration aux infrastructures nécessitent
également un examen attentif. Un grand nombre de technologies et de plates-formes peuvent être mises en œuvre
pour fournir ces composants de l’infrastructure SOA. Néanmoins, l’impératif de standardisation permet de ne
retenir que des solutions au meilleur état de l’art et de nombreux facteurs jouent en faveur de l’adoption d’une
plate-forme intégrant toutes les fonctionnalités requises dans un environnement unique de développement et de
déploiement pour simplifier tous les aspects opérationnels et la standardisation des méthodes.
Ces infrastructures SOA peuvent être déployées lors de la livraison des services qui les utilisent afin de minimiser les
risques et les coûts en intégrant graduellement les blocs de construction et des infrastructures.
Organisation et Gouvernance
À ce jour, les tentatives de transformation des systèmes d’information par maximisation du réemploi ont connu
un succès limité en raison de faiblesses dans la définition des fonctionnalités, le suivi du changement, la
conception, la gestion de projet ou dans les outils disponibles. Cependant, dans la plupart des cas, et quels
que soient les progrès accomplis dans chaque discipline, l’absence de structures et de principes forts de
gouvernance et d’organisation joue un rôle central, voire décisif dans ces échecs. Tout projet de transformation
des modes de fourniture des technologies de l’information doit adopter une approche stratégique, impliquant
toute l’entreprise et s’appuyant dès l’initialisation sur des pratiques d’excellence et des structures de
gouvernance. Les SOA ne font bien entendu pas exception à la règle.
La gouvernance et le développement d’une organisation pour la prendre en charge sont les fondations du
modèle de domaine. Le programme de gouvernance SOA doit contrôler tous les éléments suivants :
• Conformité aux standards : Le succès des SOA exige que les services et l’architecture soient développés
à partir de standards clairs et applicables à toute l’entreprise.
• Stratégie de service : Contrôle global de la définition, du développement et du déploiement des services -
au cas par cas lors de la mise en production - pour concevoir un portefeuille complet de services
interopérables.
• Gestion du changement : Les évolutions et changements incessants des besoins métiers et leurs
conséquences sur les systèmes centraux peuvent avoir d’importants effets induits qui sont largement
diminués à travers une utilisation optimale de l’architecture de référence et un processus rigoureux de
gestion du changement.
21
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
• Stratégie de réemploi : Le coût des technologies de l’information est souvent surévalué en raison de la
duplication des fonctionnalités ou de l’incapacité à partager celles qui existent déjà. À travers ses
standards et sa stratégie, la gouvernance assure le suivi des fonctionnalités d’entreprise et met en œuvre
des politiques pour maximiser le réemploi et simplifier le processus de gestion du changement.
• Structure organisationnelle : Les SOA nécessitent d’adopter une nouvelle organisation des équipes afin
de garantir le respect des normes, des principes de réemploi et de la stratégie de service. Les structures
organisationnelles SOA permettent de mettre en œuvre de multiples modèles (de « totalement centralisé »
à « totalement fédéré ») pour s’adapter aux besoins spécifiques de chaque entreprise.
• Changement culturel : La stratégie de gouvernance doit promouvoir un changement culturel, notamment
dans les modes de collaboration et de partage des informations, besoins et fonctionnalités entre les
départements informatiques et les directions fonctionnelles. La gouvernance doit également combattre la
tendance naturelle à « réinventer la roue ».
• Développement des compétences et pratiques d’excellence : Les fonctions d’organisation et de
gouvernance proposent une vue globale des compétences techniques et non-techniques requises par
l’entreprise et s’attachent à collecter et partager les pratiques d’excellence pour optimiser la productivité
des collaborateurs, diffuser les compétences dans l’organisation et garantir leur portabilité d’un projet à
l’autre.
Le programme de gouvernance SOA doit être déployé en plusieurs phases dont les activités sont détaillées
dans le tableau qui suit.
Figure 9: Phase I. Définition Phase II. Administration Phase III. Support / Contrôle
Phases d’organisation • Principes SOA généraux • Communication (interne, externe) • Monitorat d’entreprise
et de gouvernance • Architecture SOA • Respect des standards SOA et • Définition et administration du
conformité des services catalogue de services métiers
• Principes, politiques et standards • Architecture SOA Processus • Pilotage des processus
(conception, développement, d’exception
opérations, outils, etc.)
• Processus et procédures SOA • Architecture SOA Processus • Financement
(opérations, gestion du d’inspection et d’adaptation
changement, etc.)
• Organisation SOA (concepts, • Processus de gestion du
compétences, fonctions et changement
responsabilités)
22
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
Modèles de gouvernance
La réalisation d’une infrastructure de services partagés exige d’adopter un modèle de gouvernance approprié –
c’est-à-dire : prédéfini, général et standardisé - pour satisfaire simultanément les exigences des départements
informatiques et fonctionnels. Le modèle de gouvernance prend en charge les enjeux informatiques suivants :
• Responsabilités et modalités de définition des services partagés et réemployables.
• Modalités de construction des services, intervenants et approche de l’ingénierie logicielle.
• Habilitation des utilisateurs, modalités d’utilisation des services.
• Principes des activités associées de déploiement et de fonctionnement opérationnel des services.
• Responsabilité de la coordination des quatre activités ci-dessus et principes généraux de réussite.
Les modèles mis en œuvre varient considérablement d’une entreprise à l’autre mais il est toujours préférable
d’anticiper le besoin d’un modèle multiniveau dans la mesure où chaque service transversal intègre ses propres
challenges de gouvernance. Les modèles multiniveaux aident les entreprises à faire face au volume et à la
variété des enjeux qui se posent dans ce domaine.
Modèle central/partagé
Services d’information et d'accès • Financement : Central/partagé, négocié avec
les directions fonctionnelles
Services d'infrastructure • Architecture : Architectes centraux sous
la responsabilité d’un Architecte en chef
• Développement : Groupe de développement central
Plus universel et générique
23
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 gouvernance n’est pas une activité ponctuelle ; elle exige des efforts constants pour garantir le respect par
les nouveaux projets des principes architecturaux SOA et l’application des principes de conformité SOA.
Conformité SOA
Les entreprises ne peuvent pas s’appuyer uniquement sur des collaborateurs compétents et des canaux de
communication efficaces pour garantir la conformité architecturale - qui relève autant d’un changement culturel
que de la stricte application des principes de conformité. Dans les phases initiales des projets SOA, les
objectifs de gouvernance sont généralement plus interventionnistes et diffèrent de ce qu’ils deviendront dans
une architecture plus mûre ou la SOA est « institutionnalisée ».
Les entreprises doivent également s’assurer que les standards architecturaux et les meilleures pratiques sont
respectés en définissant un processus formel de revue de conformité SOA. Ce dernier peut être mené par un
intervenant extérieur, comprenant les principes fondamentaux de la SOA et capable de fournir une vue
stratégique des services métiers partagés.
L’incapacité à appliquer les principes de conformité SOA génère les inconvénients suivants :
• Alignement défectueux des services SOA avec l’architecture de référence – ou utilisation inappropriée
des standards.
• Mauvaise prise en charge des objectifs métiers – dans la mesure où les services ne représentent plus
directement des processus métiers.
• Dilution voire disparition de la couche d’infrastructure de service – provoquant la perte d’une source
majeure d’améliorations.
Organisation
La réussite d’un programme SOA exige de rénover la façon dont les technologies de l’information sont
organisées et utilisées ce qui peut avoir un impact très différent en fonction du type d’entreprise. Certaines sont
organisées en divisions avec leurs propres départements et ressources informatiques ce qui génère une grande
complexité et conduit souvent à la divergence des portefeuilles applicatifs et des méthodes d’interaction avec
les systèmes d’information.
Pour réaliser les bénéfices des SOA, une mise en conformité de plus haut niveau est nécessaire qui exige un
changement culturel, une évolution des compétences, la redéfinition de certains rôles et responsabilités et la
mise en œuvre d’un modèle commun de financement des services. Par ailleurs, il est également important que
les principes du modèle de gouvernance soient appliqués uniformément à toute l’entreprise ce qui nécessite un
équilibre entre le contrôle local et la coordination centrale. Cette dernière peut être réalisée par un groupe d’ar-
chitecture SOA ayant des responsabilités transversales tant organisationnelles que fonctionnelles.
Le groupe d’architecture doit s’appuyer sur une structure évolutive avec la maturité SOA. Dans un contexte de forte
24
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
répartition géographique, il est généralement préférable de débuter par l’une des structures organisationnelles
décrite ci-dessous (figure 11). La structure centralisée peut être implémentée dans un premier temps pour laisser la
place à une autre lorsque de nouveaux besoins apparaissent.
La meilleure approche à long terme que recherchent toutes les entreprises déployant des SOA favorise une
gouvernance multiniveau et une organisation hiérarchisée pour des raisons de performance et d’évolutivité.
Centralisé Fédéré
Equipe
Equipe de de gouvernance
gouvernance fédérée
(Région A)
Equipe Equipe
Equipe Equipe de gouvernance de gouvernance
de gouvernance de gouvernance partiellement partiellement
hiérarchique hiérarchique fédérée fédérée
(Région A) (Région A) (Région B) (Région C)
Centralisé Hiérarchisé
Au début du cycle d’adoption d’une SOA, une structure centralisée Avec la maturité des fonctionnalités SOA, l’entreprise exige
est privilégiée pour gérer le programme dans de bonnes conditions des structures plus avancées et évolutives pour prendre en charge
de cohérence et d’homogénéité. la SOA. Certaines décisions sont prises centralement et d’autres
sont déléguées à des groupes locaux au sein de la hiérarchie.
25
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
Ressources additionnelles
Pour d’autres informations sur les solutions et services de BEA, consultez le centre de ressources SOA :
www.bea.com/soa.
A propos de BEA
BEA Systems, Inc. (NASDAQ : BEAS), leader mondial des logiciels d’infrastructure, fournit des plates-formes
standardisées et sécurisées pour accélérer et fluidifier la circulation des informations et services. Ses lignes de
produits WebLogic®, Tuxedo® et la nouvelle gamme d’infrastructures de service AquaLogic™ aident les entreprises à
réduire la complexité de leurs systèmes d’information et à déployer des architectures SOA pour améliorer leur
réactivité et leur efficacité opérationnelles. Le siège de BEA est implanté dans la Silicon Valley et l’entreprise réalise
un chiffre d’affaires annuel de plus d’un milliard de dollars avec plus de 15 000 clients dans le monde et
76 implantations dans 36 pays.
Contributeurs
John Allen, Senior Principal Business Consultant
John Allen est un expert du développement logiciel ayant plus de 18 années d’expérience de terrain en tant
qu’architecte d’entreprise, chef de projet et ingénieur logiciel. Au cours de 7 années passées chez BEA, l’expertise
architecturale de John a aidé de nombreux clients à atteindre leurs objectifs de robustesse et d’agilité. Au cours
des 18 derniers mois, il a joué un rôle clé dans la définition et l’exécution de la stratégie SOA de BEA.
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
David Groves a 11 années d’expérience des stratégies de système d’information, du consulting d’entreprise, de la
direction de programme et des méthodologies de livraison. Il a conseillé de nombreux clients de BEA dans les
secteurs des finances, des télécommunications et des administrations pour définir leurs stratégies de livraison.
Directeur de la division Worldwide Consulting de BEA, David est actuellement chargé du développement des
offres de service plus particulièrement dans le domaine des SOA et des stratégies d’information. Avant de se
consacrer aux technologies de l’information, David avait des responsabilités d’analyse et de stratégie dans
l’industrie électrique.
Rag Ramanathan a 13 années d’expérience en tant que consultant et ingénieur logiciel en R&D. Rag a aidé
plusieurs clients de BEA à architecturer leurs systèmes d’information et à réussir leurs implémentations
logicielles. Il est expert du développement, des architectures et de l’intégration des solutions d’entreprise.
En tant qu’Architecte de la division Worldwide Consulting de BEA, Rag est responsable du développement des
pratiques d'excellence SOA des clients et partenaires BEA et des évaluations de maturité SOA.
Dale Slaughenhaupt supervise le développement de toutes les solutions e-business du département informatique
de BEA : architecture d’entreprise, infrastructures de service, gestion des versions et configurations, programmes
bureautiques MyBEA, etc. Dale a plus de 11 années d’expérience de la direction de programmes techniques et
du développement d'applications et logiciels. Dale a fait partager à de nombreux clients de BEA son expertise et
les pratiques d’excellence formalisées par ses équipes SOA au cours des quatre dernières années.
Nous remercions également Phil Aston, Jeff Block, Daniel Healy, David Miller, Yogish Pai et Nathan Romney
pour leur assistance dans ce projet.
27
BEA SYSTEMS, SAS
8, cours du Triangle
fr.bea.com CWP0965E0705-1A