Méthodologie SOA en six domaines - Révéler les avantages métiers d'une Architecture Orientée Services
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26Livre 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.
5Livre 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
6Livre 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
7Livre 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.
8Livre 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
9Livre 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
11Livre 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
13Livre 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
14Livre 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.
.
15Livre 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
17Livre 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
18Vous pouvez aussi lire
