4. Avantages de l`architecture orientée service - DIUF

Transcription

Université de Fribourg, Suisse
Département d’informatique
Systèmes d’information
Dr. Hüsemann Stefan
SOA : L’utilité organisationnelle, technique et
financière de l’architecture orientée service
Emine Ulukütük
Impasse de la Forêt 24, 1700 Fribourg
No. d’étudiant : 10-215-523
Bachelor en Gestion d’Entreprise
Août 2013
Remerciements
Je tiens à remercier toutes les personnes m’ayant aidé et soutenu tout
au long de l’élaboration de ce mémoire de Bachelor.
Mes sincères remerciements vont tout d’abord à Monsieur le
Professeur Stefan Hüsemann, d’avoir accepté de superviser ce travail
et pour sa précieuse aide tant au niveau de son encadrement qu’au
niveau de sa disponibilité qu’il m’a accordé dans la réalisation de ce
travail.
Je souhaite également remercier les entreprises ayant participées à la
seconde partie et particulièrement mes interlocuteurs M. Philippe
Savary ainsi que le responsable informatique de la 2ème firme
analysée. Sans leur précieuse collaboration, la partie pratique de ce
travail n’aurait pas été possible.
Je tiens notamment à remercier Joel Rossier, étudiant-assistant
d’informatique à l’EPFL et particulièrement M. Philippe Savary pour
le temps qu’’ils ont consacré à la relecture de ce travail.
Enfin, j’adresse toute ma reconnaissance à ma famille, mes amis, mes
professeurs et toutes les personnes externes pour leur soutien tout au
long de ma formation universitaire à Fribourg, s’achevant sur ce
mémoire de Bachelor.
-1-
TABLE DES MATIÈRES
1. Introduction ................................................................................................................................... 1
1.1. Description du thème ................................................................................................................. 1
1.2. Objectifs et questions centrales du travail ......................................................................... 2
1.3. Méthodologie et structure du travail ................................................................................... 4
2. Qu’est-ce qu’une architecture orientée service ? ............................................................. 5
2.1. Notion de base............................................................................................................................... 5
2.1.1. Le système d’information............................................................................................... 5
2.1.2. L’architecture informatique............................................................................................ 7
2.2. Concept de l’architecture orientée service ........................................................................ 7
2.2.1. Histoire des systèmes d’informations .......................................................................... 7
2.2.2. L’entreprise orientée service : nécessité du SOA ...................................................10
2.2.3. L’architecture orientée service ....................................................................................12
2.2.4. Composantes et principes de base ..............................................................................17
3. L’impact d’une architecture orientée service dans l’entreprise .............................. 25
3.1. D’un point de vue technique et financier ......................................................................... 26
3.1.1. Méthodologie à suivre pour implémenter une SOA.............................................26
3.1.2. Coûts de l’approche ...........................................................................................................30
-23.2. D’un point de vue opérationnel et stratégique .............................................................. 33
3.2.1. Changement dans l’organisation ................................................................................33
3.2.2. Attentes de cette approche ............................................................................................34
4. Avantages de l’architecture orientée service .................................................................. 35
4.1. Au niveau organisationnel : la flexibilité du système ................................................. 35
4.2. Au niveau technique : la réutilisabilité des ressources .............................................. 37
4.3. Au niveau financier : la baisse des coûts .......................................................................... 39
5. Etudes de cas............................................................................................................................... 43
5.1. Office de la Circulation et de la Navigation du canton de Fribourg ....................... 45
5.1.1. Portrait de l’organisation ..............................................................................................45
5.1.2. Présentation du système informatique de l’établissement ..............................46
5.1.3. Description du projet SOA et dans son évolution au fil du temps .................48
5.1.4. Objectifs visés par l’adoption de SOA et grille d’auto-évaluation sur les
attentes et les réalités de SOA ..................................................................................................51
5.1.5. L’utilité réelle de SOA dans l’entreprise ...................................................................54
5.2. Grande compagnie d’assurance ........................................................................................... 56
5.2.1. Présentation de la firme .................................................................................................56
5.2.2. Objectifs visés par l’introduction de SOA .................................................................56
5.2.3. Description de la démarche SOA et dans son évolution au fil du temps .....58
5.2.4. Grille d’auto-évaluation sur les attentes et les réalités de SOA ......................61
-35.2.5. L’utilité réelle de SOA dans l’entreprise ...................................................................63
6. Résultats des études de cas : La réalité du SOA .............................................................. 65
6.1. Les avantages de SOA .............................................................................................................. 65
6.2. Les lacunes de SOA ................................................................................................................... 67
6.3. Analyse globale de l’utilité de SOA ..................................................................................... 69
7. Conclusion ................................................................................................................................... 71
8. Bibliographie .............................................................................................................................. 72
8.1. Littérature.................................................................................................................................... 72
8.2. Articles, documents, présentations .................................................................................... 73
8.3. Webographie .............................................................................................................................. 75
9. Annexes ........................................................................................................................................ 77
Annexe 1: « SOA Infrastructures Costs » .................................................................................. 77
-4-
TABLE DES FIGURES
Figure 2-1: Historique du SI ....................................................................................................................... 9
Figure 2-2: Fonctionnement en silo des SI ........................................................................................ 11
Figure 2-3: Architecture traditionnelle vs SOA. .............................................................................. 14
Figure 2-4: Architecture de base SOA ................................................................................................. 15
Figure 2-5: Entreprise Service Bus ...................................................................................................... 16
Figure 2-6: SOA, liaison entre vue métier et vue technique ....................................................... 18
Figure 2-7: Composition et interopérabilité..................................................................................... 22
Figure 2-8 : Le couplage faible entre consommateurs et logique métier .............................. 24
Figure 3-1: Phase de la démarche SOA ............................................................................................... 27
Figure 3-2: Stratégie d'intégration ....................................................................................................... 29
Figure 3-3: Comparaison de la structure des coûts des technologies de l’information
d'une approche traditionnelle et d'une SOA ...................................................................................... 32
Figure 4-1: Motifs de choix lors de l'adoption de démarche SOA ............................................ 37
Figure 4-2 : Principales attentes des entreprises d'une démarche SOA ................................ 39
Figure 4-3: Investissement initial et rendement à long terme des capitaux investis ....... 40
Figure 5-1: Fonctionnement du logiciel CARI .................................................................................. 46
Figure 5-2: Paysage applicatif de l'OCN.............................................................................................. 47
Figure 5-3: Architecture des services en relation avec les activités d'assurance .............. 50
Figure 5-4 : Grille d'évaluation des attentes et des réalités du SOA de l'OCN ..................... 52
Figure 5-5: Grille d'évaluation des attentes et des réalités du SOA de la compagnie
d'assurance ..................................................................................................................................................... 61
1. Introduction
1. Introduction
Nous vivons actuellement dans une société de consommation orientée vers la
technologie. Cette dernière est présente dans la vie de tous les jours autant pour les
particuliers que pour les entreprises. Un des concepts clé de cette mutation
technologique est l’informatique, qui est devenu un des piliers d’une bonne gestion
organisationnelle. Toutes questions relatives à la communication et à la gestion
d’entreprise relèvent des systèmes d’information dans la plus grande partie des
firmes, surtout actuellement alors qu’on se situe dans une économie de l’information.
Il est primordial pour chaque firme de savoir gérer ces multitudes d’informations et
d’activités, d’une manière organisée. Le système d’informations s’avère être la
solution idéale pour remédier à ce besoin, et permet également à chaque firme de se
démarquer de la concurrence en gagnant des avantages compétitifs.
Les évolutions perpétuelles que connait l’informatique de gestion, alliées au besoin
grandissant de flexibilité des entreprises, rendent le thème des systèmes
d’informations toujours plus intéressant et actuel dans la gestion d’entreprise. Basé
sur ce fait, ce travail de Bachelor tente de connaître la réelle utilité que procure
l’implémentation d’un SI via une architecture orientée service.
1.1. Description du thème
Aujourd’hui, nous vivons dans une société de consommation orientée technologie,
dans laquelle l’échange d’information est primordial. Du point de vue de l’entreprise,
cela implique une bonne gestion des activités ainsi qu’une bonne communication au
sein de toute l’organisation. Chaque entreprise doit se mettre à jour continuellement
afin de suivre l’évolution des technologies de mondialisation et de globalisation qui
rendent la concurrence toujours plus féroce. Dans cette logique, les firmes doivent
s’adapter à ce contexte en étant toujours plus performantes et flexibles afin de
réaliser leurs objectifs et se démarquer de la concurrence.
1
1. Introduction
D’un point de vue informatique, une des méthodes d’amélioration du fonctionnement
de l’organisation au sein d’une firme sont les systèmes d’informations (SI) qui
permettent une meilleure communication, circulation et coordination des données au
sein de l’entreprise. Toutefois, ces systèmes relèvent d’une complexité considérable
au niveau de la structuration et engendrent des coûts élevés pour l’entreprise.
Afin de pallier à ces problèmes, il existe une architecture de conception et
d’implémentation de SI, nommé architecture orientée service (SOA) qui s’avère être
une solution adéquate. Le but de ce travail est de comprendre si ce type
d’architecture SOA répond réellement aux attentes des entreprises qui l’adoptent
comme elle est censée le faire.
1.2. Objectifs et questions centrales du travail
L’objectif principal de ce travail est d’expliciter l’architecture orientée services d’un
point de vue technique, organisationnel et financier et d’en connaître la réelle utilité
pour les entreprises, compte tenu de l’évolution constante des technologies
informatiques.
Dans un premier temps, on étudiera l’approche SOA d’un point de vue théorique tout
en explicitant cette notion, son impact dans les organisations l’adoptant ainsi que les
défis relevés par ce type d’architecture.
La deuxième partie de ce travail sera dédiée à l’étude de deux entreprises afin de
comprendre dans quelles mesures SOA comblent les attentes de celles-ci. De plus,
ces études vont permettre de comprendre quels sont les objectifs visés et les
attentes des entreprises quant à l’implémentation de la SOA.
Tout au long de la lecture de ce mémoire, le lecteur pourra récolter diverses
réponses aux questions suivantes :
Dans la première partie dédiée à l’aspect théorique de la SOA, nous nous poserons
les questions suivantes :
2
1. Introduction

Qu’est-ce qu’une architecture orientée service ?

Quel est l’impact d’une SOA sur les entreprises ?

Quelles sont les défis des SOA?
Afin de répondre à ces questions, nous puiserons des informations dans la littérature
adéquate et expliciterons les termes de système d’informations et d’architecture
informatique. Nous analyserons également l’impact et les défis relevés par les SOA
d’un point de vue technique, organisationnel et financier.
A la suite de ces notions de base, nous nous intéresserons davantage à l’aspect
pratique de la SOA, en présentant deux entreprises ayant implémenté l’architecture
orientée service grâce à diverses questions faisant référence au début de
l’implémentation SOA, telles que :

Quelles étaient les attentes des firmes au début de l’implémentation de
la SOA ?

Quels étaient les objectifs poursuivis par la mise en place de cette
approche ?

Quelle était l’utilité des SOA pour votre entreprise ?
Ensuite une autre série de questions sera discutée afin de voir si SOA a réellement
pu répondre aux attentes des entreprises, telles que :

Quelle est l’utilité des SOA pour votre entreprise ?

SOA tient-elle ses promesses au niveau de la performance ? Répond-telle réellement aux attentes ?

Quelles sont les lacunes à combler dans cette approche ?
Pour compléter la partie pratique, une analyse globale de la SOA sera réalisée pour
évaluer les avantages et les lacunes de SOA dans l’utilisation pratique de cette
architecture.
3
1. Introduction
1.3. Méthodologie et structure du travail
Ce mémoire de Bachelor est divisé en deux grandes parties : une partie théorique
basée sur un travail de recherche et une partie pratique axée sur des entretiens et
interviews réalisés avec des tiers.
La première partie met en lumière des concepts de la SOA en se référant à la
littérature appropriée ainsi que sur des articles scientifiques, des sites web et sur le
cours de Systèmes d’Informations donné par le Professeur Hüsemann.
La seconde partie, quant à elle, est orientée pratique et va soulever les questions
relevant de l’utilisation de la SOA dans plusieurs firmes. Ceci est réalisé grâce à des
études de cas sur la base d’entretiens et de questionnaires afin de connaître les
réels avantages et inconvénients émanant de l’implémentation de la SOA.
Le chapitre 2 explicite les concepts théoriques de la SOA par l’explication de la
notion de SOA, ses principes et ses composantes ainsi que des défis poursuivis par
cette architecture.
L’impact d’une architecture orientée service au sein d’une organisation est discutée
de manière détaillée dans le chapitre 3. Cet impact est analysé d’un point de vue
technique ainsi que d’un point de vue opérationnel et stratégique.
Le chapitre 4 s’intéresse plus particulièrement aux avantages émanant de la mise en
place d’une telle architecture en se focalisant sur trois angles spécifiques à savoir la
technique, l’organisation et les finances de la firme. Ce chapitre permet de
comprendre pourquoi, comment et sous quelles contraintes financières, la SOA fait
partie du système d’information de l’entreprise.
Le chapitre 5 traite des études de cas de deux firmes, permettant ainsi de
comprendre l’utilité et l’impact d’une SOA dans la pratique en présentant le projet
SOA et les objectifs poursuivis par la mise en place de ce projet. Sur la base de ces
études de cas, une étude sera réalisée sur la réalité du SOA en discutant des
avantages et des lacunes de SOA dans le chapitre 6.
Enfin, ce mémoire s’achève sur une synthèse en récapitulant les principales
réponses émanant de ce travail de recherche.
4
2. Qu’est-ce qu’une architecture orientée service ?
Ce chapitre explicite les principales notions de base qu’englobe l’architecture
orientée service. Il pose les principes de base théorique de ce type d’architecture.
Les questions qui vont être résolus dans ce chapitre sont les suivantes :

Qu’est-ce que un système d’informations ?

Qu’est-ce qu’une architecture orientée service ?
Le premier sous-chapitre va introduire la notion de système d’informations et
d’architecture informatique afin de faciliter la compréhension de ce mémoire.
Par la suite, un bref historique de l’avènement du SOA sera discuté dans le second
sous-chapitre. Nous tenterons également de comprendre la place qu’occupent les
systèmes d’informations dans les entreprises actuellement et les raisons pour
lesquelles une architecture adéquate est primordiale au bon fonctionnement des SI.
Enfin, dans la dernière partie de ce chapitre, une description détaillée de SOA suivra
via la présentation des composantes de cette architecture.
2.1. Notion de base
2.1.1. Le système d’informations
Le système d’informations est une notion très vaste et très complexe dans le jargon
informatique dans la mesure où elle englobe passablement d’éléments. Il existe de
multiples définitions dans la littérature informatique qui se complètent les unes et les
autres.
Le système d’informations est un système indispensable pour une bonne gestion
d’organisation dans la mesure où le traitement de l’information est une activité
incontournable dans les entreprises modernes. Les activités de gestion relèvent
5
toutes du traitement et de l’utilisation de l’information comme par exemple tenir une
comptabilité, construire des plans de budgets, gérer la relation client, faire des
prévisions pour les trimestres futures, surveiller la production, etc. Toutes ces
activités sont réalisées par la manipulation d’applications et de composantes sur la
base d’informations gérées par des systèmes informatiques.
Les systèmes d’informations sont apparus vers la fin des années soixante dans le
but d’automatiser des travaux d’ordres administratifs, opérationnelles, de gestion et
d’informatique [Grenier, Moine 2003, p.8-9]. L’idée centrale émanant de toutes les
définitions que l’on peut lire dans la littérature informatique est de définir le SI comme
un outil informatique facilitant la gestion des fonctionnalités des entreprises.
Afin de comprendre cette notion, il est important de bien comprendre les deux sujets
la constituant : le système et l’information.

Un système est une totalité organisée et identifiable, plus ou moins complexe,
regroupant des sous-systèmes reliés entre eux et ayant un but commun. Il
permet l’action, la prise de décision et la mémorisation des informations
[Hüsemann 2011].

L’information
est
définie
comme
une
représentation
des
« données
transformées sous une forme significative pour la personne qui les reçoit ; elle
a une valeur réelle (ou perçue) pour ses décisions et ses actions » [Gordon,
Olson, Ajenstat, Peaucelle 1986, p. 116].
Le système d’information peut ainsi être défini comme « un ensemble organisé de
méthodes et de moyens humains et matériels destinés à collecter, mémoriser et
transmettre les différents types de données nécessaires au fonctionnement d’une
entreprise » [Grenier, Moine, 2003, p. 10].
Les principaux objectifs poursuivis par l’implémentation d’un système d’informations,
sont l’accès rapide et généralisé à l’information que ce soit à l’interne ou à l’externe,
de travailler avec un système ouvert et interactif avec l’extérieur, le développement
rapide d’applications ainsi que la possibilité d’une administration simplifiée [Ben Driss
Khaled, 2007].
6
2.1.2. L’architecture informatique
L’architecture informatique est à la base de tout système d’information : elle va le
structurer et l’organiser par des fonctionnalités, des attributs et des composantes qui
sont reliés entre eux. Dans cette logique, les composantes sont modélisées, les
relations sont décrites et les attributs documentés [Hüsemann 2010]. Ainsi,
l’architecture informatique va définir les règles nécessaires à la construction et à
l’implémentation du SI. Dans la littérature informatique, une architecture software est
définie telle que « a set of statements that describes software components and
assigns the functionality of the system to these components. » [Krafzig, Banke,
Slama 2006, p. 56].
Pour structurer les SI, il est nécessaire d’utiliser des architectures d’intégration qui
permettent de couvrir tous les besoins avec une application construite de manière
intégrée. Nous pouvons citer en exemple les Progiciels de Gestion Intégrés
ERP/PGI, les Portails Web, les Data Warehousing et les Architectures Orientées
Services SOA. Dans ce travail, nous allons nous concentrer sur la dernière
architecture d’intégration, la SOA.
En somme, une architecture informatique doit décrire de manière précise tous les
éléments constitutifs du SI afin de comprendre ce système ayant comme tâche
principale le traitement d’informations de manière flexible.
2.2. Concept de l’architecture orientée service
2.2.1. Histoire des systèmes d’informations
Afin de comprendre l’émergence de cette nouvelle architecture software dans les
années 1996, il est intéressant de tracer l’évolution des systèmes d’informations
dans les technologies informatiques.
Nous pouvons diviser l’histoire des systèmes d’informations en quatre grandes
phases selon les auteurs Fournier-Morel, Grojean, Plouin et Rognon [Fournier-Morel,
Grosjean, Plouin, Rognon 2011, p. 3-7].
7
La première phase consiste à la période où le système informatique des entreprises
était concentré et géré par un serveur unique appelé le mainframe. Ce type de
serveur a l’apparence d’un ordinateur central qui gère l’ensemble de l’information
circulant dans l’entreprise. Ce type d’architecture était extrêmement centralisé
nécessitant le déplacement physique en vue de l’utiliser. En dépit des coûts
d’acquisition et d’exploitation exorbitants, le mainframe était un système cohérent et
fiable procurant des services tels que l’intégrité des données et une très haute
disponibilité des informations.
Ensuite avec le progrès technique et le développement des réseaux informatiques
(et des protocoles associés) reliant les
machines hétérogènes permettent
l’apparition des systèmes client/serveur. Ce type d’architecture permet de transférer
les composantes d’interfaces sur les postes de travail tout en conservant les
serveurs. Ces nouvelles applications s’intègrent dans de nombreuses entreprises
grâce aux faibles coûts qu’elles engendrent. Les SI deviennent incontournables au
sein des entreprises. Plus l’informatique devient présente dans l’entreprise, plus des
problèmes de gestion de l’information se posent. En effet, avec l’avènement
informatique, tous types de profils d’une organisation sont confrontés à l’utilisation
des SI sans avoir une formation particulière dans cette branche. On observe alors
une mauvaise gestion de l’information : des duplications, des redondances, des
erreurs ainsi qu’une absence de communication entre les divers départements
apparaissent dans le système. Ceci crée des incohérences dans les fonctionnalités
des SI mais aussi une complexité non gérable par des utilisateurs lambda.
C’est alors que vers la fin des années 90, les limites du client/serveur ont été
atteintes à la suite de nombreux problèmes émanant de cette architecture. On a pu
constater l’émergence d’un nouveau type architectural : les applications web qui
permettent de se connecter aux processus métier de l’entreprise par un simple
navigateur. Ainsi on permet aux clients et aux fournisseurs de s’intégrer dans le parc
informatique de l’organisation et tout ceci à moindre coût. Les applications web
favorisent également le développement du commerce électronique et offrent ainsi
aux firmes des avantages concurrentiels.
Dans les années 2000, une toutes nouvelle tendance dans les technologies des TIC
a fait son apparition : le Cloud computing qui s’avère être une opportunité importante
8
pour toutes les firmes souhaitant externaliser leur système informatique. Il consiste à
déléguer la gestion de l’informatique d’entreprise à des entités et des personnes
externes, qui sont spécialisées dans le domaine. Tout cela se gère sur demande de
l’entreprise. Toutefois cela pose quelques problèmes en termes de sécurité pour des
données confidentielles ou encore une dépendance de la firme à des tiers étant
donné le manque de maîtrises à l’interne sur les questions d’ordre de sécurité
informatique.
Toutes ces évolutions,
ayant
contribué
au
développement
des
systèmes
d’informations sont illustrés par la figure 2-1. Chaque évolution s’intègre dans des
environnements complexes et devant gérer
indépendamment
de multiples
informations. De plus, l’informatique est dès lors fortement utilisée dans toutes les
entreprises et par de nombreux utilisateurs non spécialisés dans la branche. De ce
fait, la nécessité d’une nouvelle architecture accessible à l’utilisation de tous et
rationalisant la circulation des informations au sein de tout le système fut nécessaire.
Figure 2-1: Historique du SI [Fournier-Morel, Grosjean, Plouin, Rognon 2011, p. 6]
9
Le concept d’architecture orientée service, décrit la première fois par le groupe
américain de recherche en technologie Gartner Group en 1996, se présente comme
étant la solution adéquate à la demande actuelle des entreprises. Pour la première
fois, l’architecture orientée service fut définie comme « client/server software design
approach in which an application consists of software services and software service
consumers (also known as clients or service requesters). SOA differs from the more
general client/server model in its definitive emphasis on loose coupling between
software components, and in its use of separately standing interfaces » [Gartner
Group 2013].
2.2.2. L’entreprise orientée service : nécessité du SOA
L’activité principale d’une entreprise est la création de la valeur par le traitement de
l’information. Comme vu précédemment, une bonne utilisation de l’information dans
les activités de gestion va permettre de meilleurs résultats à l’entreprise. De plus, la
quantité d’information générée est si extraordinaire qu’elle dépasse les compétences
humaines et nécessite l’intervention des ordinateurs. C’est par la prise de conscience
de ce fait, que les entreprises ont intégré les systèmes d’informations dans leur
stratégie d’entreprise pour atteindre des objectifs d’optimisation de la performance.
Les systèmes d’information poursuivent trois objectifs par leur intégration dans
l’environnement de l’entreprise au niveau stratégique, tactique et opérationnel
[Hüsemann 2010] :

Objectif stratégique : le SI doit amener des renforcements au niveau des
avantages stratégiques de la firme, pour la différencier et lui octroyer des
avantages compétitifs vis-à-vis des concurrents.

Objectif tactique : à ce niveau, le SI doit être un outil d’aide à la décision.
Grace aux informations détenues par le système, les décideurs doivent
pouvoir choisir les solutions optimales en fonctions de la situation.

Objectif opérationnel : le SI doit pouvoir soutenir les processus d’entreprise
en les développant. Il doit également permettre une utilisation efficace des
10
ressources de l’entreprise dans le but d’atteindre les objectifs visés par celleci.
L’introduction des systèmes d’informations dans le monde entrepreneurial a modifié
les techniques de gestion d’entreprise en procurant à ces derniers des opportunités
de développement remarquables. Nous avons pu observer des améliorations au
niveau du stockage des données, une fluidité dans la communication des
informations et une simplification dans les processus métiers [Bell, 2006, p. 29].
Pourtant avec l’évolution des technologies de l’information, les systèmes
d’informations construits sous formes d’applications indépendantes deviennent de
plus en plus rigides et de ce fait ne remplissent plus entièrement leur fonction
[Fournier-Morel, Grosjean, Plouin, Rognon 2011, p. 6]. L’entreprise étant
décomposée en plusieurs départements, correspondant à un silo du système
d’information comme dans la figure 2-2, les processus métiers y référants
nécessitent d’être multifonctionnels. En effet, chaque bloc du SI étant isolé en termes
de processus, d’intervenants humains ou matériels et d’interfaces, plusieurs
inconvénients apparaissent quant à l’impossibilité de réutilisation des composantes,
la duplication et les redondances d’objets, la difficulté de mettre en place des
processus métier transversaux, etc. [Fournier-Morel, Grosjean, Plouin, Rognon 2011,
p. 12 ] Le SI est alors confronté à de nouvelles exigences.
Figure 2-2: Fonctionnement en silo des SI [Ben Driss Khaled, 2007]
11
De plus, la mondialisation favorise la concurrence et fait évoluer les stratégies
d’entreprise qui se complexifient et induisent des changements dans le système.
L’intégration de ces changements dans les systèmes devient de plus en plus difficile
et provoque ainsi des désavantages concurrentiels pour les entreprises. Les
systèmes d’information sont alors dans l’obligation de s’adapter à ces changements
sans perdre de temps et sans engendrer des coûts supplémentaires.
Sur la base de ces faits, les entreprises ont pris conscience de la nécessité de
l’implémentation d’une architecture durable et structurée, capable de s’adapter à tout
changement par la réutilisation et la modification des services existants afin de
travailler. Les principales motivations sont la simplification et la suppression des
redondances dans les processus métiers, une bonne intégration et un meilleur
partage des informations grâce à une interface standardisée, et surtout un système
de gestion de l’information flexible [Holley, Dr. Arsanjani, 2011, p.43].
Parmi toutes les architectures de conception de SI, l’architecture orientée service
SOA est celle qui se rapproche des attentes des entreprises.
2.2.3. L’architecture orientée service
Le concept d’architecture orientée service-SOA, apparut déjà plus de 15 ans n’a
toujours pas de définition exacte et universelle. Cette approche a été développée par
diverses entreprises de recherche en informatique telles qu’IBM, BEA, Oracle ou
Microsoft qui ont chacun leur propre concept et leur propre définition de cette
architecture. Bien que toutes les définitions apparaissant dans la littérature se
ressemblent, elles comportent, chacune, des divergences. Voici quelques manières
de définir une SOA:
« SOA is a software architecture that is based on the key concepts of an
application frontend, service, service respository, and service bus.» [Krafzig,
Banke, Slama 2006, p. 57].
12
« Service-oriented Architecture (SOA) is an architectural design pattern that
concerns itself with defining loosely-coupled relationships between producers
and consumers. » [Wikipedia, 2013].
« A service-oriented architecture is essentially a collection of services. These
services communicate with each other. The communication can involve either
simple data passing or it could involve two or more services coordinating some
activity. Some means of connecting services to each other is needed. » [Barry,
Barry & Associates, 2013].
Sur la base de ces écrits, nous pouvons décrire la SOA, au niveau de la gestion
d’entreprise, comme une approche de conception et de construction de système
d’informations qui utilise des interfaces services pour la création de SI. Cette
architecture met à disposition des utilisateurs les fonctionnalités et les services
proposés par une entreprise, via une interface standardisée soit à l’interne soit sur
Internet (pour le e-commerce par exemple).
Cette architecture qui s’avère être un modèle d’intégration moderne a comme
principal objectif l’augmentation de la flexibilité, la réduction des coûts d’intégration,
la mise à disposition de services réutilisables, la modification et la réutilisation des
fonctionnalités ainsi que la composition des processus de gestion par l’utilisation de
services déjà existants ou à créer.
Grâce aux services modulaires interagissant entre eux, nous pouvons facilement
exécuter des processus et ainsi répondre aux demandes et aux besoins des
entreprises en matière de flexibilité. Nous pouvons observer dans la figure 2-3 la
différence entre avant et après une intégration SOA explicitantt clairement le concept
d’architecture organisé avec des relations structurées. L’approche SOA facilite la
gestion de l’interface entre les besoins métiers et l’implémentation technique.
L’interopérabilité des services fait de SOA, une approche d’intégration qui se définit
comme une application composée.
13
Figure 2-3: Architecture traditionnelle vs SOA [Hüsemann 2010].
Dans la littérature, cette conception est souvent présentée comme une approche
pour la refonte progressive des systèmes d’information afin de les rendre durables et
agiles [Bonnet, Detavernier, Vauquier 2008, p. 63]. La principale idée de cette
approche est de construire une architecture logicielle avec des services composés et
reliés entre eux, correspondant aux processus métiers de la firme. Contrairement aux
communications entre des objets hétérogènes comme à l’époque du client/serveur,
ce nouveau style d’architecture met en avant le concept de communication service
passant par des interfaces et masquant ainsi les objets. Le but étant de rendre les
systèmes d’informations aptes et flexibles aux changements qui pourraient apparaitre
par une modification de stratégie ou d’organisation par exemple. [Erl 2008, p. 38].
L’architecture orientée service est un style d’architecture moderne qui suit des
principes de modélisation modernes permettant la réutilisation des services ainsi que
l’exécution de processus d’entreprise. Elle est découpée en plusieurs couches
14
composée de manière générale d’une couche présentation, d’une couche métiers et
d’une couche données.
Les couches essentielles de ce type d’architecture sont aux nombres de quatre : le
système d’intégration, les services, les processus et l’interface. [Liebhart 2007, p.
67].
Figure 2-4: Architecture de base SOA [Microsoft Corporation 2009]
En commençant par le bas de la figure 2-4, la première couche nommée « couche
applications » se réfère au système d’intégration qui permet les liaisons entre les
données, les processus, les services, les bases de données ainsi que les
applications. Tous ces éléments sont liés par le système d’intégration, même s’ils
sont capables d’interagir directement entre eux.
La couche services correspond au deuxième niveau de l’architecture. Le service
étant un périmètre fonctionnel à caractère modulaire et autonome, représentent les
fonctionnalités d’un système qui sont exposés aux consommateurs par le biais d’une
interface. Étant donné, que ce composant met en relation direct l’entreprise avec les
15
consommateurs, la couche service a comme fonction principale la gestion de ces
services entres eux [Liebhart 2007, p. 26].
Les relations entre les services consommateurs dits consumer et les services
producteurs dits provider, peuvent être reliés par un Entreprise Service Bus, présenté
ci-dessous dans la figure 2-5. Cette technologie informatique, qui est l’une des
manières d’implémenter la SOA, permet l’interaction entre les applications à travers
les services. Il facilite ainsi l’échange entre l’entreprise et ses partenaires internes et
externes, plus précisément entre les services consommateurs et les services
producteurs en reliant les applications les unes aux autres [Michoud, Abissa
Informatique 2008].
Figure 2-5: Entreprise Service Bus [Michoud, Abissa Informatique 2008]
La troisième couche processus se réfère aux processus métiers du concept SOA, qui
consistent en des suites d’activités réalisées par les services afin d’apporter une
valeur ajoutée à l’entreprise. Ces activités, ayant comme fonction de décrire les
métiers de l’entreprise et non le système informatique, s’appuient sur diverses
structures et applications d’une organisation [Softeam, Guide pratique Objectering,
2008, p.10]. Les processus métiers sont très souvent représentés en langage UML à
l’aide de diagrammes d’activités.
16
17
La dernière couche de cette architecture correspond à l’interface service, partie
visible de l’architecture par les utilisateurs. Définie comme un composant logiciel qui
regroupe les opérations passées entre les utilisateurs et les fournisseurs de services,
l’interface ne détaille pas les fonctionnalités techniques de l’implémentation
[Fournier-Morel, Grosjean, Plouin, Rognon, 2011, p. 49-50]. Elle est transparente et
standardisée afin de faciliter l’accès des utilisateurs aux diverses fonctionnalités de
l’entreprise. Le consommateur peut alors exécuter les processus souhaités en ayant
accès aux services via l’interface.
2.2.4. Composantes et principes de base
L’architecture orientée service est un style d’architecture moderne qui suit des
principes de modélisations modernes. Elle est découpée en plusieurs couches
composée d’une dimension présentation, d’une couche métiers et de données.
Les propriétés de base de l’architecture orientée service sont nombreuses et diffèrent
en
fonction
des
divers
concepteurs
de
l’approche
SOA.
Toutefois,
les
caractéristiques fondamentales nécessaires pour classer une architecture comme
étant une SOA sont aux nombre de deux : l’orientation service et le couplage faible.
Par la suite, nous allons analyser en détail ces deux principes acceptés comme étant
essentiels, par l’ensemble de la littérature et des auteurs de ce domaine.
L’orientation service
Défini comme étant la composante fondamentale de cette approche, le service
permet de relier les consommateurs et les fournisseurs sur une même interface,
partie visible de l’architecture par les utilisateurs. Essentiel pour l’architecture
orientée service, le service peut se définir de la manière suivante :
« Un service, au sens SOA, met à disposition d’acteurs (humains ou logiciels)
intervenants dans des processus métiers, un accès vers une ou plusieurs
fonctions métiers. Un service concrétise le lien entre la couche métier
18
(constituant le côté consommateur) et les implémentations dans le SI
(constituant le côté fournisseur) en prenant à charge un contrat (réalisé par le
pourvoyeur de service). » [Fournier-Morel, Grojean, Plouin, Rognon, 2011, p.
30].
Métier
Consommateurs
Technique
Pourvoyeurs
Fournisseurs
Figure 2-6: SOA, liaison entre vue métier et vue technique [Reproduction réalisée à partir de FournierMorel, Grosjean, Plouin, Rognon 2011, p. 3 ; Laftimi, CNAM 2009]
Le graphe 2-6 démontre les liaisons entre les deux niveaux d’architecture qui sont la
vue métier et la vue informatique, découpée encore en quatre architectures : métier,
fonctionnelle, applicative et technique qui correspondent respectivement aux
processus métier de l’entreprise, aux blocs fonctionnels et aux flux d’informations,
aux blocs applicatifs et finalement à l’infrastructure physique qui supportera les blocs.
Le service est perçu différemment en fonction qu’on soit un utilisateur ou un
informaticien.
Du point de vue de l’utilisateur, le service constitue le résultat visible de la SOA, sur
lequel il pourra travailler, faire des configurations, l’exploiter, définir des contrats de
services, etc. Le service métier est le produit que l’utilisateur va consommer à travers
une interface graphique pour exercer son activité. Un même service métier apparait
simultanément dans plusieurs processus différents, ce qui permet une dynamique
dans le système. Ce service doit être simple d’emploi, doit revêtir le caractère de
réutilisabilité et doit favoriser l’interopérabilité entre ses composantes vu qu’il va relier
plusieurs acteurs sur une interface présente sur le web. [Bonnet, Detavernier,
Vauquier 2008, p. 73-74].
Étant donné que l’utilisateur lambda n’est pas censé
connaître toute la technique derrière le service qu’il utilise, les résultats de la SOA
doivent être normalisés donc compréhensibles par tous. Comme le service doit
respecter un contrat de service, il doit offrir une garantie de qualité et exécuter sa
tâche de manière simple et concise [Fournier-Morel, Grojean, Plouin, Rognon, 2011,
p. 32].
Sous le regard de l’informaticien, le service est une notion plus complexe qui
s’apparente à une composante logique de la SOA avec une fonction déterminée.
Cette notion correspond à une application auto-descriptive présente via une interface
(en langage SOAP/WSDL, REST, etc.), qui communique par message et
indépendamment des autres services. Le service est modulaire, indépendant et
neutre. Pouvant être reliée à d’autres services, cette composante englobe les
données et les informations du système et masque de ce fait l’hétérogénéité du SI.
On obtient ainsi une vue logique des données compréhensible par tous [FournierMorel, Grojean, Plouin, Rognon, 2011, p. 34].
Afin d’atteindre des objectifs stratégiques, l’entreprise est amener à flexibiliser ses
systèmes d’informations et ainsi développer des services. Afin de maximiser la
flexibilité du système, les services doivent respecter quatre principes essentiels de
construction tels que l’autonomie, la réutilisabilité, l’interopérabilité et la composition
des services.
19

La réutilisation des services [Erl 2008, p. 254-259]
Le principal but de l’architecture orientée service est explicité par ce principe
de réutilisation de services dans les processus du système. Le but étant de
créer des architectures favorisant des modèles de systèmes ayant des
composantes réutilisables. En effet, dans toute création de système, on tente
de créer des fonctionnalités répondant à des critères précis. Chaque
fonctionnalité est spécifique à une tâche précise. Dans cette logique,
l’utilisation d’une fonctionnalité d’un service pour une autre tâche est quasi
impossible si l’on tient compte également du manque de communication entre
les services. L’implémentation de la SOA offre au service, la possibilité d’être
utilisé plusieurs fois, pour des tâches différentes et des utilisateurs différents.
Ainsi, les processus s’exécutent de manière continue dans le système et
permettent d’atteindre les objectifs visés par la firme plus rapidement [Erl
2006, p. 292]. Ceci consiste à la création d’un concept générique favorisant le
paramétrage des services sans difficulté. Le but est de dissocier les services,
auparavant dépendant des uns et des autres, afin de permettre des
modifications rapides, sans passer par une programmation entière du système
et sans perdre de temps [Bonnet, Detavernier, Vauquier 2008, p. 54].
De plus, avec la flexibilité véhiculée par ce principe, SOA offre aux
organisations la possibilité d’une performance conséquente avec une
optimisation des ressources à disposition.

L’autonomie et l’interopérabilité des services [Erl 2008, p. 294-298]
Afin de favoriser la réutilisation des services, il est primordial que chacun de
ces services soit autonomes et capables d’interagir avec les autres
composantes de l’architecture du système.
En général, les services sont très restreints au niveau de leurs champs
d’exécution. En dotant un service d’une certaine autonomie, ce dernier devient
capable de gérer ses ressources sans intervention externe [Erl 2006, p. 303304]. L’autonomie leur confère un contrôle significatif sur leurs champs
d’application. Les services métiers doivent être indépendants les uns des
autres, donc faiblement couplés. [Bonnet, Detavernier, Vauquier 2008, p. 54].
Ainsi, ils deviennent en mesure d’exécuter divers logiques métiers de manière
indépendante.
20
Toutefois, les services ne sont que très faiblement reliés entre eux,
empêchant ainsi une interaction au sein du système. Ceci engendre des
problèmes de communication entre les diverses composantes et empêche le
fonctionnement des processus en continu à cause des redondances, des
duplications, des erreurs, etc.
Pour pallier à ces problèmes, il est primordial d’établir une communication
entre les services, qui doivent interagir entre eux. Pour établir une
communication cohérente, cette architecture implémente les services
échangeant entre eux par messages et dans un langage standardisé (très
souvent XML). L’utilisation d’un vocabulaire métier uniformisé pour chaque
service permet l’intégrité du système. [Bonnet, Detavernier, Vauquier 2008, p.
83]. Les échanges entre les différentes composantes du système, favorisent
l’autonomie de ces composantes et permettent plus de flexibilité au système.

La composition des services [Erl 2008, pp. 388-392]
Afin d’augmenter la réutilisabilité des services, il faut les créer de manière
composée. Chaque service, composé d’unité modulaire, doit être regroupé par
niveau d’abstraction afin de séparer des logiques différentes telles que
processus, métier ou présentation [Bonnet, Detavernier, Vauquier 2008, p.
54].
Construite de manière composée, donc par l’assemblage de multitudes
d’unités modulaires et autonomes, les processus deviennent accessibles et
compréhensibles par tous comme l’illustre la figure 2-7 suivante. Une
commande passée par un service est interconnectée à tous les autres
services dont la présence est nécessaire pour accomplir la tâche en question.
La composition des services crée la possibilité de flux d’interactions entre les
services. De cette manière, la flexibilité et l’interaction règnent entre les
composantes.
21
Figure 2-7: Composition et interopérabilité [Fournier-Morel, Grosjean, Plouin, Rognon 2011, p. 36]
En somme, les services, au cœur du concept d’architecture orientée service,
encourage la réutilisation des composantes grâce à son caractère mutualisé dans un
environnement d’applications consommatrices, favorise l’interopérabilité grâce à des
intermédiaires internes au SI, et induit une fluidité dans les processus métiers via le
principe de composition.
Afin d’accéder aux fonctionnalités logicielles, les services d’une architecture orientée
service doivent passer par une interface standardisée. C’est pourquoi, les services
présents dans un tel concept se nomment les services web, application exposée par
le biais d'une interface sur Internet ou intranet. La réorganisation des applications en
ensembles cohérents encourage la communication entre des services dits
producteurs et des services appelés consommateurs [Journal du Net, 2007].
L’architecture orientée service a alors un rôle de courtier de service de ces
différentes composantes.
Le service web est l’élément essentiel de la structure des SI orientée service. Ces
services, comportant des fonctionnalités reliées entre elles, regroupent plusieurs
opérations qui seront ensuite présentes sur une interface et directement accessibles
22
par les consommateurs. À caractère réutilisable, les services web consistent en des
programmes permettant l’échange de données entre des applications et des
systèmes via intranet ou Internet et ceci sans intervention humaine. [Wikipedia 2013]
Il est également important de relever qu’un service est à portée de non seulement
des systèmes d’informations, des processus métier mais également des utilisateurs
via des applications composées. Ces applications consistent en des compositions de
processus de gestion par l’utilisation de service nouveaux ou existants [Hüsemann
2010]. De ce fait, un service qui fait partie intégrante d’une composition, se situe
dans un contexte de partage et d’échange avec les autres services. Il doit être pris
en compte avec toutes les autres composantes de l’application.
Le couplage faible
Le deuxième principe essentiel de la SOA est le couplage faible. Le couplage est
une métrique, d’intensité forte, moyenne ou faible, indiquant le niveau d'interaction
entre deux ou plusieurs composants logiciels [Wikipedia 2013]. Il correspond au
degré d’échange d’informations entre les composants d’un système.
À cause de la faible dépendance entre les services, l’interopérabilité entre ceux-ci est
limitée [Heutschi 2007, p. 33]. En vue de garder un haut niveau de flexibilité dans
l’architecture SI, le plus judicieux est de créer des services autonomes et
indépendants les uns des autres. Ainsi, les services sont alors plus facilement
maniables et modifiables en cas de dysfonctionnements.
Toutefois afin que l’ensemble du système fonctionne correctement, il est primordial
de maintenir des liaisons entre les composantes. Pour cette raison, les services de la
SOA sont reliés par un couplage faible : ils gardent leurs autonomies tout en étant
reliés les uns aux autres mais de manière moindre comme nous pouvons l’observer
dans la figure 2-8 ci-dessous. Ce niveau de couplage est essentiel dans la mesure
où les problèmes apparaissant dans une composante, n’empêchent pas le
fonctionnement de l’ensemble du système.
23
Figure 2-8 : Le couplage faible entre consommateurs et logique métier [Erl 2008, p. 188]
De plus, le couplage faible comporte de nombreux avantages autant pour le
consommateur que pour le pourvoyeur de services. En effet, afin de pouvoir utiliser
un service, le consommateur envoie un message au système via un protocole de
communication. Le pourvoyeur de service étant tenu par le contrat de service,
répond alors à la requête de l’utilisateur par le même ou un autre protocole de
communication [Fournier-Morel, Grojean, Plouin, Rognon, 2011, p. 51].
Selon les auteurs Fournier-Morel, Grojean, Plouin et
Rognon, les avantages
suivants peuvent être détenus par les fournisseurs et les consommateurs grâce au
faible couplage [Fournier-Morel, Grojean, Plouin, Rognon, 2011, p. 51-52] :
POURVOYEUR DE SERVICES

Augmentation de la diversité de
CONSOMMATEURS DE SERVICES

consommateurs

Augmentation de la diversité de
de connaître l’implémentation

fournisseurs


Maitrise de la garantie de la
Facilité d’utilisation sans besoin
Fiabilité de transaction avec un
contrat de service explicite

Changement possible de
qualité de ses services
fournisseur en cas de non-
Modification de l’implémentation
satisfaction
de ses services
24
3. L’impact d’une architecture orientée service dans l’entreprise
3. L’impact d’une architecture orientée service dans
l’entreprise
Tenant compte des besoins des entreprises, la SOA est dans l’obligation de
raisonner en tant qu’architecture d’entreprise. L’évolution technologique a favorisé
l’émergence et la présence de plus en plus importante des systèmes d’informations
au sein des organisations.
Pourtant le SI procure non seulement des avantages colossaux aux entreprises,
mais également une complexité significative au sein de l’organisation. La manière de
gérer l’organisation de la firme va également se transformer. La SOA, définie dans
cette logique comme une architecture d’entreprise, s’avère être la solution optimale
face à la complexité des SI. Sans pour autant la simplifier, ce concept met de l’ordre
dans les systèmes d’informations de l’entreprise.
Depuis son apparition, en 1996, cette démarche s’est développée et occupe
aujourd’hui une place importante sur le marché des approches d’intégration de
systèmes. Adopté par de nombreuses entreprises, SOA démontre ses qualités
encore aujourd’hui. En effet malgré la montée fulgurante du « Cloud computing »,
cette démarche architecturale arrive à se démarquer de la concurrence.
Lors de son lancement, la Gartner Group avait prédit à environ 75%, le nombre
d’entreprises ayant recours à SOA dans les années 2008. L’étude réalisée en 2011
par le groupe de recherche américain Forrester Research, le nombre d’entreprise
ayant recours à cette approche s’élevait à 80% (sur un échantillon de 1035
entreprises interviewées). L’efficacité de cette architecture peut être vérifiée par les
résultats de l’étude : avec un taux de pénétration du marché de 60% en Amérique du
Nord tout comme en Europe, la SOA est largement leader de son segment de
marché. La satisfaction des consommateurs de cette approche s’élève en
pourcentage à 81 pour l’Amérique du Nord, et à 73 pour l’Europe [CIO UK, 2011].
Une étude plus récente, réalisée en 2012 par le groupe de recherche française dans
les technologies de l’information Jemm Research & Jemm Vision, souligne que 86%
25
des entreprises analysés (sur un total de 21) ont engagé une démarche SOA, déjà
complétement intégrée dans leur système. Cette dernière étude appuie les
estimations de 1996 du Gartner Group [Jemm Vision & Jemm Research, 2012].
Avant d’engager un projet SOA, il est primordial de s’intéresser à trois principes
fondamentaux : l’aspect technique englobant la méthodologie nécessaire et les coûts
supportés par la démarche, ainsi qu’au point de vue organisationnel relié aux
modifications qui découlent de cette implémentation. Ces trois aspects sont analysés
dans la suite de manière regroupée.
3.1. D’un point de vue technique et financier
3.1.1. Méthodologie à suivre pour implémenter une SOA
La décision de débuter une approche SOA se fait graduellement en fonction des
besoins de l’entreprise, de l’évolution des technologies de l’information, ainsi que des
coûts émanant des systèmes actuels [Fournier-Morel, Grosjean, Plouin, Rognon
2011, p. 43]. De plus, l’intégration de la SOA dans l’organisation va bouleverser la
manière de travailler dans cette entreprise avec les moyens informatiques à
disposition. C’est pourquoi, une démarche SOA est séquencée en quatre phases : la
planification, la définition, la construction et l’implémentation ainsi que la supervision.
Il existe actuellement de nombreux fournisseurs de conception d’architectures
orientée services telles que IBM, Oracle, Microsoft, etc. qui offrent une solution de
base de cette approche. Toutefois, aucune des solutions proposées n’est dans la
capacité de répondre intégralement aux besoins des entreprises. Pour cette raison, il
est important de suivre minutieusement chaque étape de l’implémentation afin
d’atteindre les objectifs visés comme l’illustre la figure 3-1.
26
Figure 3-1: Phase de la démarche SOA [SOA Blog, 2010]
La première étape consiste à l’analyse des problèmes auxquels est confrontée
l’entreprise ainsi qu’à la définition des besoins de l’organisation. Le but étant
d’améliorer les lacunes dans le système pour gagner des avantages compétitifs face
à la concurrence. C’est à partir de la prise de conscience de ces problèmes et de ces
besoins, que l’on peut commencer une démarche SOA. Les potentiels de
développement découverts dans cette phase et les objectifs visés par les SI
permettront d’élaborer une stratégie adéquate en se basant sur l’évaluation des
diverses alternatives. Cette période est consacrée à l’élaboration des facteurs de
succès d’un projet SOA à savoir le budget consacré à la démarche, le programme de
mise en œuvre du projet, les acteurs qui vont y prendre part et principalement le
team de développement, les capitaux et les soutiens externes qui vont soutenir la
réalisation du projet [Krafzig, Banke, Slama 2006, p. 263]. Plus précisément, des
tâches telles que l’analyse des dispositifs déjà en place, l’identification des axes
d’amélioration et de progression, la définition des objectifs à atteindre et le choix des
outils d’évaluation d’atteinte des objectifs sont planifiés durant cette première phase
27
[SOA Blog, 2010]. On va identifier dans cette première partie comment une
démarche SOA peut nous aider à atteindre nos objectifs de base.
La seconde partie s’intéresse à la définition du modèle de référence de gouvernance
SOA (SGRM) à adopter afin de réaliser les objectifs définis dans la partie
précédente. La gouvernance SOA est selon certains auteurs une discipline et selon
d’autre une pratique informatique, qui permet le cadrage et le pilotage d’une
démarche SOA afin de garantir son succès. Elle peut être définie comme
« l’ensemble des moyens et des indicateurs qui permettent de prendre les bonnes
décisions au bon moment et de s’adapter rapidement en tenant compte des
risques » dans le cadre d’une démarche SOA [Fournier-Morel, Grosjean, Plouin,
Rognon 2011, p. 219]. Les principaux piliers d’une gouvernance sont l’organisation
(structures organisationnelles en place), les processus et la technologie. Chaque
action réalisée dans cette logique, est en relation avec un de ces piliers.
La phase de conception de l’infrastructure informatique constitue la troisième partie.
La création et le déploiement d’une architecture SOA sont les activités principales de
cette étape. Il existe trois techniques d’intégration différentes: l’intégration « top
down », l’intégration « bottom up » et l’intégration « outside in » communément
appelé « in the middle » illustré par le graphe 3-2 suivant [Liebhart 2007, p. 172].
Figure 3-2: Stratégie d'intégration [Xebia IT Architects, 2007
28
L’approche « top down » suit une logique descendante. Elle consiste à
commencer l’intégration par la définition des processus métiers et passer
graduellement à la définition des services métiers nécessaire au fonctionnement
des processus. Cette logique est poursuivie dans le but d’aligner le système
d’information sur le métier de l’entreprise [Erl 2006, p. 363]. Cette approche
permet de piloter l’architecture par les besoins métier tout en minimisant les
redondances des services [Xebia IT Architects, 2007]. Toutefois les coûts
engendrés par cette approche sont importants dans la mesure où elle nécessite
une refonte du SI.
La seconde stratégie d’intégration, nommé « bottom up » opère dans le sens
inverse de la précédente approche. Elle est réalisée dans les entreprises
possédant déjà un système d’information. La conception se déroule de
manière ascendante en commençant par identifier les fonctions existantes du
SI que l’on peut réutiliser en tant que service [Erl 2006, p. 366]. En se basant
sur un système déjà présent, l’entreprise peut récolter un gain sur les coûts
d’implémentation. Ce type d’intégration est meilleur marché qu’une intégration
top down, mais malheureusement pas plus profitable. En effet, elle consiste à
une réutilisation différente d’une fonction déjà existante d’un système, ce qui
ne permet pas une autonomie considérable des services qui restent encore
très dépendants à leur système de base [Xebia IT Architects, 2007].
Enfin, il existe une troisième approche intitulée « in the middle » ou « outside
in », qui se définit comme une combinaison des deux précédentes. Cette
stratégie consiste à développer les approches « top down » et « bottom up »
de manière parallèles pour obtenir des résultats plus pertinents, qui
permettront de déterminer la manière optimale pour définir les processus
métiers. Bien que risqué au moment de la réunion des deux approches, cette
stratégie offre un pilotage efficace de la SOA et favorise la réutilisation des
services.
29
Une fois toutes les décisions prises quant à la planification et à la stratégie de
conception, les solutions choisies sont alors appliquées. On se situe dès lors dans la
dernière phase de cette démarche : l’implémentation et la supervision. Durant cette
phase, il est important de réaliser chaque étape de l’implémentation en respectant le
temps et le budget à disposition, afin de ne pas engendrér de coûts supplémentaires.
Une fois l’architecture complétement implémentée, le système devient alors
fonctionnel. Cette dernière phase s’achève sur la vérification de l’efficacité du
système, de la supervision de l’atteinte des objectifs, du suivi des performances du
projet et sur une formation fournie aux usagers du système pour une utilisation
optimale [Debray,IBM Software Group, 2005].
3.1.2. Coûts de l’approche
L’adoption de tout nouveau système implique des coûts plus ou moins élevés. Dans
les projets informatiques, ces coûts sont en général très élevés tenant compte des
coûts de conception, de mise en place, d’entretien, de maintenance ou encore
d’échec. Dans cette section, nous allons analyser les principaux frais émanant d’une
démarche SOA en exposant des chiffres tirées d’études réalisées sur le coût de la
SOA.
Les principaux frais activés émanent surtout au niveau de l’implémentation et de la
maintenance du système. Il est difficile de quantifier exactement les montants
nécessaires à une implémentation SOA sachant, qu’ils dépendent de l’ampleur du
projet SOA et de ce fait, des moyens nécessaires à son élaboration. Afin de mieux
cerner l’importance du poids des coûts dans une démarche SOA, il est intéressant
d’analyser différentes études réalisées à ce jour.
Une étude réalisée en 2006 par le GCR Gartner Custom Research, démontre les
différences de stratégies de coûts SOA entre les USA et l’Europe. En Europe, la
tendance est plutôt de réaliser des économies sur les coûts SOA alors qu’aux USA,
les stratégies sont orientées vers le développement de l’agilité SOA. Les principales
dépenses de cette démarche sont dues aux ESB, aux logiciels de sécurité ainsi
qu’aux outils de gestion du système. Ces dépenses représentent selon l’étude,
30
environ 40% du budget alloué à la démarche alors que les dépenses liées aux
ressources humaines constituent la part plus importante du budget, à savoir dans les
alentours de 54% [Le Monde Informatique 2006].
En comparaison, une étude
réalisée en 2008 par IBM estime à 20% le coût initial de développement et à 80% les
coûts de maintenance du projet sur la base du cycle de vie du projet SOA [IBM
Corporation 2008].
Selon des recherches menées conjointement par l’Université de St-Gall et le groupe
SAP en 2008, il existe une multitude de catégories de coûts engendrés par une
implémentation SOA. Ces coûts sont détaillés à la page 77 dans l’annexe 1, intitulée
« SOA Infrastructures Costs ».
Les principaux coûts recensés sont en termes [SAP AG, University of St. Gallen,
2008, p.23] :

D’investissement dans les infrastructures hardwares et softwares comprenant
les infrastructures physiques et les coûts de licence

De dépenses d’implémentation impliquant les coûts de gestion de projet ainsi
que des tests

Des coûts d’opérations au niveau des services et des systèmes

De gouvernance du concept

De dépense en IT Change Management impliquant les coûts de changements
organisationnels et de formation
Bien entendu, il existe encore d’autres coûts à ne pas négliger telque les coûts de
sécurité informatique, de gestion des systèmes ou encore des coûts implicites
d’effort et de performance [Gartner Group 2008, p. 21]
Vu le nombre croissant d’entreprise ayant recours à cette architecture, les coûts
engendrés deviennent un facteur décisif concernant l’adoption de la SOA. Une étude
menée en 2008 par le groupe de recherche américain IDC, sur les grandes
entreprises ayant implémenté SOA souligne ce fait. Selon cette étude, le nombre
d’entreprises ayant engagés des démarches SOA s’élevait à 53% et les dépenses
annuelles moyennes de chacune de ces firmes approchaient les 1.4 millions de
dollars [Le Monde Informatique 2008]. Lors d’une conférence d’IDC tenue en 2010,
31
la progression des dépenses pour les architectures orientées services fut estimée à
25% entre 2008 et 2013, tout en soulignant que cette croissance sera tirée par la
région Asie/Pacifique. Le vice-président d’IDC, Ruediger Spies souligne tout de
même que ces dépenses sont justifiées lorsqu’on observe les effets de la SOA sur le
long terme [Le Monde Informatique 2010].
Figure 3-3: Comparaison de la structure des coûts des technologies de l’information d'une approche
traditionnelle et d'une SOA [BEA SYSTEMS, 2005]
En effet, un programme SOA se différencie des logiciels traditionnels par sa capacité
de création de valeur de manière plus significative et importante que les projets
logiciels [BEA SYSTEMS, 2005]. Les coûts initiaux élevés s’amortissent au fil du
temps, une fois que les infrastructures SOA sont parfaitement implémentées comme
explicité dans la figure 3-3 ci-dessus.
Bien que les coûts émanant d’une initiative SOA soient élevés, les technologies de
gouvernance SOA restent un des plus importants secteurs en croissance du marché
des infrastructures et du middleware applicatif, générant des revenus de plus de 17.6
milliards de dollars en 2011 [Gartner Group 2011].
32
3.2. D’un point de vue opérationnel et stratégique
3.2.1. Changement dans l’organisation
L’introduction d’une architecture orientée service dans un système déjà existant va
bouleverser son fonctionnement. Toute l’organisation sera touchée par le
phénomène et en sera profondément modifiée. Cette mutation concerne non
seulement le fonctionnement organisationnel mais également la culture même de
l’entreprise.
De part cette approche, on tente de casser les silos du système [Cf. Chapitre 2.2.1]
pour créer une entité dans lequel tous les départements sont reliés et partagent les
ressources à disposition. Par le partage d’information, la SOA pose les principes de
base d’une organisation homogène sur la base d’un système standardisé. Cela
implique une vision globale de l’organisation, qui est gérée par la gouvernance SOA.
L’infrastructure mise en place relie tous les acteurs de ce système qui peuvent
désormais interagir de manière optimale. Ainsi la SOA optimise toutes les ressources
de l’entreprise. Les buts organisationnels poursuivis par l’implémentation de cette
approche sont [Fournier-Morel, Grosjean, Plouin, Rognon 2011, p.170] :

La mise en place d’un cadre pour l’accomplissement de projets SOA

L’amélioration de l’alignement des besoins métiers et des réponses
techniques

La mise en place d’un outil de communication entre les acteurs internes et
externes du système

La mise en place d’un outil de planification des évolutions du système
Les répercussions directes dans le mode de fonctionnement de l’organisation sont
nombreuses. On en peut relever quelques-unes. Le projet SOA permet par exemple
une augmentation de l’efficacité des systèmes, étant due à l’adaptabilité des
processus. Favorisant la réutilisabilité des composantes, on peut également observer
des améliorations concernant la réduction des délais de mise en œuvre et de la
diminution des coûts informatiques [Bonnet, Detavernier, Vanquier 2008, p. 50].
33
34
Toutefois, un changement aussi important dans l’organisation nécessite du temps à
sa mise en place et à son acceptation par tous. Les utilisateurs ont besoin d’un
temps d’adaptation pour se familiariser avec le concept. Il est alors nécessaire de
faire changer les mentalités des acteurs face à ce changement, en les formant à ce
nouveau concept.
3.2.2. Attentes de cette approche
Suite à l’évolution fulgurante des technologies de l’information et la concurrence de
plus en plus rude, le besoin d’agilité s’est fait ressentir dans toutes les organisations.
Il fut primordial de casser les silos des SI et créer des systèmes interopérables.
L’agilité, étant la capacité de réagir rapidement aux changements, est devenue le
mot clé de toute évolution informatique.
SOA est désormais considérée comme une « refonte intelligente du système
d’information, alignées sur les besoins métier, lissée dans le temps et permettant la
cohabitation entre les anciens et nouveaux applicatifs » [Bonnet, Detavernier,
Vanquier 2008, p. 43]. Avec de telles qualités, la SOA s’inscrit à deux niveaux dans
une entreprise : stratégique et opérationnel.
Sur le plan stratégique, ce concept s’inscrit dans la gouvernance des technologies de
l’information. L’approche doit permettre la gestion d’un portefeuille des solutions SOA
(les applications composites) et d’un portefeuille des services [IT- Expert Magazine,
2011]. Au niveau de la stratégie d’entreprise, elle doit favoriser le déploiement
d’outils de mesures pour analyser le rapport coûts/bénéfices et promouvoir le partage
et la compréhension de la stratégie générale [BEA Systems, 2005]. Ainsi les
décisions stratégiques seront prises en tenant compte d’un point de vue global.
Sur le plan opérationnel, ce concept se réfère surtout aux phases de conception, de
déploiement et d’exécution de la mise en place d’une démarche SOA. En effet,
l’opérationnel englobe l’implémentation des processus de gestion des cycles de vie
des services et des applications composées [IT- Expert Magazine, 2011].
À ce
niveau, la SOA doit se définir comme un style architectural dynamique et
standardisée, réduisant les redondances des fonctionnalités du système et favorisant
la réutilisabilité des processus [BEA Systems, 2005].
4. Avantages de l’architecture orientée service
Depuis la montée en puissance du Cloud computing durant ces dix dernières
années, le concept d’architecture orientée service est souvent remis en question
dans le domaine informatique. On peut apercevoir une division entre les partisans de
ce concept d’un côté et les promoteurs du Cloud de l’autre côté. Les articles
scientifiques criant à la fin du SOA se multiplient. Pourtant les statistiques, comme vu
précédemment, démontre le contraire. A ce niveau, la question se pose alors : SOA
a-t-elle encore une utilité actuellement ? Quelles sont les arguments favorisant
l’adoption de ce concept de nos jours ? Pourquoi opter pour une démarche orientée
service ?
Dans ce chapitre, nous allons analyser les principaux avantages d’une architecture
orientée service sur le plan organisationnel, technique et financier afin de souligner
les avantages découlant de l’adoption d’une SOA dans les infrastructures
informatiques actuellement. Pour cela, nous allons nous baser sur plusieurs études
réalisées à ce jour tout en complétant avec la littérature existante.
4.1. Au niveau organisationnel : la flexibilité du système
Le principal but poursuivi par les entreprises est de se démarquer de la concurrence
pour gagner des parts de marchés et faire des profits. Toutes les théories
économiques l’ayant confirmée, seule une innovation continuelle peut amener à une
position compétitive sur le marché. Pour ceci, il est primordial de s’adapter facilement
et rapidement aux évolutions du marché. Tout retard face aux changements coûte à
l’entreprise non seulement en terme financier mais également en matière de perte de
clients. Dans cette logique, la flexibilité des entreprises face aux évolutions s’avère
être la clé de réussite pour maintenir la satisfaction des clients et le maintien des
parts de marché. Sachant que la majorité des processus d’entreprises sont
informatisés, la flexibilité technologique devient alors un des sujets fondamentaux du
bon fonctionnement de l’organisation.
35
La flexibilité technologique se définit comme « la capacité de la technologie à se
transformer et à s’adapter au rythme des activités d’une façon aisée et au moindre
coût possible » [Soto, IBM Corporation, 2008, p. 2]. Dans cette optique, l’architecture
orientée service permet la possibilité de créer un environnement technologique
flexible grâce à la standardisation des infrastructures et la décomposition des
applications en services. En effet, ce concept favorise l’agilité par le découpage des
structures applicatives en des composantes, créant une division nécessaire au bon
fonctionnement de l’organisation. Ainsi, les métiers sont construits de manière
alignée aux processus de l’entreprise, qui deviennent automatisés [Raymond,
Softeam, 2011, p. 5]. La standardisation des technologies de l’information est alors à
la base de l’interopérabilité des composantes en favorisant la gestion des processus,
désormais indépendants des services. Toute modification apportée à une
composante du système n’affecte que le service en question sans porter préjudice à
toute autre composante.
Toutefois, les systèmes d’informations ne sont pas des blocs homogènes. Chaque
système est composé de silos applicatifs, de progiciels, de services, etc. qui doivent
interagir les uns avec les autres afin d’être performants. L’importante ampleur de la
communication et du partage d’informations entre ces entités, dote le système d’une
complexité non négligeable [Bonnet, Detavernier, Vauquier 2008, p. 259]. Afin de
contrer la complexité, la SOA se présente comme une solution adéquate en cassant
les silos (barrières organisationnelles). Cette démarche rationalise les échanges
avec un langage commun et gère l’augmentation des flux d’informations grâce à une
structure organisée et standardisée [Holley, Dr. Arsanjani, 2011, p.59].
D’un point de vue économique, les attentes des entreprises de cette démarche sont
diverses. Le graphe 4-1 suivant, tiré d’une étude réalisée en 2009 par le groupe de
recherche Wolfgang Martin Team, illustre les divers motifs de choix économiques
lors de l’adoption d’une démarche SOA. Suivant l’ordre d’importance dans la prise de
décision, nous pouvons citer la haute flexibilité du système, l’optimisation des
processus, la réduction du temps de développement, l’accroissement du ratio
d’innovation et finalement l’augmentation de la production.
36
Figure 4-1: Motifs de choix lors de l'adoption de démarche SOA [SAP AG, University of St. Gallen, Saat,
Discher, 2009, p. 4]
La transformation de l’ensemble du réseau informatique de l’entreprise en le dotant
de la flexibilité, offre de nombreux avantages tels que l’augmentation des bénéfices
induit par une modification de la stratégie informatique, des marges de profits
émanant de l’accroissement de la production ou encore un gain sur le temps de
développement des produits et des services [SAP AG, University of St. Gallen, Saat,
Discher, 2009, p. 18]. Une technologie flexible comme le concept SOA, peut
révolutionner le fonctionnement des systèmes et permettre ainsi aux entreprises de
devenir plus compétitives.
4.2. Au niveau technique : la réutilisabilité des ressources
D’un point de vue technique, l’implémentation SOA contribue amplement à la
réduction de la complexité du système grâce à ses fonctionnalités réutilisables et ses
services indépendants. En effet, le principe de base de la démarche SOA est de
créer des services réutilisables afin d’optimiser les ressources au sein de l’ensemble
du système. Lors de sa conception, les services métiers sont élaborés de manière à
pouvoir être réutilisés d’une part afin de simplifier les processus, d’autre part pour
réduire les coûts de développement des projets.
37
Par la possibilité de réutilisabilité des composantes déjà existantes, nous pouvons
réaliser des économies en dépenses et en temps nécessaire à la réalisation de
nouveaux projets [Erl, 2007, p.506]. Ainsi un service déjà existant pourra être
invoqué à nouveau par lui-même pour réaliser des tâches déjà exécutées mais
également d’autres lignes de services pourront s’y référer [Raymond, Softeam, 2011,
p. 5]. De cette sorte, les tâches exécutées par les services métiers sont
automatisées, et les services sont mutualisés et ceci en moins de temps que les
autres types d’architecture d’intégration. Ainsi, par l’augmentation de la capacité de
réutilisabilité des services, la SOA diminue les redondances et les erreurs pouvant
apparaitre dans le système tout en accélérant le temps d’automatisation des
processus.
L’orientation
service
des systèmes simplifie
également
les problèmes de
maintenance grâce à sa structure organisée. Garantissant une intégration
standardisée avec des composantes interopérables, l’architecture SOA améliore
l’aptitude d’exploitation du système [Bonnet, Detavernier, Vauquier 2008, p. 300301]. En effet en assurant un maximum d’indépendances entre les services, on peut
empêcher par exemple les répercussions néfastes du dysfonctionnement d’un
service sur toutes les autres composantes du système. Le problème n’affecte que le
service concerné sans empêcher le fonctionnement des autres services.
L’interopérabilité permet d’une part la standardisation des protocoles pour un meilleur
échange entre les services, et d’autre part la transformation des données entre les
services consommateurs et les services producteurs [Bell 2006, p. 229-230].
L’indépendance totale entre les composantes crée la neutralité technologique sans
contrainte de technologies ou de localisation des services. Ainsi l’échange
d’informations entre les divers services est exécuté de manière adéquate pour une
meilleure communication dans l’ensemble des composants du système.
38
4.3. Au niveau financier : la baisse des coûts
La plus importante valeur ajoutée du concept d’architecture orientée service est sa
capacité de réduction des coûts sur le plan financier. Une étude réalisée en 2008 aux
États-Unis par le GCR Gartner Customer Research, démontre les attentes des
entreprises vis-à-vis d’un projet SOA [IBM Corporation 2008]. Il ressort de cette
étude que le motif principal à la base d’une adoption du concept SOA est d’ordre
financier.
En effet dans un panel de 151 utilisateurs SOA, 30% ont indiqué avoir choisi ce
concept dans le but de réaliser des économies sur les coûts IT comme explicité sur
la figure 4-2. Nous pouvons en déduire l’ampleur de l’importance des coûts
engendrés par des projets IT dans les organisations surtout lorsqu’on travaille avec
des concepts non agiles.
Figure 4-2 Principales attentes des entreprises d'une démarche SOA [IBM Corporation 2008]
39
Ces dépenses IT souvent très élevées, englobent non seulement les coûts IT de la
mise en place de nouvelles infrastructures informatiques et de changements qui
suivent l’implémentation, mais également les coûts d’opportunité implicites dans le
cas où le changement n’opère pas en temps voulu [Soto, IBM Corporation, 2008, p.
2]. En effet, la mise en place de ce concept regorge des coûts initiaux exorbitants
dus à l’installation technique, qui seront amortis avec le temps. Sur le long terme, il
est très probable de réaliser des économies sur les coûts essentiellement dus à la
réutilisabilité des composantes.
L’approche SOA, se démarque des approches conventionnelles grâce aux
fonctionnalités qu’elle offre en termes de flexibilité et de baisse des coûts. La figure
4-3 met en relation la structure des coûts de maintenance d’une approche orientée
service et d’une approche d’intégration conventionnelle en accentuant leur évolution
au fil du temps.
Figure 4-3: Investissement initial et rendement à long terme des capitaux investis [Madsen, Loureiro,
Groupe CGI, 2006]
Nous pouvons observer qu’au début du projet, les coûts engendrés par la SOA sont
supérieurs aux coûts
des approches traditionnelles mais qu’avec le temps, la
tendance s’inverse. Sur le long terme, le concept d’architecture orientée service est
plus bénéfique au niveau de l’amortissement des coûts de maintenance et permet
40
même de réaliser des marges importantes sur ces coûts par rapport aux méthodes
traditionnelles d’intégration.
La baisse des coûts est notamment due à deux principes majeurs : la réutilisation et
l’interopérabilité des services. Le fait de pouvoir réutiliser les services à maintes
reprises, offre des possibilités d’épargne sur les quatre sources de dépenses IT : les
coûts des projets, les coûts de maintenance, les éventuels changements futurs et le
retour sur investissement.
L’utilisation d’une approche orientée service dans des projets, réduit les coûts de
ceux-ci dans la mesure où elle favorise une implémentation et un déploiement plus
efficient que des approches conventionnelles. Nous pouvons ainsi réaliser des
économies lors de la modification d’un code, de l’intégration de nouveaux modules,
des tests de réussite de projets et lors de la configuration des processus
d’entreprises tout au long du projet, et ceci sans frais supplémentaires [Krafzig,
Banke, Slama 2006, p. 243-244].
Au niveau de la maintenance, les coûts du système sont fortement diminués lorsque
celui-ci est intégré avec une SOA. En effet, la recomposition des services modulaires
et le couplage faible vont simplifier les processus. De ce fait, les dépenses engagées
par la maintenance, les modifications et l’entretien seront réduits [Krafzig, Banke,
Slama 2006, p. 244].
Une autre source de dépenses de toute infrastructure informatique sont les frais
émanant des changements et des évolutions du marché. Afin de faire face à ces
changements, l’entreprise a besoin d’un certain temps d’adaptation qui va coûter à
l’entreprise en termes de bénéfice net et de chiffre d’affaire. SOA s’avère être la
solution adéquate à ce problème. Grâce à son infrastructure standardisée, la SOA
supporte tous types de modifications au cours du temps. De plus, elle est facilement
maniable grâce à la modularité des services réutilisables qu’elle met à disposition. A
long terme, la SOA s’adapte aisément par une intégration facilitée de nouvelles
composantes [Krafzig, Banke, Slama 2006, p. 244].
41
Enfin, il est possible d’obtenir des retours sur investissements ROI (Return On
Investment) importants avec ce type d’architecture. En effet, sur le long terme, les
coûts initiaux élevés sont amortis. La flexibilité offerte par la SOA est très souvent
décrite comme la raison des possibilités de retour sur investissement [Holley, Dr.
Arsanjani, 2011, p. 28]. Même si mesurer le ROI de la SOA reste une tâche
complexe à réaliser, il existe tout de même des techniques de calculs de la valeur
commerciale de SOA exprimé en valeur monétaire. Toutefois, lors du choix d’une
démarche SOA, les chiffres du ROI ne sont pas significatifs. Il est nécessaire de tenir
compte la stratégie choisie et des objectifs visés pour parvenir à une décision avant
d’opter ce concept.
En somme, les avantages de la SOA offrent à l’entreprise une position compétitive
sur le marché par la flexibilité et une meilleure profitabilité économique grâce à la
réduction des coûts [Gartner Group 2008, p.12].
42
5. Etudes de cas
5. Etudes de cas
Cette seconde partie du mémoire, recense des expériences de la vie pratique
concernant l’architecture orientée service. Le principal objectif étant de prendre
conscience de la réelle utilité du concept de SOA sur la base d’expériences
d’utilisateurs de cette approche et de comprendre comment et pour quelles raisons
cette démarche est appliquée par les entreprises. Même que cette approche a été
élaborée, il y’a déjà quelques années, elle reste malgré tout pas très commune sur le
marché européen et particulièrement en Suisse. C’est pourquoi, réaliser cette partie
fut intéressant et enrichissant pour venir en appui à la partie théorique. Les
expériences récoltées dans la suite du travail, permettent de prendre conscience de
l’application réelle de cette démarche ainsi que les vraies raisons à la base de son
adoption.
Deux difficultés majeures se sont réellement posée dans cette partie du travail.
Premièrement, recenser des institutions utilisant ce type d’architecture fut laborieux,
dans la mesure où les substituts de ce concept sont nombreux. En effet, il existe
plusieurs méthodes d’intégration, et SOA en est une parmi d’autres. Même si ses
avantages sont nombreuses, moult entreprises préférèrent utiliser d’autres types
d’architectures que SOA pour diverses raisons. Ensuite, la seconde difficulté fut
l’accès à l’information. Bien entendu toutes les entreprises agissent dans le cadre de
la confidentialité des données. De ce fait, certaines informations concernant les
études de cas suivantes seront citées de manière anonyme surtout en ce qui
concerne la seconde entreprise. Le principal but demeure dans l’information ellemême et non dans l’entreprise qui l’a fourni. Nous pouvons encore relever un autre
aspect qui est la collaboration avec les firmes rendus difficile soit à cause de la
distance géographique soit à cause du manque de disponibilité, mais tout à fait
compréhensible de la part des entreprises.
43
5. Etudes de cas
Ces études de cas portent d’une part sur une entreprise privée qui est une grande
compagnie d’assurance et dont le nom ne sera pas cité pour cause de
confidentialité, ainsi que sur une organisation autonome mais publique qui est l’Office
de la Circulation et de la Navigation du canton de Fribourg. Les divers éléments
discutés dans la suite émanent d’un questionnaire identique, traduit en français et en
anglais, adressé à chacune des deux entreprises. J’adresse ma reconnaissance à M.
Philippe Savary, Chef du service IT de l’OCN ainsi que la responsable IT de la
compagnie d’assurance pour leur collaboration et pour le temps qu’ils ont consacré à
la concrétisation de cette partie du travail.
Les informations citées et utilisées dans la suite proviennent des études de cas
réalisées avec les entreprises. Ces études de cas se sont déroulées en deux parties.
Premièrement une série de question ouvertes, identiques pour les deux entreprises,
ont été adressées aux interlocuteurs. Les réponses à ces questions ont été étudiées
dans divers sous-chapitre, en faisant une synthèse de chacune. Ensuite, afin de
comprendre les avantages procurés par l’adoption de l’architecture orientée service
au sein des systèmes informatiques, les entreprises ont dû remplir une grille
d’évaluation. Les principaux avantages au niveau organisationnel, technique et
financier d’une implémentation SOA y étaient exposés. Chaque entreprise a été
priée de remplir cette grille de manière la plus adaptée et réaliste en fonction de leur
situation. Sur la base des résultats obtenus dans ces questionnaires, une analyse a
été réalisée dans la dernière partie de chaque étude de cas.
44
5. Etudes de cas
5.1. Office de la Circulation et de la Navigation du canton de
Fribourg
La première étude de cas repose sur une organisation autonome mais publique de
l’Etat de Fribourg, qui est l’Office de la Circulation est de la Navigation, plus
communément appelée l’OCN.
Ce sous-chapitre se concentre sur l’expérience, en termes d’architecture orientée
service, dans le domaine de la sécurité routière. Les informations utilisées par la
suite proviennent d’une étroite collaboration avec le chef du service IT de l’OCN,
Monsieur Philippe Savary, sur la base d’un questionnaire, lui étant destiné et d’un
échange par courriel électronique.
5.1.1. Portrait de l’organisation
L'Office de la Circulation et de la Navigation (OCN), dont le siège principal se situe à
Fribourg, opère dans les activités liées à l’admission des personnes et des véhicules
à la circulation routière et à la navigation, aux autorisations nécessaires à toutes
catégories de circulation et navigation, à la perception des impôts sur les véhicules
et les bateaux, à l’organisation de cours de prévention, ainsi qu’aux diverses
activités administratives [OCN 2013].
Avec un effectif de près de 100 collaborateurs, cet établissement autonome de droit
public est géré selon les principes de l’économie d’entreprise. Les impôts prélevés
sur les véhicules et les bateaux, s’élevant à près de 90 millions de francs suisses,
sont entièrement versés à l’Etat de Fribourg. Cet établissement supervise la gestion
de plus de de 220'000 conducteurs et 235’000 véhicules dans le canton. La qualité
des prestations offertes, qui est orientée selon les attentes de leur clientèle, est
d’importance capitale. D’ailleurs la performance de leur service ainsi que la qualité de
leurs prestations sont souvent certifiés par des accréditations.
45
5. Etudes de cas
5.1.2. Présentation du système informatique de l’établissement
À l’OCN, le domaine informatique ne fait pas partie intégrante du « Core Business
Management » de l’établissement. Toutefois, étant donné l’ampleur et l’importance
des données informatiques, ce domaine demeure essentiel au bon fonctionnement
de l’ensemble du système. Ce domaine est géré par Monsieur Philippe Savary, chef
du service IT.
Le système informatique de l’OCN se compose d’un (pro)logiciel d’entreprise nommé
CARI ainsi que d’une multitude d’applications hébergées soit localement soit à
l’OFIT1 étant donné qu’elles sont exploités au niveau national. CARI est une
application métier utilisée pour par quatorze services des automobiles et de la
navigation dans l’ensemble de la Suisse [Abraxas CARI 2011].
Elle fonctionne de manière simplifiée selon la figure suivante.
Figure 5-1: Fonctionnement du logiciel CARI
1
L’OFIT est l’Office Fédéral de l’Informatique et de la Télécommunication qui s’avère être l'un des
fournisseurs internes de prestations informatiques de l'administration fédérale [Confédération Suisse
2013].
46
5. Etudes de cas
Le logiciel CARI se caractérise par une série de processus standardisés permettant
de relier plusieurs modules et les bases de données ainsi qu’avec les partenaires
internes et externes comme nous pouvons le voir dans la figure 5-1 [Abraxas CARI
2011]. De cette sorte, les services publiés sur Internet permettent d’intégrer les
clients et les partenaires externes directement dans les procédures internes.
Le paysage applicatif de l’entreprise se représente alors de la manière suivante :
Figure 5-2: Paysage applicatif de l'OCN
Comme le décrit la figure 5-2, le paysage applicatif de l’OCN est constitué de divers
logiciels et éléments reliés entre eux. Le logiciel principal CARI est en quelque sorte
le socle de l’ensemble du système. Il gère une multitude de modules à lui seul
comme la comptabilité débitrice, les relations avec les partenaires internes et
externes, les questions relatives à l’administration, etc. L’architecture orientée service
apparait dans ce paysage au niveau de ce logiciel CARI. Elle est mise en œuvre à
l’intérieur même du logiciel et facilite toutes les relations présentées dans la figure 52 par des flèches. Il existe d’autres logiciels plus spécifiques tels que CarD pour
l’impression des permis de conduire sous la forme de carte de crédit ou encore des
logiciels de gestion comme Abacus. L’OCN dispose également d’une plateforme
Internet comme moyen de communication. Elle est en constante collaboration avec
d’autres organisations externes grâces à divers applications telles que FABER,
47
5. Etudes de cas
ADMAS, RIPOL, MOFIS, TARGA, Sari, etc. qui sont hébergées soit par l’OFIT
(appelée BIT en allemand) ou soit par des serveurs locaux.
Malgré son statut d’autonomie, l’OCN reste une entreprise de droit public et pour
cette raison, elle collabore tout de même avec le service informatique de l’Etat de
Fribourg, nommé le SITEL, qui héberge pratiquement l’ensemble des services
utilisés.
5.1.3. Description du projet SOA et dans son évolution au fil du temps
L’architecture orientées service fait partie du l’architecture logicielle de l’OCN. Elle
est mise en œuvre dans le logiciel CARI, spécifique pour les services automobiles de
l’ensemble de la Suisse (implémentées dans quatorze cantons). Ce type
d’architecture est le plus adapté aux besoins informatiques rencontrés dans ce
domaine, grâce à sa couverture fonctionnelle. L’architecture orientée service n’a pas
été introduite dans le système informatique de l’Office en tant que projet à part
entière. Elle n’est exploitée que dans le service informatique de l’établissement au
niveau de l’architecture logicielle.
Cette démarche informatique est née dans la stratégie informatique de l’Office de la
Circulation et de la Navigation suite à plusieurs contraintes imposées par d’autres
organisations.
D’une part, l’Office a du faire recours à ce type d’architecture dans le prolongement
des décisions prises par l'Office Fédéral des Routes (OFROU) et l'Office Fédéral de
l'Informatique et des Télécommunications (OFIT). Ces deux partenaires jugeaient
nécessaire la mise en place d’un support de centralisation des données de gestion
au niveau national en ce qui concerne le domaine des permis de conduire avec
l’application FABER, celui des permis de circulation avec l’application MOFIS et celui
des mesures administratives avec l’application ADMAS. Le principe consistant était
de centralisé l’information gérée au niveau cantonal directement au niveau fédéral.
Toute information validée par un canton doit être communiquée et validée au niveau
fédéral grâce à un processus actif en temps réel.
48
5. Etudes de cas
D’autre part, l’OCN fait partie d’une association des services automobiles nommée
asa. Cette association œuvre pour le respect des prescriptions sur la circulation
routière de manière uniforme dans l’ensemble du pays [ASA 2013]. Elle travaille
continuellement sur des projets de développements informatiques et d’échanges de
données dans le but de standardiser les processus cantonaux pour assurer une
uniformisation des applications utilisées. Par la standardisation des processus, il
devient alors possible de réduire les coûts informatiques de l’ensemble des membres
de l’association. Le meilleur exemple que l’on peut citer dans cette étude de cas est
celui de l’application CarD développée pour permettre l’impression des permis de
conduire au format de carte de crédit directement dans les offices d’automobiles.
Cette application à elle seule permet une réduction importante des coûts de
développements. De plus, elle a également lancée des projets d’échanges de
données, par exemple pour les questions d’assurance de responsabilité civile, afin
de simplifier les tâches administratives d’une clientèle commune.
Cet environnement nécessitant l’intervention de différents acteurs a contraint l’OCN a
à restructurer son système grâce à une architecture plus flexible comme la SOA, afin
de répondre à tous ces changements et ces obligations qui lui ont été imposées.
Cette technologie orientée service, décrite par Monsieur Savary comme une « mise
en place des services informatiques, à forte intégration mais avec un faible couplage
au niveau de la maintenance, afin de garantir son optimisation » est exploitée à
divers niveaux du système. Tout d’abord, elle intervient notamment dans les
communications qu’entretient l’OCN avec les applications informatiques fédérales
telles que FABER, ADMAS ou MOFIS utilisées par d’autres organisations.
L’intégration avec SOA, facilite les échanges avec ses partenaires externes.
Ensuite, les relations informatiques entretenues avec les compagnies d’assurance,
qui délivrent les attestations d’assurance de responsabilité civile RC pour
l’immatriculation des véhicules et également des bateaux sont améliorées. En guise
d’exemple, nous pouvons observer la figure 5-3 qui représente l’architecture des
services mises en place par une compagnie d’assurance dans les activités de
délivrance des attestations nécessaires pour autoriser l’immatriculation ou la mise en
circulation d’un véhicule.
49
5. Etudes de cas
Figure 5-3: Architecture des services en relation avec les activités d'assurance
La partie supérieure de la représentation explicite les quatre interfaces nécessaires
apparaissant dans ce type d’activités alors que la partie inférieure décrit les relations
étapes par étapes pour la réalisation de cette activité. L’architecture orientée service
favorise la réalisation de ces relations. Les services utilisés via une architecture SOA
permettent une communication claire entre les diverses composantes du système
sachant que tous ces échanges d'informations sont basés sur des web services (en
langage XML).
50
5. Etudes de cas
Enfin, l’implémentation de la SOA dans cette infrastructure informatique permet à
l’OCN, une marge d’indépendance dans la réalisation de certaines tâches
directement dans leur système grâce au couplage faible. Par exemple, le système
assure la production de permis de conduire au format de carte de crédit, et ceci
grâce à la communication qu’elle peut facilement entretenir avec des applications
externes. L’architecture orientée service facilite également la communication de la
firme avec ses clients directement sur leur site internet via des quiz et des
formulaires et services présents sur le web.
L’OCN ne développant pas directement ce type de services elle-même, ces derniers
proviennent de sociétés de service externes spécialisées dans le développement
informatique. En somme, l’architecture orientée service n’a pas été implémentée
dans cette firme en tant que projet mais plutôt tel qu’un prolongement informatique
nécessaire face aux changements continuels des technologies de l’information.
Toutefois ceci ne signifie pas qu’aucun coût a été engendré pour sa mise en œuvre.
Depuis 2001, la mise en place de l’architecture orientée service a activée des coûts
d’investissement dépassant plusieurs millions de francs suisses qui représentent des
sommes considérables.
De par son caractère d’organisation publique, l’OCN est tenu de respecter des
exigences standardisées imposées par l’Etat dans le but d’uniformiser les systèmes.
L’Office est dès lors dans l’obligation de se mettre à jour pour travailler sur la base
d’applications standardisées au niveau national.
5.1.4. Objectifs visés par l’adoption de SOA et grille d’auto-évaluation sur les
attentes et les réalités de SOA
Pour comprendre les attentes de l’entreprise avant l’implémentation de la SOA et la
réalité après l’implémentation pour chacun des avantages théoriques de ce concept,
nous allons analyser la grille d’évaluation suivante, complétée par Monsieur Savary.
51
5. Etudes de cas
Attentes
Réalités
"Saint-Graal"
Théorique
ORGANISATIONNEL
Flexibilité
Complexe avec une forte
Modification des
services existants
implication de tous les
-
partenaires que cela soit du côté
du "client" comme du
"fournisseur"
Intégration de
nouveau processus
Adaptation à de
nouvelles exigences
-
idem
-
idem
TECHNIQUE
Pour éviter les difficultés
Favoriser le
développement
-
d'évolution l'on a tendance à
démultiplier les services
disponibles
Augmentation des
processus à
-
idem
-
idem
-
Pas évaluer / comparer
-
-
disposition
Réutilisation des
ressources
FINANCIER
Coût de
l’implémentation
Coût de la
maintenance
Coût de
l’infrastructure
Figure 5-4 : Grille d'évaluation des attentes et des réalités du SOA de l'OCN
52
5. Etudes de cas
Comme vu précédemment, la démarche SOA n’a pas été adoptée dans le cadre d’un
projet autonome. L’OCN a dû adopter cette technologie à la suite des contraintes
imposées par ses partenaires. L’évolution des partenaires de l’office vers ce type
d’architecture, en est la réelle raison. C’est pourquoi, l’OCN n’a pas établit des
objectifs à atteindre avec cette architecture. Elle a dû l’admettre afin de suivre les
évolutions
de
d’informations.
ses partenaires
en
matière
de
technologie
des
systèmes
Pour cette raison, le département n’avait pas des attentes
particulières vis-à-vis de la SOA lors de son adoption.
Une fois implémentée, les réels avantages et désavantages de cette architecture ont
pu être dénombrés au niveau technique et organisationnel. Certaines parties du
système ont connu des simplifications dans leurs processus grâce à la mise en place
de services à forte intégration, reliés entre elle avec un faible couplage au niveau de
la maintenance. De ce fait, le système utilisé est devenu plus flexible par endroit.
Toutefois, Monsieur Savary juge le niveau de flexibilité amené avec la SOA positif.
En effet, la modification des services existant ainsi que l’intégration de nouveaux
processus, qui auraient dû être améliorée avec l’implémentation SOA, demeure tout
de même complexe à mettre en pratique. Toute modification nécessite l’implication
de tous les partenaires clients ou fournisseurs. De ce fait, la marge d’autonomie de
l’entreprise en termes de changements informatiques se rétrécit.
Au niveau de la technique, le département informatique de l’OCN n’opte pas l’option
de réutilisabilité des services existants, mais plutôt préfère démultiplier les services
disponibles. Certes, de cette manière les problèmes diminuent mais ceci aura
comme conséquence d’augmenter la complexité du système notamment à cause des
redondances. Du fait que l’Office est fortement relié à des partenaires externes, elle
ne peut pas changer de stratégie informatique selon ses envies. Ceci explique les
problèmes de manque de flexibilité ou de non utilisation optimale des ressources à
disposition.
Sur le plan financier, aucune évaluation intégrale des coûts engendrés n’a été
réalisée jusqu’à ce jour par l’établissement. En effet, la mise en place de cette
architecture a été réalisée en plusieurs étapes moyennant des évolutions constantes
dues aux extensions de services. Ceci s’est déroulé sur plusieurs années. Depuis
53
5. Etudes de cas
2001, l’ensemble des coûts engendrés pour l’implémentation et l’adaptation se
monte à la hauteur de plusieurs millions de francs suisses. Pourtant d’autres
avantages apparaissent comme la diminution des
dépenses informatiques en
termes de modifications nécessaires à l’avenir. Même si dans ce cas, la SOA ne
permet pas d’avantages directs au niveau des coûts informatiques, elle offre tout de
même des opportunités d’épargne des coûts en cas de modification nécessaire du
système dans le futur.
Il est quasi irréaliste de dénombrer les avantages financiers selon Monsieur Savary,
dans la mesure où elle nécessite des évolutions constantes et rapides, tout en
sachant que ces évolutions engendrent elles aussi des coûts importants. Le plus
efficace sera de comparer cette architecture aux autres solutions utilisées dans le
département, pour connaitre les réelles épargnes réalisées avec SOA.
Dans l’ensemble, l’architecture orientée service fut pour l’office une contrainte
imposée par ses partenaires, à laquelle elle a dû s’y résoudre. Cette technologie
informatique a tout de même apporté des avantages à l’entreprise surtout en termes
d’organisation et d’épargne des coûts informatiques pour les projets futurs. En
somme, la SOA est perçue dans l’Office comme une tentative importante à
l’urbanisation de leur système d’information.
5.1.5. L’utilité réelle de SOA dans l’entreprise
L’architecture orientée service est décrite dans cette organisation comme une
architecture naissant de plusieurs tentatives informatiques passées et présentes
dans le but d’aboutir à une véritable urbanisation des systèmes d’information. La
notion d’urbanisation sous-entend l’évolution continuelle du système d’information en
vue d’anticiper les changements et transformations futurs. Cette discipline
d’ingénierie informatique a comme but de soutenir efficacement les objectifs et les
missions des entreprises [Club Urba-EA 2010, p.3-6]. SOA est le fruit de la mutation
de ces systèmes d’informations qui vont encore continuer à évoluer, dans notre
environnement et notre société bouleverser par le changement continuel. La
démarche SOA garantit des perspectives effectives dans le but de réaliser cette
54
5. Etudes de cas
intention d’urbanisation des systèmes. L’utilité réelle de cette architecture pour la
firme réside dans cette logique d’évolution informatique afin d’augmenter la
performance continuellement.
La mise en place de l’architecture SOA fut longue mais son adaptation le fut encore
plus. Il est difficile pour l’établissement d’estimer ce temps d’adaptation au sein de
toute l’organisation. Toutefois, il est important de souligner que la mise en place
d’une architecture de ce genre nécessite un engagement sérieux de la part de tous
les collaborateurs afin d’en assurer la maîtrise complète. Une fois implémentée
intégralement, l’architecture orientée service a augmenté le potentiel de performance
du système d’informations. Une simplification s’est installée à certains niveaux du
système, tout en complexifiant d’autres niveaux.
Théoriquement parlant, le fait d’adopter une telle architecture pouvait amener à des
gains en avantages concurrentiels. Toutefois étant donné que l’Office n’opère pas
sur un marché libre, cet argument théorique n’est pas discutable pour le cas de cette
entreprise. Ceci n’empêchant pas le fait que la SOA a augmenté la performance du
système en offrant de nombreuses améliorations techniques au niveau de
l’infrastructure logicielle. En somme, la réelle utilité de ce concept se calcule en
termes d’avantages organisationnels pour cette firme. Le gain en flexibilité du
système s’avère être la plus-value de l’adoption de la démarche SOA, permettant
ainsi à l’organisation une marge d’agilité.
55
56
5. Etudes de cas
5.2. Grande compagnie d’assurance
La seconde étude de cas repose sur une très grande compagnie d’assurance active
dans le monde entier dont le nom ne sera pas divulgué explicitement dans ce travail
pour des questions de confidentialité. Ce sous-chapitre se concentre sur
l’expérience, en termes d’architecture orientée service, dans les domaines de
l’assurance, secteur dans lequel le service est l’activité élémentaire. Les informations
utilisées par la suite proviennent d’une collaboration avec le responsable IT de la
compagnie d’assurance en Suisse, et sur la base d’un questionnaire qui leur était
destiné.
5.2.1. Présentation de la firme
Avec un effectif de plus de 160000 employés dans le monde entier, dont 4000 en
Suisse, et plus de 100 millions de clients, ce groupe d’assurance occupe une place
très importante sur le marché mondiale des assurances. Cette entreprise de service
opère dans plusieurs domaines et plus particulièrement dans des activités telles que
les solutions d’épargne, la gestion de patrimoine avec des produits bancaires ainsi
que dans tous les types d’assurances que ce soit des personnes, des véhicules, des
choses ou encore la responsabilité civile.
5.2.2. Objectifs visés par l’introduction de SOA
Avec de telles activités et une présence aussi importante sur le marché tant national
qu’international, l’entreprise nécessite de détenir un vaste système informatique dans
le but d’uniformiser les applications partout dans le monde entier. Leur système IT,
utilisant divers technologies dont SOA, s’est principalement développé au cours des
dernières années et gère actuellement plus de 300 applications différentes, dont
certaines datent de plus de quarante ans et d’autres sont plus récentes.
applications
sont
gérées
par
6
différentes
technologies
de
Ces
déploiement
d’applications dont une est l’architecture orientée service. Cette structure donne lieu
5. Etudes de cas
à une infrastructure informatique complexe utilisant des technologies variées afin
d’opérer de manière optimale dans les services proposés par la firme.
Adopter un nouveau concept informatique sous-entend toujours des améliorations de
la situation actuelle tant sur un plan opérationnel que sur un plan stratégique. La
compagnie en question a préféré opter cette démarche pour les avantages qu’elle
procure surtout au niveau organisationnel sans chercher à exploiter entièrement
toutes les fonctionnalités dans l’idée d’optimiser l’utilisation de cette technologie.
L’idée d’origine de l’adoption de cette architecture était de favoriser la réutilisabilité
des composantes du système. Ceci ayant comme but de minimiser les erreurs et les
redondances. De plus, par la réutilisabilité des ressources, l’entreprise a réussi à
développer leur système, pour le rendre plus homogène et efficace. La
communication entre les composantes du système devient améliorée et procure au
système plus de performance.
Toutefois, la réutilisabilité des composantes n’était pas le seul objectif poursuivi. En
effet, avec un système d’information aussi complexe nécessitant une performance
continuelle et une homogénéité au niveau global dans tout son champ d’exécution, il
était et est toujours nécessaire d’utiliser des technologies informatiques facilitant la
réalisation de ces processus complexes. L’entreprise décrit le principal but comme la
hausse du potentiel de management du système d’information constituée de
nombreuses applications complexes. Que l’on se trouve en Suisse, aux USA, ou
dans n’importe quel autre marché mondial, chacun des utilisateurs doit pouvoir
accéder à l’information de manière simple et compréhensible. SOA s’avère être dans
ce sens, une technologie facilitant l’accès à l’information par des utilisateurs lambda
et permet ainsi un meilleur management du système dans son intégralité.
Comme il s’agit ici d’une entreprise dont les activités sont majoritairement des
services, il fut nécessaire pour la firme d’adopter une méthode d’intégration des
applications permettant le découplage entre celles-ci afin de rendre les processus
plus fluides et les fonctionnalités plus simple d’utilisation. De ce fait, l’ensemble des
transactions réalisées dans le monde entier peuvent croître et permettre à
l’entreprise de renforcer sa position sur le marché grâce à un système d’information
plus flexible.
57
5. Etudes de cas
D’une part, le découplage est important pour faire face aux différents changements
technologiques que peuvent connaitre les technologies actuellement utilisées. En
effet, l’évolution technologique est un phénomène toujours plus important de nos
jours. Il est primordial de réussir à faire face à quelconque mutation technologique
afin de rester toujours à jour. Avec l’architecture orientée service, la compagnie
d’assurance peut facilement réagir face à tous types de changements grâce à ses
services modulables et son interface standardisée. Ainsi les fonctionnalités, les
processus et les technologies utilisés ont plus de chance de remplir entièrement leur
fonction en tout temps, dans ce monde heurté par la mutation technologique.
D’autre part, le découplage des composantes, permet une meilleure relation entre
les fonctionnalités back end et l’environnement front end du système d’information.
En effet, les fonctionnalités en arrière-plan du SI sont en général très lentes
d’exécution alors que les interactions sur l’interface d’utilisation doivent être rapides
et efficaces. Le niveau de découplage offert par l’architecture orientée service permet
d’homogénéiser cette relation pour obtenir en fin de compte un environnement
dynamique et flexible.
En plus de l’augmentation de l’agilité du système et la flexibilité face aux
changements, la compagnie souhaitait également gagner des avantages au niveau
financier par la réduction des coûts de maintenance toujours plus démesurés. En
effet, comme vu précédemment dans le chapitre 4.3 aux pages 45-46, les coûts
informatiques peuvent fortement être diminués, sur le long terme, lorsqu’on intègre
un SI avec une architecture SOA. Ce type d’architecture va grâce à la modularité des
services, la réutilisabilité des composantes et la simplification des processus,
diminuer les coûts de maintenance et d’entretien. Toutefois, il demeure difficile de les
quantifier.
5.2.3. Description de la démarche SOA et dans son évolution au fil du temps
Le concept d’architecture orientée service n'a pas été introduit dans la stratégie
informatique de la compagnie en tant que projet à part entière. Il fut nécessaire de
l’adopter à la suite des évolutions technologiques qu’a connues le marché
58
5. Etudes de cas
informatique. Face au besoin grandissant d’agilité dans cet environnement
chamboulé par les changements technologiques, environnementaux, stratégiques,
etc., la firme la introduite dans son infrastructure dans les années 2000.
Depuis, cette méthode d’intégration est en constant développement et joue
aujourd’hui un rôle important dans cette infrastructure. En effet, environ un tiers de
l’architecture logicielle est implémenter par la démarche orientée service. Cette
intégration orientée service est perçue comme une pratique apparaissant dans le
prolongement du développement de software réalisé par le département informatique
de la firme, et dont il est devenu impossible de s’en passer. L’architecture orientée
service a acquis le titre de très puissante gouvernance d’architecture au sein de cette
compagnie permettant ainsi un contrôle important sur l’ensemble de ce système
complexe. Les principes de la SOA sont acceptés et implémenter dans les valeurs
des équipes de développements informatiques
Dans les années 2000, la compagnie d’assurance a lancé un projet informatique
englobant l’établissement des technologies d’intégration à savoir les Enterprise
Service Bus, vu précédemment au chapitre 2.2.3 p. 16, afin de restructurer l’ossature
de leur système, sachant que l’implémentation d’une SOA par une ESB est la
méthode la plus commune de nos jours. Par la suite, ils décident d’implémenter des
processus pour les SOA Services Development et les SOA Services Operations
dans le but d’harmoniser l’architecture en place. Ces deux types de services sont mis
en place pour favoriser le développement et la gestion des opérations du système.
Enfin, la compagnie initie un référentiel de services d’entreprise permettant un
contrôle sur l’ensemble des services et par conséquent une intégration standardisée
de toutes les composantes du système.
L’architecture IT de cette compagnie d’assurance est assez complexe. Afin de
l’expliciter, nous allons décrire de manière simplifiée certains éléments au niveau
technique de l’architecture. Tout d’abord, il faut savoir que la firme dissocie les types
de services en trois catégories. Il existe les Business Objects Services qui consistent
aux services orientée objets, les Business Activity Services qui concernent les
activités générées par le système (par exemple un service faisant appel à d’autres
services) et les Presentation Services qui s’apparente surtout sur le visuel des
informations affichées sur l’interface d’utilisation. Ils agissent sur la base de ces trois
59
5. Etudes de cas
différents niveaux de services qui respectent les principes de couplage faible, voire
même de découplage dans certains cas, pour les données, les fonctionnalités, les
interfaces utilisateurs, etc. Ensuite un Enterprise Service Bus rend possible le
transfert de ces services là où des options d’intégration prédéfinis sont présentes.
Ces options autorisent les services à communiquer entre elles, favorisant l’interaction
de ces dernières. Ainsi l’échange et la communication entre les composantes du
système sont garantis. Enfin, afin d’orchestrer ces services selon les situations
demandées, l’entreprise fait appel à une plateforme du Business Process
Management (BPM). Le BPM, plus communément appelé gestion de processus
métier, permet la modélisation des processus métier de la firme tant dans sa forme
applicative ou humaine afin d’automatiser au maximum les processus métiers
[Madsen, Loureiro, Groupe CGI, 2006, p.4]. Toutefois cette orchestration peut aussi
directement être réalisée par les composants utilisateurs du système sans faire appel
au Business Process Management.
La vision de l’entreprise sur ce concept SOA se caractérise non pas comme une
technique en elle-même, mais comme une pratique permanente dans le
développement de leur système. Ils affirment suivre une forte approche contrat
mettant en relation d’une part une approche orientée entreprise et d’autre part une
plateforme indépendante. Cela signifie, selon les responsables questionnés, qu’il faut
définir le service SOA comme un service contrat en mettant toutes les informations
dans le référentiel de service d’entreprise alors que les plateformes restent
indépendantes du service mais dépendantes des adaptateurs.
En somme, l’architecture orientée service n’a pas été implémentée dans cette firme
en tant que projet mais plutôt telle qu’une pratique permanente dans le
développement de software. De ce fait, le budget consacré à cette implémentation
reste quasi impossible à quantifier même si l’on peut estimer que les frais furent
considérables dans la première phase de son implémentation. De par la complexité
de son système d’information, cette compagnie d’assurance doit en tout temps
développer son infrastructure informatique pour le rendre plus fonctionnel et simple
d’utilisation.
60
5. Etudes de cas
5.2.4. Grille d’auto-évaluation sur les attentes et les réalités de SOA
La figure 5-5 ci-dessus a été complétée par un responsable informatique du
département informatique de la compagnie. Elle met en évidence les attentes de
l’entreprise avant l’implémentation de la SOA et la réalité après l’implémentation pour
chacun des avantages théoriques de ce concept.
Attentes
Réalités
High
Quite high
Easy
Sometimes tricky
ORGANISATIONNEL
Flexibilité
Modification des
services existants
Intégration de nouveau
processus
Adaptation à de
nouvelles exigences
Easy
Only easy if the respective
services are in place already
-
-
Yes
Yes
-
-
TECHNIQUE
Favoriser le
développement
Augmentation des
processus à disposition
Réutilisation des
ressources
One of the principals
reasons
Yes
FINANCIER
Coût de l’implémentation
-
-
Coût de la maintenance
Increase of costs
Not quantified
Coût de l’infrastructure
-
-
Figure 5-5: Grille d'évaluation des attentes et des réalités du SOA de la compagnie d'assurance
61
5. Etudes de cas
Comme discuté précédemment, la compagnie d’assurance a opté cette méthode
d’intégration orientée service surtout pour ses avantages au niveau organisationnel.
Nous pouvons d’ailleurs le constater en observant la partie supérieure du tableau.
Seule la partie concernant les attentes et les réalités de SOA au niveau
organisationnel comportent des commentaires. Les deux autres catégories à savoir
l’aspect technique et l’aspect financier ne sont pas pris en compte dans l’analyse
puisqu’elles ne s’avèrent
pas faire partie des principaux critères de besoins de
l’entreprise.
Au niveau organisationnel, les attentes de la compagnie étaient grandes. La forte
pression concurrentielle oblige la firme à opter des positions avantageuses. Pour
ceci, la compagnie d’assurance avait des attentes de l’approche SOA très élevés en
termes de flexibilité. Plus un système est flexible, plus il devient facile de réagir
rapidement à une quelconque évolution du marché. Ainsi, la flexibilité des
technologies utilisées permet de gagner des positions intéressantes sur le marché
lorsque celles-ci sont exploitées de manière optimale. L’adoption de la démarche
SOA a engendré certes, des améliorations dans le système et augmenter la flexibilité
mais ceci n’est toujours pas suffisant en rapport avec les attentes initiales. Par
exemple, la firme juge que la modification des services existants ainsi que
l’intégration des nouveaux processus sont des deux principes qui demeurent assez
complexes à mettre en pratique.
Même si les principaux objectifs poursuivis sont au niveau organisationnel, la
compagnie d’assurance a tout de même observé des avantages en termes
techniques et financiers. En effet, grâce à la SOA, il fut possible de réutiliser
certaines ressources. Ce principe permettant une meilleure optimisation et une
allocation efficace des ressources a permis la diminution des coûts de
développement informatique lié à l’architecture logicielle, qui est tout de même
impossible à quantifier.
62
5. Etudes de cas
5.2.5. L’utilité réelle de SOA dans l’entreprise
Comme pour l’exemple précèdent, cette étude a été réalisée dans le but de
connaître la réelle utilité de la démarche d’intégration orientée service.
Dans le cas de cette compagnie d’assurance, l’accent est principalement mis sur
l’utilité organisationnelle que procure SOA. En effet, par cette architecture orientée
service, l’entreprise détient un système d’information flexible et permettant d’être plus
performant à certains niveaux du système d’information.
Sachant que plus de 30% de l’architecture logicielle de la firme est implémentée par
les principes SOA, l’importance de ce concept devient évidente. Ce type
d’architecture répond aux attentes de l’entreprise au niveau de la performance. En
effet, comme tous les services ne sont pas implémentés par l’architecture orientée
service et que le système fonctionne simultanément avec d’autres architecture
également, il est évident que SOA ne peut pas assurer une performance intégrale au
système d’information de l’entreprise à elle seule.
Même si toutes les attentes de la firme au niveau organisationnel ne sont pas
entièrement comblées, elles ne demeurent pas pour autant insatisfaites. Le gain
réalisé au niveau du changement possible grâce à l’approche SOA est bien plus
conséquente que le gain amené au niveau exécutif par la SOA. Ceci est
généralement du au couplage faible même voir au découplage à certains niveaux.
Ce type de couplage entre les services engendre une légère baisse de la
performance à court terme, mais une diminution massive des efforts nécessaires
face aux éventuels changements futurs. De ce fait, l’utilisation d’une telle
architecture, même à raison d’un tiers dans toute l’architecture logicielle, offre à la
firme des gains bénéfiques sur le long terme. Le système d’information adopte un
caractère plus agile et moins complexe.
La firme n’avait pas fixé d’objectifs en termes financiers et techniques lors de
l’adoption de la démarche SOA. Toutefois, cela ne signifie pas pour autant qu’il n’y a
aucun avantage d’ordre technique et financier. Bien entendu, SOA a simplifié la
structure de leur complexe système en permettant la réutilisation des ressources. Le
caractère de réutilisabilité des ressources à disposition fait de ce principe le plus
63
64
avantageux en termes de flexibilité apportée à l’intérieur même du système. En
terme financier, l’implémentation de la SOA permet de réduire les efforts de
développements futurs en cas de changements nécessaires. Il est évident que la
baisse des coûts informatiques reste un argument majeur à l’adoption de tout type de
projet informatique. Toutefois, il est impossible pour la firme de quantifier ce gain sur
le plan financier.
La vision de cette grande compagnie d’assurance tournée vers l’innovation oblige la
firme à défendre sa position de leader dans de nombreux domaines. De ce fait, le
développement devient le mot d’ordre de la stratégie d’entreprise tant sur le plan
stratégique qu’opérationnel. Le développement informatique s’inscrit alors dans cette
stratégie d’entreprise comme un incontournable outil de réussite. Comme l’affirme le
responsable IT de la compagnie, il n y a pas moyens d’échapper à l’utilisation de ce
type d’architecture surtout dans leur environnement orienté évolution, nécessitant de
créer leurs applications eux-mêmes. Les changements et les modifications dans le
système sont tellement fréquents qu’aucune autre architecture ne pourrait leur
permettre d’y répondre aussi rapidement. De ce fait, la présence de ce type de
technologie agile SOA dans leur architecture logicielle, leur est bénéfique en tout
point.
6. Résultats des études de cas : La réalité du SOA
Ce dernier chapitre se concentre sur les éléments précédents afin de synthétiser les
réponses obtenus et les analyser en mettant en évidence les avantages de SOA
ainsi que les lacunes de SOA afin d’en mesurer l’utilité réelle.
Il est ici question de comparaison entre des arguments théoriques émanant de la
littérature informatique et des expériences pratiques d’utilisateurs directs pour
réaliser le potentiel économique de la démarche SOA.
Les études de cas réalisées auprès de deux entreprises en Suisse, ont démontré
l’existence de diverses raisons à l’adoption de cette approche. Les entreprises sont
amenés à adopter ce concept non pas seulement en fonction de leur besoin, mais
également en fonction des contraintes imposées par leurs environnements et leur
stratégie. L’Office de la Circulation et de la Navigation fut dans l’obligation de l’opter
à cause de ses relations avec divers partenaires, alors que la compagnie
d’assurance l’a intégrer telle un outil nécessaire à la mise en place d’un projet
informatique.
Dans cette logique, aucune des deux entreprises n’ont été amené à fixer des
objectifs à viser avec l’adoption de la SOA. Toutefois, une fois intégrée, il est devenu
essentiel aux firmes de retirer des gains de cette architecture sur le plan
organisationnel, technique et financier.
6.1. Les avantages de SOA
Malgré le fait que les deux entreprises analysées sont actives dans des secteurs
différents, le principal avantage qu’elles ont retirés de cette approche SOA reste le
même : l’augmentation de la flexibilité du système d’information grâce à une
architecture logicielle modulable. Cette constatation met en évidence l’importance
des aspects organisationnels et techniques lors de la mise en place d’une telle
technologie et vient confirmer l’existence des avantages sous ces aspects, explicités
dans la partie théorique du travail.
65
En effet, la flexibilité est présentée comme le mot d’ordre dans la littérature
informatique. Cette nécessité s’explique par la mutation technologique. Nous
évoluons dans un monde compétitif, où la concurrence est de plus en plus rude sur
le marché. Chaque acteur de cet ensemble, est dans l’obligation de se démarquer
des concurrents afin de protéger ou même d’améliorer sa position. La pression est
d’une telle envergure qu’elle crée à elle-même le changement. Les technologies de
l’information se diversifient tous en se complexifiant. La capacité de réaction des
firmes face à ces transformations devient alors indispensable à leur réussite. Raison
pour laquelle, la grande majorité des entreprises tente de se doter de technologies
modulables et flexibles sur le plan informatique.
Nous avons pu constater dans les études de cas que la technologie SOA est
bénéfique pour les deux entreprises en termes de flexibilité. Elle permet à chacune
des deux institutions de faire face aux changements rapidement grâce à la
modularité de ses services. Toutefois, ce type d’architecture ne réduit pas pour
autant la complexité du système intégral et de ce fait contredit nos arguments
théoriques sur ce point.
D’un point de vue technique, les avantages théoriques discutés dans la première
partie du travail ne sont que partiellement obtenus. En effet, aucune des deux cas
analysés ne poursuivaient des objectifs techniques par l’implémentation de la SOA.
Pourtant la réutilisation des ressources a permis aux deux entreprises d’augmenter la
performance de leur SI grâce au couplage faible mise en œuvre dans l’architecture
SOA.
Même que la réutilisation des ressources reste complexe pour l’OCN, elle demeure
néanmoins un atout non négligeable pour la compagnie d’assurance. Avec un tel
avantage, l’entreprise n’est pas obligé de créer des nouveaux services pour chaque
nouvelle requête sachant que ceux-ci existent déjà dans le système. Quant à l’OCN,
la complexité rencontrée pour la réutilisation des services existants s’explique par
l’existence d’un fort couplage entre certains services. Dans ces situations, il devient
très complexe de faire appel à un service déjà existant. Ce principe détaillé dans le
chapitre 2.2.4 offre aux deux institutions des opportunités de développement en leur
permettant de réduire leurs coûts informatiques.
66
Théoriquement
parlant,
la
réutilisation
des
composantes devrait
permettre
l’augmentation des processus. Dans les études de cas, ceci ne s’est confirmée que
partiellement. En effet, pour la compagnie d’assurance ce principe a largement
contribué à l’augmentation des processus et à la
simplification des parties du
système implémenté avec la SOA. En ce qui concerne l’OCN, ce principe fut plus
difficile à mettre en place à cause de la complexité de leur système. Pour contrer la
complexité, ils préfèrent démultiplier les services pour favoriser l’intégration des
nouveaux processus. Le principe de réutilisabilité des composantes reste un
avantage important même qu’il soit mitigé en fonction des situations.
En dépit du fait que les avantages théoriques en termes organisationnels et
techniques ne sont pas entièrement réalisés dans la pratique, ils en demeurent
néanmoins évidents. Les résultats rencontrés dans les études de cas sont
surprenantes dans l’optique financière de la démarche. En effet, dans la première
partie du travail, nous avions affirmés le poids important des coûts dans ce type de
démarche. Aucune des deux entreprises n’a cherché à obtenir de manière directe la
diminution des coûts informatiques. Cette constatation contredit les arguments
financiers que nous avions exposés dans la première partie. La diminution des coûts
informatiques n’est de loin pas l’argument principal à l’adoption du concept orientée
service. Toutefois, nous pouvons tout de même observer dans les deux cas, une
diminution des coûts non quantifiable. Chacune des deux firmes ont vu des
avantages financiers en termes d’épargne des éventuels frais informatiques en cas
de modifications nécessaires dans le futur. La SOA est en quelques sortes un outil
d’anticipation permettant aux entreprises de réaliser des gains sur les éventuels frais
futurs dus aux évolutions technologies ou autres.
6.2. Les lacunes de SOA
Les principales lacunes de la démarche SOA sont difficiles à déterminer sur la base
de ces deux études de cas. En effet, aucune des deux firmes questionnées ne se
sont explicitement prononcés sur le sujet. Ceci est dû au fait, qu’aucune d’entre elles
n’ont analysé les lacunes de leur architecture SOA. Toutefois, en se basant sur leurs
expériences, nous pouvons en déterminer certaines.
67
Une des difficultés majeures rencontrées fut la durée et les moyens nécessaires à la
mise en place de cette architecture pour les deux cas analysés. En effet, le manque
d’expérience des collaborateurs dans ce domaine a induit à un prolongement de la
durée de son adaptation sans compter les coûts d’implémentation gigantesques qu’a
engendré l’adoption de cette démarche. Il fut nécessaire de mettre en place des
formations internes pour les utilisateurs. Le développement continu nécessaire dans
les technologies de l’information ont nécessité des coûts supplémentaires à la mise à
jour continue des systèmes. De ce fait, la solution SOA n’a pas permis une réduction
des coûts comme promis théoriquement. Toutefois, la plus grande difficulté de
l’adoption d’une telle architecture est l’investissement personnel de chaque
collaborateur concerné. Le réel engagement des collaborateurs fut incontournable à
la réussite de la mise en place de ce concept surtout pour le cas de l’OCN.
Une des autres problèmes rencontrés est la part qu’occupe la SOA dans toute
l’architecture logicielle des deux cas traités. En effet, les deux entreprises possèdent
simultanément avec la SOA d’autres types d’architecture d’intégration. La
coexistence de plusieurs différentes architectures peut amener certains problèmes
notamment dus à leurs divergences de fonctionnement. Moult processus
fonctionnant différemment entrant en ligne de compte, complexifient les systèmes
encore plus que ce qu’ils ne le sont déjà.
En somme, l'architecture SOA est un outil indispensable et nécessaire au
développement de leur système d’information. Monsieur Savary de l’OCN le décrit
comme « une parmi plusieurs tentatives passées et présentes afin d'aboutir à une
véritable urbanisation des systèmes d'information ». La SOA est une des meilleures
perspectives permettant l’accomplissement de cette urbanisation. Chez la compagnie
d’assurance, le bilan se décrit de la même manière : la SOA est une technologie
incontournable même si des améliorations seront toujours nécessaires.
68
6.3. Analyse globale de l’utilité de SOA
Le principal but de ce travail de Bachelor est de connaître la réelle utilité de
l’architecture orientée service au sein des entreprises de nos jours. Au début de ce
travail, plusieurs avantages ont été discutés d’un point de vue théorique. Dans la
seconde partie, l’analyse pratique nous a démontré les divergences entre
l’expérience pratique et la littérature théorique sur la démarche SOA. Sur la base de
ces deux parties, nous pouvons enfin synthétiser ce travail pour en déduire l’utilité de
ce concept dans les organisations l’exploitant.
Nous
pouvons
ressortir
des
deux
précédentes
parties
trois
conclusions
fondamentales concernant l’utilisation de la SOA au sein des entreprises aujourd’hui.
En premier lieu, nous avons pu remarquer que les utilisateurs SOA ont une bonne
vision de ce concept. Il est tantôt perçu comme une solution optimale pour l’évolution
des systèmes d’informations, et tantôt considéré comme un outil fondamental pour le
bon fonctionnement de l’infrastructure informatique. Toutefois, même si la SOA
demeure une technologie qui tient sa place dans les politiques informatiques, elle
nécessite tout de même des améliorations afin de répondre à tous les problèmes que
l’on pourrait rencontrer.
En second lieu, nous remarquons que l’approche SOA a autant d’avantages que
d’inconvénients aux trois niveaux d’analyse, à savoir organisationnel, technique et
financier. D’un point de vue organisationnel, elle permet plus de flexibilité donc plus
de marge de manœuvre en cas de modification nécessaire ou face à un changement
technologies. La maniabilité de cette architecture lui confère un caractère agile et de
ce fait plus flexible. Sous un regard technique, la réutilisabilité des services est l’atout
majeur de la SOA. Par cette possibilité, le système se simplifie à certains niveaux et
devient plus opérationnel. Quant aux avantages théoriques promis par la SOA au
niveau financier, ils ne sont pas vérifiés dans la pratique. Aucune des entreprises
n’ont pu voir la réduction directe des coûts. Toutefois, nous avons pu observer dans
le cas de la compagnie d’assurance que cette technologie avait un énorme avantage
financier dans le futur lorsqu’une éventuelle modification devra être appliquée.
69
70
En dernier lieu, aucune des entreprises analysées n’ont opté l’approche SOA de
manière complète. La solution SOA n’a pas été implémentée intégralement et de ce
fait analyser ce concept alors qu’il n’est que partiellement intégrée n’en démontre pas
les réelles opportunités. La seule réelle utilité de cette démarche qui est une
évidence est sa capacité à augmenter la flexibilité des systèmes d’informations.
De manière générale, nous pouvons constater que les avantages promis au niveau
théorique ne sont que partiellement réalisés dans la pratique. Ceci n’empêche pas
pour autant la vision positive que portent les utilisateurs à l’égard de la SOA et
justifient ainsi l’adoption d’une telle technologie dans les politiques informatiques des
firmes.
7. Conclusion
7. Conclusion
L’objectif de base de ce mémoire était de connaître l’utilité organisationnelle,
technique et financière de l’architecture orientée service en comparant les dits
théoriques avec les faits pratiques. Tout au long de ce travail nous avons tenté de
donner une réponse claire à la question émanant de cette recherche : quelle est la
réelle utilité de la SOA ?
Ce raisonnement qui fut présent tout au long de la rédaction de ce travail a abouti à
plusieurs réponses, tantôt satisfaisantes et tantôt surprenantes. Nous avons pu
constater que le concept au niveau théorique ne correspond pas toujours au concept
dans la pratique.
Ce travail qui nous a permis d’étudier une technologie informatique spécifique dans
les domaines de l’informatique de gestion, fut divisé en deux grandes parties
distinctes. La première partie portait sur le concept de la SOA d’un point de vue
théorique. Le but était de comprendre ce concept et les avantages qu’il peut offrir. En
2013, ce sujet a été traité et analysé sous tous ses angles par des professionnels du
domaine. Une quantité non négligeable d’œuvres littéraires, d’articles scientifiques et
de recherches ont été élaborés à ce jour et dont certains ont été utilisés dans la
rédaction de cette partie. Par contre, le nombre de firmes ayant adopté la démarche
SOA en Suisse semble moins important, constaté dans la seconde partie du travail
axée sur l’expérience pratique de la SOA. Notre but était de voir jusqu’à quel niveau,
cette architecture est utile aux entreprises en Suisse, en présentant le cas de deux
entreprises suisses du secteur privé et publique.
Certes il est quasi impossible de donner une réponse à cette question sur la base de
deux études de cas seulement, mais cela ne nous empêche pas d’avoir une idée de
son utilisation. Néanmoins, les résultats obtenus de ces cas, nous permettent de dire
clairement que l’architecture orientée service tient sa place dans toute architecture
logicielle souhaitant agilité et flexibilité. Ce travail de Bachelor nous a démontré que
ce concept, même que concurrencé aujourd’hui par d’autres technologies, garde un
potentiel important de croissance et s’avère être un outil fondamental dans la
continuité de l’optique d’évolution des systèmes d’informations.
71
72
8. Bibliographie
8. Bibliographie
8.1. Littérature
[Bell,
2006]
Bell
Marks:
Service-Oriented
Architecture:
a
planning
and
implementation guide for business and technology, Hoboken, John Wiley & Sohns,
2006.
[Bonnet, Detavernier, Vanquier 2008] Bonnet Pierre; Detavernier Jean-Michel ;
Vauquier Dominique : Le Système d’information durable: la refonte progressive du
SI avec SOA, Paris, Hèrmes Science, 2008.
[Club Urba-EA 2010, p.3-6] Club Urba-EA, Urbanisme des SI et Gouvernance,
Dunod, 2010
[Erl 2008] Erl Thomas: SOA principles of Service Design, Indiana, Prentice Hall,
2008.
[Erl 2006] Erl Thomas: Service-Oriented Architecture, Concept, Technology, and
Design, Indiana, Prentice Hall, 2006.
[Fournier-Morel, Grosjean, Plouin, Rognon 2011] Fournier-Morel Xavier, Grosjean
Pascal, Plouin Guillaume, Rognon Cyril : SOA Le guide de l’architecte d’un SI agile,
Paris, Dunod, 2011.
[Gordon, Olson, Ajenstat, Peaucelle 1986] Gordon, B. Davis ; Olson, Margrethe
H.; Ajenstat, Jacques, Paucelle, Jean-Louis : Systèmes d’information pour le
management. Boucherville, Edition G. Vermette, 1986.
[Grenier, Moine 2003] Grenier, Claude ; Moine, Camille : Construire le système
d’information de l‘entreprise. Paris, Foucher, 2003.
[Heutschi 2007 ] Heutschi Roger: Serviceorientierte Architektur, Architekturprinzipen
und Umsetzung in die Praxis, Berlin, Springer, 2007.
8. Bibliographie
[Holley, Dr. Arsanjani, 2011] Holley Kerrie, Dr. Arsanjani Ali: 100 SOA Questions
Asked and Answered, Indiana, Prentice Hall, 2011.
[Hüsemann 2011] Hüsemann, Stefan : Systèmes d’information I. Université de
Fribourg, Suisse, 2011
[Krafzig, Banke, Slama 2006] Krafzig Dirk; Banke Karl ; Slama Dirk : Enterprise
SOA : Service-Oriented Architecture Best Practice, Prentice Hall, 2006.
[Liebhart 2007] Liebhart Daniel: SOA goes real: Service-Orientierte Architekturen
erfolgreich planen und einführen. München, Hanser, 2007.
8.2. Articles, documents, présentations
[BEA SYSTEMS, 2005] Méthodologie SOA en six domaines, Révéler les avantages
métiers
d’une
Architecture
Orientée
Services,
BEA
SYSTEMS,
2005
http://img1.lemondeinformatique.fr/ftp/partnerzone/BEA/livresblancs/livreblanc_metho
dSOA.pdf
[Debray, IBM Software Group, 2005] De la modélisation Métier à l’implémentation
SOA, Séminaire Mettre en œuvre aujourd'hui une Architecture Orientée Services
(SOA), Luc Debray, Paris, 2005
ftp://service.boulder.ibm.com/software/fr/event/soa/SOA2juinCBMtoSOA-LucDebrayV2.pdf
[Gartner Group 2008] Building an SOA Business Case: A Gartner Framework,
Gartner Group, Anthony Bradley, W Schulte, Daniel Sholler, Paolo Malinverno, 2008
[Laftimi, CNAM 2009] SOA (Service Oriented Architecture) Architectures Orientées
Services, Ahmed Laftimi, CNAM 2009
http://home.nordnet.fr/~ericleleu/cours/nfe107/SOA.ppt
[Michoud, Abissa Informatique 2008] L’approche SOA, Olivier Michoud, Abissa
Informatique, 2008
73
74
8. Bibliographie
http://www.abissa.ch/data/fichiers/tec_architecture_soa.pdf
[Madsen, Loureiro, Groupe CGI, 2006] Exploitez la pleine puissance de
l'architecture orientée services (SOA) en la combinant à la modélisation des
processus d'affaires, Michael Madsen, Rodrigo Loureiro, Groupe CGI, 2006
http://www.cgi.com/files/white-papers/cgi_whpr_67_soa_bpm_wp_f.pdf
[Raymond, Softeam, 2011] SOA: Architecture Logique : Principes, structures et
bonnes
pratiques,
Raymond
Gilbert,
Softeam,
Paris,
2011
http://www.softeam.fr/sites/default/files/files/Livre%20blancSOA%20Architecture%20Logique.pdf
[SAP AG, University of St. Gallen, 2008], SAP AG, University of St. Gallen,
Economic
Experiences
Justification
and
of
Service-Oriented
Guidelines
on
Building
Architecture,
SOA
Research
Business
Cases,
Study:
2008
http://www.sap.com/brazil/temp/Economic_Justification_of_SOA.pdf
[SAP AG, University of St. Gallen, Saat, Discher, 2009] Economic Justification of
SOA, Jan Saat, Institute of Information Management, University of St. Gallen, Stefan
Discher, Global Platform Marketing, SAP AG, 2009
[Softeam, Guide pratique Objectering, 2008] Le Guide Pratique des Processus
Métiers, Equipe Conseil Softeam, Paris, 2008
http://support.objecteering.com/objecteering6.1/tutorials/fr/guides/business_process_
guide_fr.pdf
[Soto, IBM Corporation, 2008] Augmenter la flexibilité de l’entreprise grâce à
l’architecture orientée service, Soto David, IBM Corporation, 2008
http://www.bitkom.org/files/documents/P2_5_Wirtschaftlichkeit_von_SOA_StGallen_
SAP_FO_SOA_2009.pdf
8. Bibliographie
8.3. Webographie
[Abraxas Cari 2011] Juin 2013
http://www.abraxas.ch/fileadmin/customer/Dokumente/Produkte/Abx_CARI_Prod_fr.p
df
[Barry, Barry&Associates, 2013] Avril 2013
http://www.service-architecture.com/
[Ben Driss Khaled, 2007] SOA: Démystification, Khaled Ben Driss, Février 2013
http://fr.slideshare.net/kbdsoft/soa-architecture-oriente-service-dmystification-khaledben-driss-21-nov-2007-v121
[CIO UK, 2011] Avril 2013
http://www.cio.co.uk/news/architecture/forrester-claims-soa-projects-still-alive-andwell/
[Confédération Suisse 2013] Juillet 2013
http://www.bit.admin.ch/org/index.html?lang=fr
[Gartner Group 2011] Mai 2013
http://www.gartner.com/newsroom/id/1632714
[Gartner Group 2013] Février 2013
http://www.gartner.com/id=391595
[IT- Expert Magazine, 2011] Mai 2013
http://www.it-expertise.com/gouvernance-des-architectures-soa-entre-controle-etflexibilite/
[Jemm Vision & Jemm Research, 2012] Avril 2013
http://www.jemmvision.com
75
8. Bibliographie
[Le Monde Informatique 2006] Mai 2013
http://www.lemondeinformatique.fr/actualites/lire-le-business-s-approprie-la-soaestime-le-cabinet-gcr-custom-research-21420.html
http://www.lemondeinformatique.fr/actualites/lire-les-depenses-en-soa-augmententles-risques-aussi-note-amr-research-25444.html
http://www.lemondeinformatique.fr/actualites/lire-depenses-soa-24-entre-2008-et2013-selon-idc-30289.html
[Microsoft Corporation 2009] Mai 2013
http://www.microsoft.com/france/entreprises/plateformeapplicative/scenarios/details/business-processandsoa.aspx
[OCN 2013] Juillet 2013
http://www.bit.admin.ch/org/index.html?lang=fr
[SOA Blog, 2010] Mars 2013
http://www.soablog.fr/2010/02/01/presentation-du-cadre-de-reference-framework-dela-gouvernance-soa/
[Wikipedia, 2013] Février 2013
http://fr.wikipedia.org/wiki/Couplage_(informatique)
[Xebia IT Architects, 2007] Avril 2013
http://blog.xebia.fr/2007/08/16/mise-en-oeuvre-dune-soa-les-cles-du-succes/
76
9. Annexes
9. Annexes
Annexe 1: « SOA Infrastructures Costs »
77

4. Avantages de l`architecture orientée service - DIUF

Transcription

Documents pareils

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

Consultants EAI/SOA/Urbanisation (H/F)

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

Les services Web rajeunissent le mainframe

Entreprise agile et l`alignement métier