Méthodologie SOA en six domaines

Transcription

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 marques 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 service de BEA Systems, Inc. Tous les autres noms de sociétés ou de produits sont potentiellement soumis à des droits
de propriété détenus par des tiers.
CWP0965E0705-1A
Livre Blanc BEA – M é t h o d o l o g i e S O A e n 6 D o m a i n e s
SOMMAIRE
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Six domaines répondant à des challenges spécifiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Stratégie métier et processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Programme SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Optimisation des processus métiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Orientation service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Standardisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Orientation entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Orientation métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Architecture de référence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Coûts et avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Avantages des SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Gestion des coûts SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Projets et applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Projets et applications actuels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Planification du programme SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Briques de construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Infrastructures communes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Organisation et gouvernance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Modèles de gouvernance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Conformité SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Ressources additionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
A propos de bea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Contributeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Introduction
L’objectif des architectures orientées services ou SOA (Service Oriented Architecture) est de permettre aux
entreprises de réaliser des progrès métiers et technologiques en combinant l'innovation des processus, une
gouvernance efficace et une stratégie technologique centrée sur la définition et le réemploi des services. Bien
qu’impliquant une stratégie à long terme - qui amène à repenser la façon dont les technologies de l'information
sont fournies aux utilisateurs - les SOA doivent également répondre à des initiatives immédiates. En d'autres
termes, le bénéfice des SOA exige de maintenir l'équilibre entre objectifs à long terme et besoins opérationnels
à cour terme en instituant, dès l’initialisation, un ensemble de pratiques d’excellence organisationnelles,
financières, opérationnelles, de conception et de livraison. Le modèle SOA en 6 domaines conçu par BEA
« encapsule » ces pratiques d’excellence dans six domaines clés – qui doivent être traités avec la même
diligence pour proposer un framework SOA performant.
Bien que distincts, ces six domaines sont interconnectés et interdépendants. La réussite exige de les traiter
avec une égale attention ; ce document présente les enjeux propres à chaque domaine et les pratiques
d'excellence qui conditionnent la réussite de la mise en place d’une SOA.
Qu’est-ce qu’une SOA ?
L’architecture orientée service ou SOA est une stratégie permettant de convertir les fonctions applicatives
élémentaires en modules de service normalisés et interopérables qui peuvent ensuite être rapidement
combinés et réutilisés pour donner naissance à de nouvelles solutions ou processus composites.
En organisant les systèmes d’information autour de services et non d’applications, les SOA présentent les
avantages suivants :
• Meilleure productivité, agilité et vitesse pour l’entreprise et ses technologies de l’information ;
• Livraison accélérée de nouveaux services parfaitement conformes aux besoins métiers
• Meilleure réactivité opérationnelle et livraison accélérée de solutions utilisateur optimisées.
Six domaines répondant à des challenges spécifiques
Chacun de ces six domaines soulève un enjeu particulier pour réussir le déploiement d’une architecture orienté
service.
1. Processus Métiers & Stratégie
Enjeu : Fournir des implémentations techniques prenant en charge les activités opérationnelles et les
changements des besoins.
Réponse : Un environnement reliant l’administration et la quantification des technologies de l’information aux
stratégies métier afin que ces deux aspects fonctionnent en symbiose pour une constante amélioration des
processus.
5
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:
Les six domaines SOA
• Coûts de construction
• Avantages métiers
et informatiques
• Indicateurs clés
•
•
•
•
•
•
•
Processus
métiers &
Stratégie
Coûts &
Bénéfices
•
•
•
•
Architecture de référence
Administration/Disponibilité
Evolutivité
Sécurité
•
•
•
•
•
Services d'infrastructure
Services d’information et d'a
Services métiers partagés
Services de présentation
Applications composites
Architecture
Organisation &
Eléments
Conception organisationnelle
Gouvernance
de base
Financement
Compétences
Projets &
Fonctions et responsabilités
Applications
Standards
Processus et outils opérationnels
Gestion du changement
• Applications existantes
• Projets clés opérationnels
• Plans de construction des infrastructures
6
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
Figure 2:
Approche traditionnelle et approche
SOA
Stratégie
métier
Stratégie
des technologies
de l’information
Architecture orientée service (SOA)
Stratégie
métier
SOA
Stratégie
des technologies
de l’information
7
Programme SOA
Les SOA exigent un changement culturel dans les modes de collaboration, la réflexion architecturale et les principes de fourniture des fonctionnalités aux utilisateurs. Un programme SOA – bénéficiant d’appuis
hiérarchiques forts et d’une grande visibilité – est indispensable pour mettre en place ces changements dans
l’entreprise et notamment pour :
• Promouvoir le partage et la compréhension de la stratégie générale afin que les décisions soient prises
avec une vision globale (non limitée à une ligne d’activité) ;
• Centraliser la stratégie SOA d’entreprise pour chacun des six domaines clés à travers un programme
d’évolution sur plusieurs années ;
• Définir une architecture dynamique, réactive et standardisée ;
• Garantir une livraison au moindre coût des fonctionnalités par identification et optimisation des processus
divisibles en services partagés et réemployables ; éviter la duplication des fonctionnalités en utilisant celles
proposées par les applications existantes ;
• Décider des priorités de développement et de déploiement de services et choisir les incréments et dates
de livraison ;
• Établir une organisation de gouvernance appropriée afin que les processus, politiques et standards soient
respectés ;
• Encourager le changement et l’adoption à travers des mesures de promotion et d’incitation ;
• Déployer les outils de mesure appropriés pour analyser en permanence le rapport coûts/bénéfices ;
organiser une « boucle de rétroaction » pour valider la viabilité de l’ensemble du programme.
Optimisation des processus métiers
Les SOA font des systèmes d’information un partenaire à part entière de la stratégie générale d'entreprise.
Les technologies sont alors l’expression concrète des processus d'entreprise - et non un ensemble disjoint de
systèmes représentant chacun un fragment de processus. Parallèlement, les processus métiers sont
encapsulés et peuvent ainsi faire l'objet de mesures et d'analyses de pertinence. La direction des systèmes
d'information peut ainsi considérablement améliorer sa réactivité avec la maturité des SOA dans la mesure où
la fourniture de nouvelles fonctionnalités consiste à étendre des processus existants et non à construire des
systèmes ou applications indépendants.
L’étude des processus, systèmes et programmes de développement existants à court, long et moyen termes
permet d’identifier les processus prioritaires de l’initiative SOA. Il s’agit à ce stade de réaliser une analyse
collaborative entre les directions fonctionnelles et informatiques pour prioriser les activités en fonction de la
stratégie métier et d’initialiser une boucle d’itération pour maximiser le retour sur les investissements
existants. La figure 3 illustre cette boucle d’itération.
L’analyse des processus permet de recenser les fonctionnalités techniques préexistantes et celles nécessitant
de nouveaux développements. Les fonctionnalités métiers standards seront ensuite proposées sous forme de
services et de contrats en régissant l’usage. Les processus peuvent alors être exprimés comme un ensemble
de services assemblés (ou « orchestrés ») constituant un processus complet. Les contrats gouvernant les
services intègrent des mécanismes pour mesurer les performances générales et vis-à-vis d’indicateurs clés.
Mais ils mesurent aussi la conformité avec les engagements de qualité de service (SLA). Ces éléments
quantitatifs permettent de mettre en lumière des opportunités d'améliorations et de réaliser une boucle
d’itération pour aligner les systèmes d'information sur les besoins métiers.
8
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
Figure 3:
• Alignement des critères
de mesure avec la stratégie
Optimisation des processus –
Boucle d’itération
• Identification des opportunités
d’optimisation
• Analyse des processus
• Collecte des fonctionnalités
des actifs existants
• Identification des fonctions
de support requises
• Développement
de nouvelles fonctionnalités
• Développement des contrats
et packaging en services
9
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
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
Figure 4:
Engineering
B2B
Services
B2C
Clients
Partenaires
Architecture de référence SOA
Systèmes d’information Données et Middleware
d’entreprise
Applications spécifiques
Progiciels tiers
(PGI, GRC, etc.)
Bases de
Middleware
données Interactions
(Tuxedo, MQ, etc.)
Couche d’infrastructure
de service
Services d’information et d'accès
Services communs
Bus de service
Gestion des services
Besoins
non fonctionnels
Standards
Outils de
développement
Gestion
des configurations
Administration
système
Administration
réseau
Dimensionnement
Pilotage des
activités métier
Répertoires
Modèles
11
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
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:
Justifications SOA
Avantages Métiers
Résultats liés aux enjeux métiers stratégiques
Principal
Augmentation du chiffre d’affaires en raison d’une
meilleure réactivité de mise sur le marché et du
profilage personnalisé.
Amélioration de 75 % de la fidélisation de la clientèle
Réduction de 20 % du coût de lancement par offre
Meilleur reporting, analyse plus fine des clients et des
campagnes
Avantages IT
Résultats liés aux enjeux informatiques stratégiques
Secondaire
Réduction des coûts de back-office de 30 à 40 %
Systèmes centraux retirés – plus de 200 applications
Développement d’applications dans les délais et les budgets
Réutilisation de 30 % - conforme aux objectifs
13
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.
Structure des coûts de livraison traditionnels et SOA
Approche
traditionnelle
Coûts cumulés
Figure 6:
SOA
Investissements
en infrastructures
SOA
1
2
3
Intégration
des infrastructures
SOA
4
5
6
7
Maturité
des infrastructures
SOA
8
9
10
11
Nombre de fonctionnalités implémentées
14
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.
Projets et applications actuels
Les programmes SOA débutent généralement dans un contexte de forte hétérogénéité (infrastructures
techniques, applications, projets en cours, etc.) nécessitant d'analyser l’état initial des applications et des
projets pour localiser les fonctions existantes applicables à l’ensemble de l’entreprise – et donc potentiellement
réemployables. Cette étape est cruciale lorsque plusieurs applications disposent de fonctionnalités identiques
ou similaires. Elle permet également de localiser les composants d’infrastructure existants et ceux qui devront
être acquis ou développés pour fournir une SOA complète. En revanche, il n’est pas nécessaire à ce stade
d’envisager les fonctionnalités entièrement spécifiques à l’application ou au projet pour lequel elles sont
développées.
Le programme SOA doit donc débuter par un inventaire des applications existantes et un catalogue des
projets en cours ; ces deux éléments doivent notamment intégrer les informations suivantes :
• Fonctionnalités des applications existantes, services et dépendances ;
• Granularité et capacité des services existants ;
• Interdépendances des applications existantes avec les projets planifiés ou en-cours et enjeux de
développement et de maintenance ;
• Utilisation actuelle des services communs ;
• Coûts et autres critères de mesure relatifs au développement applicatif ;
• Informations consultées et livrées par les applications ;
• Modèle de données, transformations et traductions utilisés dans les applications ;
• Workflow et flux de processus impliqués dans les applications ;
• Utilisation de services tels que signature unique (SSO), journalisation, traitement des erreurs et exceptions,
monitoring et notifications ;
• Contrats de niveau de service (SLA), de qualité de service (QoS) et autres informations métiers
non-fonctionnelles ;
• Détails des prévisions de livraison actuelles et des calendriers des projets immédiats.
.
15
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
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.
• Infrastructure partagée
• Multiples applications
• Partage et réutilisation généralisés
des services d’entreprise
• Intermédiaire
• Contrôles basés sur des politiques
• Gestion des contrats de niveau
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
• Introduction SODA
• Solution tactique
mono-application
• Accès aux données
via services
• Applications composites
• APS
Faible
Moyenne
Approche du développement
incrémental
Complexité
Figure 7:
Forte
Nirvana SOA
Phase
Phase 1
Phase 2
Phase 3
17
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.
Approche incrémentale de collecte
1
Plan d’infrastructure — Exemple
Objectif : plan de développement à
plusieurs années séquencé par :
• les principales initiatives métier ;
• les projets de développement en cours ;
• les capacités organisationnelles ;
• les financements disponibles ;
• la nature des applications.
3
1
2
3
1
1
2
3
3
2
1
2 2 1
2
1
3
1
18
2
Services de présentation 1 2 3
2
- Projet 1
3
3
2
3
- Projet 2
3
- Projet 3
2
1
1
1
1
2
2
2
3
3
3
Couche d’infrastructure
de service
3
Services communs
3
Bus de services
2
1
Gestion des services
1
Figure 8:
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.
Implémentation de service : La partie implémentation du service est constituée du code, de l’interface de
l’application ou d’autres actifs technologiques contenant la fonctionnalité requise. Elle peut être accomplie par
n’importe quelle technologie. Les premières implémentations représentent généralement une fonctionnalité
préexistante.
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
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
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
• 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.
• Modèle de financement et comptabilisation : Les services et l’architecture de référence institutionnalisent
un suivi et un reporting à forte granularité des coûts et des bénéfices des technologies de l’information et
permettent d’optimiser les décisions d’investissement. Cette approche est essentielle pour démontrer la
valeur créée et développer les cas d’utilisation ultérieurs – et plus particulièrement des services
d’infrastructure de niveau entreprise.
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:
Phases d’organisation
et de gouvernance
Phase I. Définition
• Principes SOA généraux
• Architecture SOA
• Principes, politiques et standards
(conception, développement,
opérations, outils, etc.)
• Processus et procédures SOA
(opérations, gestion du
changement, etc.)
• Organisation SOA (concepts,
compétences, fonctions et
responsabilités)
22
Phase II. Administration
• Communication (interne, externe)
• Respect des standards SOA et
conformité des services
• Architecture SOA Processus
d’exception
Phase III. Support / Contrôle
• Monitorat d’entreprise
• Définition et administration du
catalogue de services métiers
• Pilotage des processus
• Architecture SOA Processus
d’inspection et d’adaptation
• Financement
• Processus de gestion du
changement
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.
En termes métiers, le modèle de gouvernance gère les aspects suivants :
• Modalités de quantification et niveau de granularité (par application composite ou service par service) de
l’efficacité de mise sur le marché et du retour sur investissement afin de sécuriser la rentabilité de l’initiative
SOA et de mener une étude permanente du rapport coûts/avantages du programme.
• Méthode d’orchestration des groupes de services en solutions métiers (ou applications composites) et de
gestion du cycle de vie afin que l’intégrité de la solution métier soit assurée tout au long de son cycle de
vie – quels que soient les services qui la composent.
• Principes d’ingénierie domaine à plus long terme pour poursuivre l’optimisation des processus représentés
dans le système d’information à travers le référentiel de services.
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.
Généralement un modèle de gouvernance multiniveau en comporte trois : un pour chaque catégorie de
service. Le modèle de gouvernance regroupe les services en fonction de leur potentiel de réutilisation et affecte
différents degrés de contrôle centralisé et un contrôle métier direct à chaque niveau.
Moins universel – Plus spécifique
Modèle orienté métier
• Financement : Direct par les activités
• Architecture : Architectes applicatifs sponsorisés
Figure 10:
par une direction fonctionnelle et sous
la responsabilité d’un Architecte en chef
Exemples de modèles de gouvernance
multiniveaux
• Développement : Equipes métiers
Modèle orienté métier- Administré SI
• Financement/définition : Conseil métier
• Architecture/Développement : DI
Modèle central/partagé
• 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
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’architecture SOA ayant des responsabilités transversales tant organisationnelles que fonctionnelles.
Le groupe d’architecture SOA prend en charge la gestion centralisée du programme, l’architecture, la
planification, les services d’infrastructure et la gestion des versions. Son organisation exacte dépend des
structures sous-jacentes et des facteurs suivants :
• Alignement métier et soutien des décideurs seniors.
• Dimension de l’organisation et structure géographique.
• Modèle de gouvernance SOA multiniveau.
• Niveau de maturité SOA de l’organisation.
Le groupe d’architecture doit s’appuyer sur une structure évolutive avec la maturité SOA. Dans un contexte de forte
24
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é
Figure 11:
Structure des groupes d'architecture
SOA
Fédéré
Equipe
de gouvernance
fédérée
(Région A)
Equipe
de gouvernance
centralisée
(Entreprise)
Hiérarchique
Equipe
de gouvernance
fédérée
(Région B)
Partiellement fédéré
Equipe de
gouvernance
Equipe
de gouvernance
hiérarchique
(Région A)
Equipe
de gouvernance
hiérarchique
(Région A)
Gouvern. Gouvern.
locale
locale
(UK)
(DE)
Gouvern. Gouvern.
locale
locale
(US)
(CAN)
Equipe
de gouvernance
fédérée
(Région A)
Equipe
de gouvernance
partiellement
fédérée
(Région B)
Equipe
de gouvernance
partiellement
fédérée
(Région C)
Les structures des groupes du
diagramme sont détaillées dans le tableau suivant :
Centralisé
Hiérarchisé
Au début du cycle d’adoption d’une SOA, une structure centralisée
est privilégiée pour gérer le programme dans de bonnes conditions
de cohérence et d’homogénéité.
Avec la maturité des fonctionnalités SOA, l’entreprise exige
des structures plus avancées et évolutives pour prendre en charge
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.
Fédéré
Partiellement fédéré
Lorsque des régions distantes additionnelles ont des besoins
de gouvernance SOA, la structure fédérée est utilisable.
Ces organisations de service fédérées sont des répliques exactes
des structures centralisées en termes de conformité SOA et de support
– cependant, la gouvernance générale demeure un organe central.
Lorsque des régions distantes additionnelles ont des besoins de
conformité et de support avec des ressources limitées,
une structure partiellement fédérée est envisageable.
En raison de l’augmentation des lignes de communication
there are limits to the scalability of this structure and it tends to
au-delà de 3 régions. Si d’autres régions doivent rejoindre
l’environnement l’entreprise doit envisager de migrer vers une structure
hiérarchisée.
25
Ressources additionnelles
Pour d’autres informations sur les solutions et services de BEA, consultez le centre de ressources SOA :
www.bea.com/soa.
Ce site rassemble de nombreux documents, présentations et études et propose une plate-forme
d’« auto-évaluation SOA » développée d’après le modèle de domaine BEA pour fournir une première approche
de vos niveaux actuels de maturité dans les six domaines clés des SOA. À l’issue de cette évaluation, vous
recevrez un rapport personnalisé de 9 pages intégrant des suggestions pragmatiques pour améliorer votre
préparation aux 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.
Pour plus d’informations, consultez fr. bea.com.
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.
Ian Barnes, Chief Advocate of Technology in EMEA
Fort de 19 années d’expérience, Ian Barnes est un expert de la formation des décideurs aux avantages des
approches technologiques et architecturales – et plus spécifiquement dans l’univers des SOA. En tant consultant
auprès des décideurs stratégiques des clients de BEA, Ian Barnes participe à la définition de solutions de grande
ampleur. Il est également responsable de la communication horizontale auprès des architectes et des ingénieurs de
développement des technologies d’infrastructure de BEA. Ian Barnes intervient comme expert lors des projets
majeurs d’implémentation SOA pour fournir son expertise du domaine à BEA et aux principaux architectes clients.
Stephen Bennett, Senior Principal Business Consultant
Steve Bennett a 20 années d’expérience du développement logiciel, des pratiques d’excellence d’agilité et des
architectures d’entreprise. Il a conseillé de nombreux clients de BEA pour définir leur architecture. Membre de
la division Worldwide Consulting de BEA, Steve est actuellement spécialisé en SOA ; pendant les douze
années précédentes, il était responsable de systèmes d’information stratégiques dans l’industrie bancaire.
26
David Groves, Director Worldwide Consulting
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, Consulting Technical Manager
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,VP of IT & Deputy CIO
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
Immeuble Triangle de l’Arche
8, cours du Triangle
92397 Paris La Défense 12 cedex
fr.bea.com
CWP0965E0705-1A

Méthodologie SOA en six domaines

Transcription

Documents pareils

Consultants EAI/SOA/Urbanisation (H/F)

L`adoption des principes d`architecture orientée services (SOA) à la

SERVICE ORIENTED ARCHITECTURE SERVICE ORIENTED

Système d`Information

L`approche SOA

Architecte de solutions

IBM SOA Infrastructure Consulting Services – stratégie et

(SOA) et Microsoft® BizTalk® Server